Pull to refresh

Comments 62

К сожелению, без потери безопасности тут не обойтись. :-)
необоснованный поверхностный взгляд.
«на лету» не значит «на клиенте». все остальное есть лишь небольшие технические сложности.
Поверхностный? Мы же на хабре, уважаемый. :-) Хотите обоснование? Пожалуйста:

Вдумайтесь, какое счастье будет боту, что при подборе капчи еще и дополнительная помощь от сервера добавится. Одно дело, когда валидация происходит для всей капчи сразу и совсем другое, когда для каждого отдельного символа в процессе набора. Бот просто будет циклически менять символы, если вдруг один из символов сервер забраковал. Вероятность подобрать каптчу с первой же попытки для робота увеличивается в десятки раз. Смысл капчти становится, практически, нулевым.
Вы не видите леса на фоне деревьев.

Никто и не говорит о проверке ввода каждого символа.

Банально на jquery при нажатии на субмит аяксом проверяем все поля, включая капчу без перезагрузки страницы и, если есть невалидные поля, просто подчеркиваем их.
Тогда простите, но в чем новизна такого метода?
Новизны тут нет, я еще пару лет назад такое встречал.
Но все же спасибо автору что напомнил общественности об этом, так как подобные решения на данный момент крайне редки, чрезвычайно редки, невообразимо редки, несмотря на все удобство этого метода (хотя в нем есть и минусы, ниже в одном из комментов я это привел).
>>Никто и не говорит о проверке ввода каждого символа.
Ну как это никто не говорит? Сам автора топика это подтвердил, положительно ответив на это уточнение:
kaant.habrahabr.ru/blog/64202/#comment_1786552

Это значит, что exvel все правильно увидел, и, соответственно, разъяснил автору топика.
Может потому, что теряется весь смысл каптчи?
не теряется.
асинхронная валидация капчи до сабмита формы никак не препятствует в выполнении основной задачи капчи — резать ботов.
За исключением появления дополнительного условия: у пользователя должен быть включён Javascript
Стандартно, в подавляющем большинстве случаев, JS включен.
… многие капчи и так требуют JS, к сожалению. Только вот об этом они не всегда заранее (и вобще) предупреждают, в результате чего проверка просто фэйлится.
Если Javascript выключен, можно использовать старый, обычный способ — проверку введенного пользователем текста каптчи после сабмита формы.

Если Javascript включен — вполне можно использовать асинхронную проверку через AJAX. Это действительно удобно для пользователя. Только на сервере нужно делать дополнительную антифраудную проверку, чтобы перебором не баловались.
Разве это не еще одна возможность для ботов? Т.е. бот разве не сможет таким образом тоже узнать, правильно ввёл каптчу или нет и если нет, попробовать подобрать еще раз?
тоесть, вы наивно полагаете, что если не использовать этот метод и проверять каптчу по сабмиту, это помешает боту попробовать подобрать каптчу ещё раз? разумеется, после неправильной попытки, каптча будет обновлена.
Как я понимаю автора, смысл этого асинхронного запроса с точки зрения пользователя как раз в том, чтобы, в случае не уверенности в одной из букв, попробовать тут же исправиться именно с текущей капчей.
абсолютно верно )
ну да, «без потери безопасности», ага.
что-ж, хозяин-барин.
Ну можно ограничить пользователя 3-мя попытками, например, на каждую капчу.
А если стоит ограничение на колличество попыток регистрации в определённый промежуток времени?
ограничьте количество попыток и все снова станет секьюрненько.
Как на счет уменьшить искажения?
Как на счет не использовать в вашей капче I и l?
Как на счет добавить кнопку — обновить капчу, чтобы дало другую?
а он и не использует. он вообще не программист и капчи не писал.
топикстартер задал правильный вопрос с позиции юзера: «какого фига из-за хреновой капчи или опечатки приходится повторно заполнять форму?»

ответ на этот вопрос простой — потому что лениво :(
большинство девелоперов не озадачиваются вопросами юзабельности их «монстров», лишь бы ботов отсекало.
1. Дело в том, что, если уменьшить искажение, то можно, теоретически, считать код программными средствами.
2. Я только «ЗА», но многие продолжают использовать эти, и другие, неудобные символы.
3. Нуу, дело в том, что в ней могут также попасться эти символы :)
>>(например, как проверка логина и т.п.)
а как проверка логина и т.п. на лету?
Например после ухода с поля ввода пароля посылать асинхронный запрос к серверу для проверки того есть ли такой логин в базе. Как, например, сделано в Invision Power Board последних версий.
Тьфу, то есть конечно после ухода с поля логина.
в смысле, при выборе логина для регистрации, аяксом проверять, занят ли уже такой логин?
т.е. у бота будет не одна, а много попыток угадать каждую капчу?
генерируется капча и одновременно генерится код, который может быть, например, как-нибудь просто зашифрован. Код можно хранить в переменной, а после подтверждения или обновления удалять/обновлять.
Зачем? Не угадали капчу — генерим новую. По сути программное нажатие кнопки «Обновить картинку».
Но при таком подходе, как мне на первый полусонный взгляд кажется, будет некоторые проблемы с интеграцией той же reCaptch'и, то есть нужно будет писать свой генератор изображений.
p.s. А кстати это идея — сделать сервис вроде recaptcha.net, только с аяксовой проверкой.
а смысл? экономить нажатие Enter?
капча и так много где загружается и проверяется аяксом
Смысл в том, что я прокомментировал: «т.е. у бота будет не одна, а много попыток угадать каждую капчу?». При неверном наборе будет обновляться капча. Таким образом одну и ту же картинку бот не будет угадывать больше одного раза.
может просто делать более понятные капчи?
Более понятные для ботов?
Зачем это?
Капчи придумали для того чтобы защититься от ботов, а проверка правильности как раз облегчит им жизнь.
правильность проверяется в любом случае. в чем проверка одновременно с остальными данными безопаснее асинхронной проверки?
ну так проверка кода происходит в любом случае… ведь надо же как-то сравнить код на картинке с кодом, который ввел пользователь.
А разве это не было реализовано нигде?
например тут
Кстати на нескольких сайтах видел в работе, действительно удобно…

Больше раздражает когда нет кнопочки «обновить капчу».
о! Вот она, родимая! :) спасибо за ссылку.

ПС: на самом деле, реализовать можно все (ну или почти все), было бы желание.
ненавижу капчи
Хоть и сам разработчик, сам применяю иногда, но технология капчи должна умереть, по моему мнению.
Мне кажется стоит думать не как улучшить капчу, а как от неё избавится.
Сам для себя этот вопрос пока не смог решить, к сожалению.
в таком случае нужно пересажать всех спамеров. Но это не возможно, поэтому нужно искать способы защиты от них.
Как вариант, можно использовать «тестирование» перед регистрацией, т.е. перед тем как зарегистрироваться, пользователь должен ответить на несколько простых вопросов.

Или к примеру как на goha.ru:


Вообще, с картинками самый лучший вариант на мой взгляд.
Такое возможно только в том случае, если:

1. Если картинок миллионы, и постоянно добавляются новые. Но в этом случае нужно как минимум собрать столько картинок, чтобы еще небыло проблем с копирайтами, систематизировать их, написать для них вопросы. Потом их нужно где-то хранить, возможно в отдельном файлохранилище или базе данных, а это все ресурсы, производительность системы…

2. Если такие картинки каждый раз генерятся налету (к базовым картинкам-шаблонам добавляются тексты, накладываются фильтры, эффекты и т.д.). Но эти операции по изменению картинок весьма медленны, а, учитывая, что при показе формы нужно сгенерировать десятки таких картинок за раз, можно поставить крест на производительности системы (или выделять выделенный сервер для генерации картинок).

В противном случае бот запросто соберет все варианты картинок (хотя бы даже по их размеру и/или CRC32), и потом будет подставлять по мере необходимости.
UFO landed and left these words here
И на Хабре, и в любых других местах скопления веб-кодеров уже многократно обсуждался вопрос пользы арифметических или визуальных капч.
Дело в том, что провести некоторые арифметические операции — совсем не проблема для бота. А если уж эти числа у вас еще и не на картинке, а просто рядом набраны — вообще разговоров нет.
Сличить картинки с капчи тоже сильно проще, чем распознать символы — картинки сложно исказить до той степени, когда и человеку будет понятно что там нарисовано, и бот не сможет успешно сравнить их с оригиналом.
UFO landed and left these words here
Зато в один прекрасный день кто-нибудь сочинит такого бота, который станет захватывать изображение с экрана — и тогда на сайте резко появится на пятьдесят тысяч пользователей больше.

То же самое касается капч в формате SVG или в виде джаваскриптовых инструкций для холста <canvas>.

Рекапча радует хотя бы тем, что подсовывает те слова, которые заведомо не распозналися OCR.
UFO landed and left these words here
Зато в один прекрасный день кто-нибудь сочинит такого бота, который станет захватывать изображение с экрана

а тогда какая разница через какую технологию это изображение на экран попало?
iShift, тоже была мысль про флеш, но дело в том, что, в отличие от того же JS, флеш установлен не у всех.
JS тоже включён не у всех.
UFO landed and left these words here
Сложность в том, что реализация будет далеко не такой простой, как поначалу кажется, и то что получится будет тоже не без подводных камней. Итак, нужно:

1. проверять, включен ли Javascript, если не включен — использовать только старый метод, с проверкой каптчи после сабмита формы.

2. сделать AJAX реализацию для проверки введенного пользователем текста каптчи.

3. сделать на сервере антифраудную систему, прочем она и так должна была бы быть и в старом варианте, но в новом — просто обязана быть, так как попыток для перебора вариантов теперь у ботов будет намного больше. соответственно, чтобы избежать перебора вариантов, текст на каптче нужно делать довольно длинным, желательно не менее 8 символов, а вот это уже будет весьма неудобно для пользователя (вот он, подводный камень этого метода!).

А вообще очень хорошее и правильное предложение, это удобно для больших форм регистрации, особенно многостраничных.
На некоторых сайтах я такое уже видел, действительно, очень удобно.
Аналогично имеет смысл проверять логины, почтовые индексы (для тех стран где есть полная база данных), и т.д.

А вот для небольших форм типа логин+пароль+каптча — этот метод явно избыточен IMHO, хотя даже в этом случае может быть использован для «особо быстрых» пользователей.
P.S.
Только вот при отключении Javascript — кнопка Зарегестрировать не активна, и появляется сообщение:

Некоторые динамические элементы этой страницы не могут корректно отображаться и выполняться, из-за того что в Вашем браузере отключены функции Javascript.

Как верно заметил tvv, необходимо проверять на использование Javascript.
я правильно понимаю — введенные цифры отправляются на сервер, там проводится сверка и, в случае правильного ответа, отсылается подтверждение правильного ввода?
Да, после заполнения поля
идёт запрос:

POST /go/_reg/check_kod.php?PHPSESSID=3bfb8bf21dc4526cce7117241abf0a36&JsHttpRequest=12474861626000-xml HTTP/1.1

Передаваемые данные:

cod=48466
а, и код получается зашифрованным?
ну вот, тогда и боту будет трудно его разгадать.
а много у вас было автоматических регистраций с такой версией каптчи?
Подозрительных всплесков регистраций замечено не было.
Only those users with full accounts are able to leave comments. Log in, please.