> Я не против процедурного программирования, но если уж выбирать его, то зачем создавать объекты?
А тут объекты и не нужны. Просто не хочется создавать глобальные переменные вместо статических свойств как сейчас.
>В РHP есть пространства имён, не нужно ничего «эмулировать».
В PHP > 5.0, < 5.3 их нет. А нам приходится использовать библиотеку на хостингах где нет 5.3.
> здесь невозможно использовать autoload, нужен require.
Это почему же нельзя? Мы используем, там, где это надо. Все имена классов начинаются с «Botobor_». Сделать функцию автозагрузки элементарно.
> запрашивать необходимые параметры в конструкторе
Да пожалуйста! Если в конкретном проекте это имеет смысл — напишите обёртку, которая будет передавать в метод аргумент $req, и тогда метод не будет трогать $_SERVER. Но нам, бывает, приходится иметь дело с проектами, которые написаны не нами и по которым нет документации, а защитить форму надо «вот уже прям щас». Бывают проекты, где и фреймвока-то нет, просто набор скриптов. Разные, в общем, проекты бывают. И часто обработка $_SERVER — вполне допустимый компромисс между красотой решения и затратами на реализацию.
> html нужно разбирать с помощью XML-парсера
Кому нужно? :-) Нет, как расширение функциональности, в виде отдельного модуля, это конечно можно сделать. Я даже обязательно тикет такой открою. Но, как я уже писал выше, мы сталкиваемся с самыми разными проектами. И на многих из них, использование парсера будет напоминать забивание гвоздя под крючок для картины при помощи промышленного пневмомолота. Это конечно круто, высокотехнологично… но смысл?
Знаете, я некоторое время назад, тоже был пуристом, как и Вы. Но в последнее время стал всё чаще задумываться и об экономической целесообразности.
Изначально всё хранилось в сессии, потом почему-то было переделано без сессий. Надо вспомнить, почему. Но вообще, как вариант, такую возможность надо добавить (https://github.com/mekras/botobor/issues/7)
Я тут подумал, по сути, мета-данные, добавляемые Ботобором в форму, это и есть маркер против CSRF. Потому что они содержат время создания страницы (т. е. уникальное значение), подписанное при помощи неизвестного посетителю ключа.
> Идея: REFERER может быть, может не быть. Основывать на этом защиту — создавать проблемы пользователю.
Защита на этом не основывается. Это лишь одна из возможных проверок.
> Поля приманки могут создать проблемы с автозаполнением — абсолютно легальные пользователи отсеются.
Разработчик волен не использовать поля-приманки в формах, которые могут заполняться одним пользователем многократно, или в любых других по своему усмотрению.
> несколько классов в одном файле
Обычно мы так не делаем, но здесь это вполне сознательное решение. Причина — компактность и простота подключения к сайту.
> статические методы
Что не так со статическими методами? В данном случае они выполняют функцию эмуляции пространства имён.
> обращение к глобальным переменным внутри класса
Если речь идёт про обращение к $_SERVER в Botobor_Keeper::handleRequest, то это на усмотрение разработчика. Методу можно передать аргумент $req, и тогда он $_SERVER трогать не будет. Если у Вас есть идеи, как сделать лучше — буду рад услышать.
Любая защита всегда многослойна и неабсолютна. Неверно говорить, что защита работает или не работает, всегда надо уточнять о каких случаях идёт речь. Каждый слой защиты — дополнительная страховка от определённого набора случаев. Ограничение lifetime защищает от программ вроде Хрумера, но оно не спасёт от примитивных пауков, работающих по принципу «нашёл форму — засабмитил». Зато от них спасёт ограничение Delay, которое, в свою очередь, не спасает от для Хрумера. И т. д.
Защита от CSRF — ещё один слой, который может быть, а может и не быть. Например, зачем защита от CSRF на сайте, где нет регистрации пользователей?
Разные проекты, разные задачи — разный набор проверок и параметров этих проверок.
Если это форма комментария — можно установить большой lifetime, или вообще отключить проверку.
Если это форма запроса звонка, расположенная на отдельной странице — можно установить lifetime поменьше.
Никто разработчика не заставляет использовать все проверки со значениями по умолчанию.
Удобнее тем, что задавать в секундах никогда надобности не возникает, а вот в минутах были случаи. Собственно, по умолчанию, там как раз (если не ошибаюсь) 30 минут стоит. По опыту, подходит для большинства случаев. Пока менять в большую сторону приходилось только на паре проектов.
DateInterval появился только в PHP 5.3, а нам надо было обеспечить работу библиотеки и под более ранними версиями 5-й ветки.
Логично. Потому что Delay никогда не бывает больше минуты, а Lifetime, наоборот — не бывает меньше. Ну и задавать его в минутах просто удобнее для конечного разработчика.
По большому счёту библиотека и рассчитана на типовые решения, она позволяет быстро и просто защитить формы от роботов. Если у вас крупный проект, к тому же лакомый для спамеров, конечно, стоит подумать об индивидуальной и более сложной защите. А вот для сайтов, где пяток форм, вроде «обратной связи», Ботобора вполне хватит.
Как я и написал, разработчик может сам выбрать какие проверки уместны, в зависимости от условий стоящей пред ним задачи. Конкретно проверка на большой промежуток предназначена для того, чтобы нельзя было сохранить форму с её мета-данными и использовать её в будущем (через день, два, десять…).
Я обычно выношу все подобные моки в отдельный файл (как helpers.php в примере), который подключается всеми заинтересованными тестами. Ну и внутри моков функций используется более сложная логика, покрывающая все потребности тестов. Тут уже всё зависит от сложности тестирования. Можно сделать класс со статическими членами, который будет и возвращать значения для моков функций, и вбрасывать исключения, и хранить историю вызовов. Всё ограничивается только фантазией программиста.
А тут объекты и не нужны. Просто не хочется создавать глобальные переменные вместо статических свойств как сейчас.
>В РHP есть пространства имён, не нужно ничего «эмулировать».
В PHP > 5.0, < 5.3 их нет. А нам приходится использовать библиотеку на хостингах где нет 5.3.
> здесь невозможно использовать autoload, нужен require.
Это почему же нельзя? Мы используем, там, где это надо. Все имена классов начинаются с «Botobor_». Сделать функцию автозагрузки элементарно.
> запрашивать необходимые параметры в конструкторе
Да пожалуйста! Если в конкретном проекте это имеет смысл — напишите обёртку, которая будет передавать в метод аргумент $req, и тогда метод не будет трогать $_SERVER. Но нам, бывает, приходится иметь дело с проектами, которые написаны не нами и по которым нет документации, а защитить форму надо «вот уже прям щас». Бывают проекты, где и фреймвока-то нет, просто набор скриптов. Разные, в общем, проекты бывают. И часто обработка $_SERVER — вполне допустимый компромисс между красотой решения и затратами на реализацию.
> html нужно разбирать с помощью XML-парсера
Кому нужно? :-) Нет, как расширение функциональности, в виде отдельного модуля, это конечно можно сделать. Я даже обязательно тикет такой открою. Но, как я уже писал выше, мы сталкиваемся с самыми разными проектами. И на многих из них, использование парсера будет напоминать забивание гвоздя под крючок для картины при помощи промышленного пневмомолота. Это конечно круто, высокотехнологично… но смысл?
Знаете, я некоторое время назад, тоже был пуристом, как и Вы. Но в последнее время стал всё чаще задумываться и об экономической целесообразности.
Если утечёт подпись и пойдёт спам, её легко сменить.
Не поясните зачем?
Защита на этом не основывается. Это лишь одна из возможных проверок.
> Поля приманки могут создать проблемы с автозаполнением — абсолютно легальные пользователи отсеются.
Разработчик волен не использовать поля-приманки в формах, которые могут заполняться одним пользователем многократно, или в любых других по своему усмотрению.
> несколько классов в одном файле
Обычно мы так не делаем, но здесь это вполне сознательное решение. Причина — компактность и простота подключения к сайту.
> статические методы
Что не так со статическими методами? В данном случае они выполняют функцию эмуляции пространства имён.
> обращение к глобальным переменным внутри класса
Если речь идёт про обращение к $_SERVER в Botobor_Keeper::handleRequest, то это на усмотрение разработчика. Методу можно передать аргумент $req, и тогда он $_SERVER трогать не будет. Если у Вас есть идеи, как сделать лучше — буду рад услышать.
> парсинг html регуляркой
Ваши предложения?
> настройки через массивы параметров.
Где?
Защита от CSRF — ещё один слой, который может быть, а может и не быть. Например, зачем защита от CSRF на сайте, где нет регистрации пользователей?
Если это форма комментария — можно установить большой lifetime, или вообще отключить проверку.
Если это форма запроса звонка, расположенная на отдельной странице — можно установить lifetime поменьше.
Никто разработчика не заставляет использовать все проверки со значениями по умолчанию.
DateInterval появился только в PHP 5.3, а нам надо было обеспечить работу библиотеки и под более ранними версиями 5-й ветки.