Пока что воздержусь от комментариев, но - уточнение:
- Если это статья, то исправьте, пожалуйста, ошибки - поскольку из-за них я не смог уловить смысл многих фраз, либо же он двояк (не говоря уже о том, что такой стиль/грамматика для статьи недопустим)
- Если это вопрос, то выделите чётко, что Вы спрашиваете, так как сейчас это понять не представляется возможным.
Плохой. Отсутствующий cookie-header в соответствующем HTTP-Request разрушит всю подобную защиту. И - да, роботы шлют через cURL, им не нужно стирать куки в браузере.
А разве приватный конструктор не приводит к Fatal Error при попытке создать объект стандартным способом?
Приводит. О том и речь. А раз так, я предполагаю, что предложенный вариант с exit относится к публичному конструктору - и потому считаю это плохой идеей (и, если уж есть такая необходимость, корректнее использовать исключения, хотя и с ними такой подход выглядит в лучшем случае странным).
DelphinPRO
Нет, вероятно, посыл не был понят. Если это случай, когда класс разрабатывается для самого себя - то вполне достаточно сделать конструктор приватным (для самого себя нет нужды использовать exit - ведь про свои действия каждый в курсе).
Но вот если предполагается использовать класс как часть некоторого API - или части библиотеки - словом, если пользователями будут сторонние разработчики, которые могут использовать его в динамическом контексте - exit выглядит плохим решением.
Разумеется, я имею ввиду связку обычного (публичного) конструктора + exit, так как в случае с приватным конструктором возникнет Fatal error ещё до вызова exit
OrmaJever
В корне плохая идея. exit не предоставляет никакой возможности или свободы при выборе действий. Таким образом, прерывая исполнение скрипта, исключается любая возможность определить реакцию на возникшую ситуацию. Корректный способ - использовать исключения (Exception), но даже и так - в ряде случаев приватный конструктор может принимать параметры и использоваться в других статических методах, инстанцирующих объект.
Насчёт синглтона - его польза в PHP стремится к нулю, по сути это почти всегда антипаттерн. Разумное правило - если объект не должен существовать более, чем в одном экземпляре - не инстанцировать его более одного раза. Хорошее пояснение почему это так для PHP есть здесь
Насчёт статических методов - их лучше избегать. Есть немного случаев, когда их использование оправдано (например, уже упомянутые выше инстанцирующие методы, которые по определению не могут быть иначе как статичными ввиду отсутствия контекста объекта при их вызове). Общее пояснение - статические методы трудно тестировать, они являются, по сути, неявным побочным эффектом (side-effect), так как переносят общий контекст между разными объектами - а это затрудняет читаемость, переносимость и поддержку кода в большинстве случаев.
Зависит от того, сколько уровней вложенности существует. Если фиксированное число - то можно одним запросом. Либо же - изменить структуру таблицы (см. nested sets)
1: Пока Славик ходил курить, обучили его Аутлук старословянскому ))
2: Эт как? )
1: Врубили ему автозамену список=свиток, чтобы=дабы, ну и там воистину, ибо и т.д. Главное, чтобы в глаза не бросалось )
1: Так он очень удивился, когда на письмо с фразой "... посему высылаю всем свиток свободных айпишников, не забывайте!" ему стали приходить ответы типа "Челом бьем, боярин! Не прибежал еще со свитком гонец" ))
Вы говорите не о ключах, а о значениях. Кроме того, зачем нужны пустые значения? (они есть в каждом элементе 2-го уровня). Если они не нужны, то зачем нужна вложенность 3-го уровня, не будет ли достаточно 2-й? Если всё же пустые значения по какой-то причине нужны, как они должны быть обработаны?
ВэйДлин
Смысл в том, что PHP уже имеет штатный класс, реализующий все стандартные интерфейсы работы с массивами. Называется ArrayObject и при наследовании от него, разумеется, класс получит все его свойства, после чего с ним можно будет работать, как с массивом.
Указывайте id явно. Либо используйте перенумерацию после создания записей. Корректный путь - не привязываться к id, так как они - всего лишь номера и ничего более.
Stokmam
Это зависит от того, что значит "не допустить уязвимость". Использование стольких функций подсказывает мне, что Вы делаете это "просто на всякий случай", то есть не имеете чёткого представления - где, как и для чего будут использоваться сохранённые данные. Это плохо. Значит, я тем более не могу ответить, что для Вас безопасно, а что - нет. Я могу лишь сказать, что приведённый код запишет верную SQL-строку, у которой удалены концевые пробельные символы и html-теги заменены на их экранирующие представления. Достаточно ли этого? Неизвестно. Может быть, у Вас планируется система проверки прав пользователей и Вам нельзя записывать, например, значение '0'. С точки зрения приведённой функции оно вполне верно, но с точки зрения логики - уже нет. Поэтому прежде, чем задавать себе вопросы о безопасности, стоит задать вопрос из разряда "как же вообще всё это должно работать?" - Какой должна быть логика приложения, какие сценарии (user-story) допустимы и т.п.
Нельзя заниматься вопросами безопасности в приложении, логика которого неопределена и архитектура которого неизвестна. И нельзя написать "универсальную" функцию, которая предусмотрит все возможные исходы - так как эти исходы связаны с логикой приложения.
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 8901
