Какие-то дебилы сыплют в мою гостевую книгу всякий хлам.
Дебилизм выражается в том, что гостевуха премодерируемая, и кроме меня, никто не увидит их энларджа.
Судя по разбросу IP — это зомби-нет, а не обычные анонимайзеры. Поэтому бан-лист не работает
Один раз поменял url странички — поток прервался где-то на месяц. Видимо, хозяин всё-таки пасёт её.
Что посоветуете?
Желательно, не громоздкое. Может быть, даже вообще текстовую капчу. А может, и без капчи можно обойтись?
И желательно, с комментариями — чтобы я научился (например, до сих пор не вкурил в механизм сессий).
У меня есть только для PHP5: работающий пример. Подогнать и проверить под PHP4 не могу — нет его у меня. Там, по идее, достаточно убрать в файле класса всякие public/private (у переменных заменить на var).
Аннотация: PHP5-класс CCaptcha, генерирует фразу и картинку для Теста Тьюринга. Гибкие настройки в конструкторе класса. Сгенерированную фразу записывает в $_SESSION['captcha'], картинку выводит напрямую вместе с заголовками, без временных файлов.
К>Что посоветуете? К>Желательно, не громоздкое. Может быть, даже вообще текстовую капчу. А может, и без капчи можно обойтись? К>И желательно, с комментариями — чтобы я научился (например, до сих пор не вкурил в механизм сессий).
Есть, например, reCaptcha. Помогает оцифровывать книги
Я у себя использую самописную функцию, предлагаюущую решить простенькую задачку типа 2+2:
К>Какие-то дебилы сыплют в мою гостевую книгу всякий хлам. К>Дебилизм выражается в том, что гостевуха премодерируемая, и кроме меня, никто не увидит их энларджа.
К>Судя по разбросу IP — это зомби-нет, а не обычные анонимайзеры. Поэтому бан-лист не работает К>Один раз поменял url странички — поток прервался где-то на месяц. Видимо, хозяин всё-таки пасёт её.
К>Что посоветуете? К>Желательно, не громоздкое. Может быть, даже вообще текстовую капчу. А может, и без капчи можно обойтись? К>И желательно, с комментариями — чтобы я научился (например, до сих пор не вкурил в механизм сессий).
К>Язык — PHP4.
Я сделал простое решение на клиенте, работает пока
<form action="break.php" ...> <!-- здесь ловушка для роботов - break.php не кладет данные в базу -->
...
<checkbox onclick="this.form.action='save.php'; this.form.elements['subm'].disabled=false;" /> - согласен (с чем угодно)
<input type="submit" name="subm" value="Отправить" disabled="disabled" />
</form>
принцип работы: без выбора галки не дает отпавить форму, при выборе меняет action у формы на правильный
Здравствуйте, ibnTeo, Вы писали:
T>Я сделал простое решение на клиенте, работает пока
T>
<form action="break.php" ...> <!-- здесь ловушка для роботов - break.php не кладет данные в базу -->
T>...
T><checkbox onclick="this.form.action='save.php'; this.form.elements['subm'].disabled=false;" /> - согласен (с чем угодно)
T><input type="submit" name="subm" value="Отправить" disabled="disabled" />
T></form>
T>принцип работы: без выбора галки не дает отпавить форму, при выборе меняет action у формы на правильный
По идее, можно сделать и без галочки — менять сразу при submit-е. Вот только за что я не люблю такие методики так за то, что они вообще делают невозможным работу формы при выключенном JS.
Кстати, «в тему»: наткнулся вчера на обсуждение небольшое о методах борьбы с зло-роботами (: — CSS и борьба со спамом.
<>
Боюсь, что такая капча элементарно ломается.
Спамер будет присылать POST-запрос с согласованной парой вопроса и ответа. Ведь не жмёт же компьютер-зомби кнопки на страничке?
То же касается и яваскрипта.
Поэтому и хочу разобраться с сессиями или другими механизмами диалога между сервером и клиентом.
К><> К>Боюсь, что такая капча элементарно ломается. К>Спамер будет присылать POST-запрос с согласованной парой вопроса и ответа. Ведь не жмёт же компьютер-зомби кнопки на страничке? К>То же касается и яваскрипта.
К>Поэтому и хочу разобраться с сессиями или другими механизмами диалога между сервером и клиентом.
Ну, значение $result можно и в сессию класть, а потом проверять Да и саму схему шифрования менять хоть десять раз на дню. Но это так, поделка
Кодт wrote:
> Боюсь, что такая капча элементарно ломается. > Спамер будет присылать POST-запрос с согласованной парой вопроса и > ответа. Ведь не жмёт же компьютер-зомби кнопки на страничке? > То же касается и яваскрипта. > Поэтому и хочу разобраться с сессиями или другими механизмами диалога > между сервером и клиентом.
Сессии и другие механизмы диалога делаются браузером, т.е. программой, а следовательно могут быть запрограммированны в
роботе. Только фигни типа посчитать арифметическое выражение нарисованное на картинке могут отшить роботов.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
1. Лучше всюду писать <?php вместо <? (хотя у большинства хостеров включена deprecated-опция short tags, из-за чего приходится, например, при генерации XML писать так: echo '<' . '?xml ...')
2. На случай вызова showform() из обработчика ошибок, следовало бы подставлять в поля формы ранее введённые юзером значения (что-то типа <input ... value="<?php = @_REQUEST['...']'; ?> .../>, если подавление hint-ов с помощью '@' тебя не смущает).
Здравствуйте, ., Вы писали:
.>Сессии и другие механизмы диалога делаются браузером, т.е. программой, а следовательно могут быть запрограммированны в роботе. Только фигни типа посчитать арифметическое выражение нарисованное на картинке могут отшить роботов.
Сессии только наполовину делаются браузером. На другую половину — таки сервером.
Кодт wrote:
> Сессии только наполовину делаются браузером. На другую половину — таки > сервером.
Клиент легко может при каждом запросе создавать новую сессию (или если совсем крутой робот, то брать из пула ранее
начатых). Так что "серверная часть" никакой роли играть не может.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ., Вы писали:
.>Клиент легко может при каждом запросе создавать новую сессию (или если совсем крутой робот, то брать из пула ранее начатых). Так что "серверная часть" никакой роли играть не может.
Ну и что он с этого добьётся? Ну наоткрывает новых сессий, ни в одной из них капчу правильно не введёт, этим всё и закончится.
Кодт wrote:
> .>Клиент легко может при каждом запросе создавать новую сессию (или если > совсем крутой робот, то брать из пула ранее начатых). Так что "серверная > часть" никакой роли играть не может. > > Ну и что он с этого добьётся? Ну наоткрывает новых сессий, ни в одной из > них капчу правильно не введёт, этим всё и закончится.
Аа.. Ты людей прошедших капчу хочешь запоминать? Тогда ладно. Просто ты упоминул это дело в контексте "капча элементарно
ломается", вот я и подумал, что ты хочешь придумать как использовать сессии для усиления капчи, я просто хотел сказать,
что сессии помочь ничем не могут.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ., Вы писали:
>> Ну и что он с этого добьётся? Ну наоткрывает новых сессий, ни в одной из >> них капчу правильно не введёт, этим всё и закончится. .>Аа.. Ты людей прошедших капчу хочешь запоминать? Тогда ладно. Просто ты упоминул это дело в контексте "капча элементарно ломается", вот я и подумал, что ты хочешь придумать как использовать сессии для усиления капчи, я просто хотел сказать, что сессии помочь ничем не могут.
Запоминать мне их не надо. Сценарий примерно такой:
1) юзер кликнул в гостевухе на "добавить": открыл сессию, создал вопрос-ответ; показал страницу ввода с этим вопросом
2) получил post-запрос с ответом: (повторно) открыл сессию; сравнил со значением, запомненным на сервере; записал в базу; закрыл сессию
Если спамбот сразу прыгнет на (2) — в сессии не будет контрольного значения, и я пошлю его нафиг.
Только нужно таймаут у сессии выставить — чтобы не хранить хлам на сервере.
А пока что я сделал ещё проще: дебильный байесвский фильтр.
Если в тексте сообщения нет русских букв — это спам
Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>2. На случай вызова showform() из обработчика ошибок, следовало бы подставлять в поля формы ранее введённые юзером значения
В настоящей гостевухе так и сделано. Здесь был макет.
Но, пожалуй, я её немножко отрефакторю.
ДГ> (что-то типа <input ... value="<?php = @_REQUEST['...']'; ?> .../>, если подавление hint-ов с помощью '@' тебя не смущает).
А что за тема с хинтами? Еггог, если элемент массива отсутствует?
Здравствуйте, Кодт, Вы писали:
ДГ>> (что-то типа <input ... value="<?php = @_REQUEST['...']'; ?> .../>, если подавление hint-ов с помощью '@' тебя не смущает).
К>А что за тема с хинтами? Еггог, если элемент массива отсутствует?
Если ты обращаешься к несуществующей переменной, e.g. к несуществующему элементу массива $_REQUEST['xxx'], то будет сгенерировано предупреждение уровня NOTICE (самое слабое). Чтобы оно не выводилось в стандартный вывод (красным текстом), можно поступить двояко:
1) гасить вывод всех сообщений определённого уровня с помощью error_reporting(E_ALL & ~E_NOTICE);
2) гасить вывод всех сообщений для конкретного оператора с помощью префикса '@', например:
— @$_REQUEST['xxx'] — гасится вывод сообщения "Undefined variable";
— @imap_open(...), @unlink(...) — гасится вывод сообщений из методов (при этом функции работают без изменений, т.е. остаются доступными коды возвратов и imap_errors()).
Однако, оба эти способа подавления отладочного вывода не катят, если ты инсталлируешь обработчик ошибок через set_error_handler() — например, для журналирования. Обработчик будет вызываться с типом ошибки NOTICE, даже если ты напишешь @$_REQUEST['xxx'], в итоге журнал будет засоряться всякой фигнёй. Поэтому я обычно оборачиваю работу с $_REQUEST в простенький класс, чтобы избежать генерации "Undefined variable" NOTICE:
и с реализациями для $_REQUEST и raw-posted XML. Тут, правда, проблемы с нормальной обработкой ошибок (с генерацией контекстно-зависимых и локализованных сообщений), но в целом идея себя оправдывает.