если система не предполагает в паролях русских букв, то проверку можно (и нужно) производить на клиенте, тем же JS проверять введенные буквы, и если они русские выводить предупреждение об этом.
В свою очередь предлагаю всем читателям максимально активно голосовать за комментарии, которые по вашему мнению представляют ценность (а не только понравились или не понравились, лично вам). Это не только придаст радости автору комментария, но и поможет последующим читателям легче ориентироваться в дереве, так как многие читают именно цепляясь глазами за заплюсованные высказывания, а не читают всё подряд. А так же это немного поможет автору топика их агрегировать, например, автор может быть не согласен с чьим то мнением, но видя, что согласных много добавлять в свой топик и альтернативные точки зрения.
Я вообще обычно лоялен к некоторой неграмотности, хотя всё равно не приветствую. Но есть ошибки, от которых реально мутит. «Еженидельно» относится как раз к таким. Исправьте, пожалуйста.
Во-первых, вы предлагаете по сути вариант капчи, а топик о том, как обойтись без нее
Во-вторых, пример с хабром и комментариями совсем не в тему, для комментирования нужно быть зарегестрированным, просить же зарегестрированных ответить на вопрос — в высшей степени издевательство и стремление к смерти ресурса. Защищать надо только форму регистрации/авторизации.
В-третьих, ваше слово-ответ узнается один раз, после чего натравленный бот работает уже без помех.
Ну как бы Referer — это просто один из заголовков, передаваемых клиентом серверу. По стандарту он не обязателен, как и большинство других. Например такой известный файрвол Outpost смело вгрызается в http-соединения и вырезает такой, казалось бы безобидный заголовок, как Accept-Encoding, после чего у вас полностью перестает работать gzip-сжатие, а вы даже об этом и не узнаете, разве что в статистике заметите более высокий расход трафика. Так было, когда я им пользовался. И сделали так потому(видимо), что Outpost не умел распаковывать данные на лету или это оказывалось очень накладно по ресурсам. Запрет рефереров — это средство от паранойи, чтобы никто не мог понять о вас даже таких пустяков, как какой вы посещали сайт, перед тем, как придти на этот.
Про реферер можно еще забыть из-за такой банальности, как закладки. Пришел я на страницу формы, положил ее в закладки со словами — потом отправлю а через какое то время открыл эту страницу и отправил форму, с пустым рефером :)
Да, хороший подход. Причем делать так хорошо. На первом этапе генерить форму полностью яваскриптом, тогда проходящие мимо автоботы даже не узнают, что тут была форма, и не будут ломиться, так что заодно снизим нагрузку на сервер :)
Нет, плохой. Передача реферера — воля браузера, пользователя и файрвола. А также админа прокси-сервера, через который живет пользователь. В каждой инстанции этот заголовок может быть изменен или запрещен пользователем. Боту с другой стороны ничего не мешает при обходе сайта запомнить URI с которого он попал на страницу с формой и передать этот URI в заголовке HTTP_REFERER.
Удивительно, но многие простенькие боты заполняют все неизвестные поля.
В этом ничего удивительного, в той теме, где мы это обсуждали я объяснял почему это так :) И так делают не просто многие боты, таким интеллектом обладает большинство ботов-автоматов. Даже если автомат заточен под конкретный движок, пара изменений в стандарте форм этого движка — и автобот обломается.
1. Время заполнения формы учитывать нельзя, так как у пользователя может работать автозаполнение форм, и он ее может заполнить «неожиданно» быстро. Если форма долго не сабмитится, то человек мог уйти попить кофе — это нормально.
2. Капча вообще была придумана только потому, что у людей может не быть JS. Если забить на тех у кого нет JS — то форму можно полностью генерить яваскриптом передавая с сервера данные в виде массива/объекта для генерации+ключ для сверки. Боты задолбаются. Возможности защиты с JS — практически безграничны, но все таки его некоторые отключают.
3. Проверка юзерагентов совершенно неэффективна. Бот скорее будет маскироваться под браузер, нежели слать специфичный для него заголовок (это вообще глупость какая то — зачем ему это надо?)
4. Про бан по IP нужно забыть совсем. Мало того, что за одним IP может сидеть куча невиноватого народу, так и бот может орудовать с компьютера жертвы, которая о нем не знает (вирус, то бишь). Соответственно про «ловушку» можно тоже забыть. Бан по IP более менее работает только в локальных сетях, там это имеет смысл.
5. от целенаправленного и/или человеческого вскрытия не спасет ничего :)
Упс… чего то на меня поздяя ночь плохо подействовала сегодня — неправильно разряды посчитал, в чиселке 487299860 насчитал 10 знаков, извините меня :)
Насчет покрытия всего населения и интернетизации не совсем верно, не являясь злостным асечником, за свою жизнь зарегестрировал уинов 6-7. На работе практически весь состав офиса менял как минимум один раз аську за несколько лет, потому что меняли пароль, угодняли и пр.
То есть если у нас есть поле «ICQ» типа VarChar, делать его длиннее 10 символов бессмысленно
Т.е. когда у ICQ вместо десятизнаков появятся 11-ти(а это может произойти достаточно скоро) — вам надо будет об этом во-первых как-то узнать, во-вторых менять структуру БД, точнее менять размерность поля. На практике это означает, что вы узнаете об этом уже как о баге — вероятнее всего от пользователей вашего ресурса/приложения.
Это нехороший подход. Конечно не надо для ICQ делать varchar(255), но хотя бы какой то разумный запас оставлять надо я бы поставил хотя бы на несколько лет вперед varchar(12). Тем более, что с точки зрения производительности — разница мизерна
Какой в этом смысл? В песочнице за эту статью автор практически сразу получит инвайт, не дожидаясь +50-ти, и тут же её сам от своего имени и опубликует, за что получит заслуженные плюсы.
Я так понимаю, разница в обработке escape-символов?
Кстати alert('\x'=='x') выдает true в остальных браузерах
Спасибо
Во-вторых, пример с хабром и комментариями совсем не в тему, для комментирования нужно быть зарегестрированным, просить же зарегестрированных ответить на вопрос — в высшей степени издевательство и стремление к смерти ресурса. Защищать надо только форму регистрации/авторизации.
В-третьих, ваше слово-ответ узнается один раз, после чего натравленный бот работает уже без помех.
Про реферер можно еще забыть из-за такой банальности, как закладки. Пришел я на страницу формы, положил ее в закладки со словами — потом отправлю а через какое то время открыл эту страницу и отправил форму, с пустым рефером :)
1. Время заполнения формы учитывать нельзя, так как у пользователя может работать автозаполнение форм, и он ее может заполнить «неожиданно» быстро. Если форма долго не сабмитится, то человек мог уйти попить кофе — это нормально.
2. Капча вообще была придумана только потому, что у людей может не быть JS. Если забить на тех у кого нет JS — то форму можно полностью генерить яваскриптом передавая с сервера данные в виде массива/объекта для генерации+ключ для сверки. Боты задолбаются. Возможности защиты с JS — практически безграничны, но все таки его некоторые отключают.
3. Проверка юзерагентов совершенно неэффективна. Бот скорее будет маскироваться под браузер, нежели слать специфичный для него заголовок (это вообще глупость какая то — зачем ему это надо?)
4. Про бан по IP нужно забыть совсем. Мало того, что за одним IP может сидеть куча невиноватого народу, так и бот может орудовать с компьютера жертвы, которая о нем не знает (вирус, то бишь). Соответственно про «ловушку» можно тоже забыть. Бан по IP более менее работает только в локальных сетях, там это имеет смысл.
5. от целенаправленного и/или человеческого вскрытия не спасет ничего :)
Насчет покрытия всего населения и интернетизации не совсем верно, не являясь злостным асечником, за свою жизнь зарегестрировал уинов 6-7. На работе практически весь состав офиса менял как минимум один раз аську за несколько лет, потому что меняли пароль, угодняли и пр.
Это нехороший подход. Конечно не надо для ICQ делать varchar(255), но хотя бы какой то разумный запас оставлять надо я бы поставил хотя бы на несколько лет вперед varchar(12). Тем более, что с точки зрения производительности — разница мизерна