Планирую форму регистрации на аяксе. Примерно с такой логикой:
- Если у пользователя отключен JS, то вместо формы появляется сообщение вроде "для доступа к этой странице требуется включить JavaScript "
- Сначала проверяются все поля на правильность заполнения, капча и тд. И только если все нормально, данные отсылаются на сервер.
Так вот, если на сервер пришли неправильные данные, значит они левые и пришли в обход формы? Так ведь?
И если так, то есть ли смысл при обнаружении любых ошибок в пришедших данных прекращать работу обработчика аякс-запроса и выдавать какую-нибудь страницу ошибки?
Типа, если какой-то ганд... плохой человек шлет пост-запросы на обработчик, то попадает на страницу ошибки.
Полная Версия: Скрипт-обработчик ajax-запроса
Да
| Цитата |
| Если у пользователя отключен JS |
не боись, это уже не пользователь. это неандерталец
_____________
HTML, CSS (Bootstrap), JS(JQuery, ExtJS), PHP, MySQL, MSSql, Posgres, (TSql, BI OLAP, MDX), Mongo, Git, SVN, CodeIgnater, Symfony, Yii 2, JiRA, Redmine, Bitbucket, Composer, Rabbit MQ, Amazon (SQS, S3, Transcribe), Docker
| Цитата (Игорь_Vasinsky @ 8.05.2017 - 20:43) | ||
не боись, это уже не пользователь. это неандерталец |
Просто, напримет, тут https://badoo.com/signup/?display_errors=1
если отключить JS, то форма ВРОДЕ БЫ ЕСТЬ, и даже отправляется, но работает через жо.
Как-то это, не знаю кхм, неофициально выглядит, что-ли)
| Цитата (walerus @ 8.05.2017 - 20:42) |
| Да |
Типа, я создал поддельную форму, чтобы слать post-данные на скрипт обработчик ajax-запроса:
- отправил в поле 'login' логин уже существующего пользователя.
- Хоппа!!! 404.php
А нормальный пользователь , который использует форму, либо ничего не может отправить, либо отправляет только правильные данные.
И он либо никуда не попадет со страницы с формой при сабмите (пока все как следуюет не заполнит), либо попадет на страницу с уведомлением о том, что зарегистрирован.
| Цитата (Raymond @ 8.05.2017 - 19:25) |
Типа, я создал поддельную форму, чтобы слать post-данные на скрипт обработчик ajax-запроса: - отправил в поле 'login' логин уже существующего пользователя. - Хоппа!!! 404.php |
Детский сад вторая четверть.
Ты никогда не получишь 100% гарантии, что это именно аякс запрос пришел.
И заморачиваться на этом (аякс / не аякс) не нужно. Лишние телодвижения.
Аякс - это не метод защиты, а асинхронный фоновый метод передачи данных.
Вот и исользуй его для асинхронной фоновой передачи данных.
А защищать регистрацию от ботов нужно по-другому.
_____________
[продано копирайтерам]
| Цитата (AllesKlar @ 9.05.2017 - 01:23) |
| Детский сад вторая четверть. |
А что тогда делать в таком случае? Подскажи, у меня мало опыта.
Просто, я имел ввиду зачем париться с заведомо левыми данными, если можно кинуть на страницу с ошибкой?
| Цитата (Raymond @ 9.05.2017 - 08:47) |
| Просто, я имел ввиду зачем париться с заведомо левыми данными, |
Как ты определяешь, что данные "левые"?
_____________
[продано копирайтерам]
| Цитата (AllesKlar @ 9.05.2017 - 14:48) | ||
Как ты определяешь, что данные "левые"? |
Потому, что если они неправильные (не проходят серверную проверку), значит не были проверены предварительно яваскриптом. если не были проверены предварительно - значит 100% левые же.
Raymond
ну если данные не валидные выводишь сообщение об ошибках и всего то.
Вообще серверная и клиентская валидация имеет разное назначение.
ну если данные не валидные выводишь сообщение об ошибках и всего то.
Вообще серверная и клиентская валидация имеет разное назначение.
| Цитата (Raymond @ 9.05.2017 - 19:26) |
| Потому, что если они неправильные (не проходят серверную проверку), значит не были проверены предварительно яваскриптом. если не были проверены предварительно - значит 100% левые же. |
Я не спрашиваю "почему", я спрашиваю "как"?
Какие критерии?
_____________
[продано копирайтерам]
Raymond
Ты же сам написал:
Ты же сам написал:
| Цитата |
| - Сначала проверяются все поля на правильность заполнения, капча и тд |
Если капча самописная, т.е. не гугл капча например, то это один вопрос, если гугл капча, то уже 50% проблема от ботов (левых пост форм и т.д.) решена. Что мешает использовать параметр в сессии ?, левая форма уже не прокатит, если конечно не будет залита на сервер.
| Цитата (AllesKlar @ 9.05.2017 - 22:52) |
| Я не спрашиваю "почему", я спрашиваю "как"? Какие критерии? |
Не соответствуют регуляркам логин и пароль, или пришел логин, который уже есть в БД и так далее.
Обычный пользователь может отправить только верные данные на сервер. Неправильные - значит пришли не пойми откуда
| Цитата (walerus @ 10.05.2017 - 01:40) |
| Если капча самописная, т.е. не гугл капча например, то это один вопрос, если гугл капча, то уже 50% проблема от ботов (левых пост форм и т.д.) решена. Что мешает использовать параметр в сессии ?, левая форма уже не прокатит, если конечно не будет залита на сервер. |
Тут вопрос больше не защиты, а того, зачем выполнять какие-то лишние действия
при получении практически 100% некорректного обращения к скрипту)
Это ведь почти то же самое, что отсутствие (не пустота) какого-то ожидаемого ключа $_POST-массива .
Кстати да, пользуясь случаем, хотел спросить - что обычно нужно делать , если
отсутствует ожидаемый ключа $_POST-массива . например, ждешь в обработчике $_POST['login'], но isset($_POST['login']) == false?
Raymond Как написал выше AllesKlar, ты никогда не узнаешь от кого пришел запрос на AJAX обработчик, т.е. от твоего скрипта или же от "локалки"... Я могу перехватить данные которые отправляются на AJAX обработчик и сделать такой же запрос на локалке... обработчик в любом случае должен вернуть FALSE или TRUE или что то иное тобою придуманное, может ты захочешь кодировать ответ в sha256 или еще как, это твое дело, НО!, ответ от обработчика должен быть однозначно, не зависимо от того все поля пришли или нет, на то он и обработчик...
То что включена ява или нет, это уже другой вопрос, это проверка на стороне клиента так сказать и по идее, если ява выключена, то и запрос на аякс не должен вообще поступить, но "умельцев" масса, которые разберут запрос по косточкам и будут писать "постеры", заваливая твой обработчик( и сервер ) бесконечными многоканальными запросами, так вот самое простое, на мой взгляд, использовать сессию... - нет параметра в сессии - сразу на выход, если есть, то уже тогда подключать базу, проверять имена... явки... пароли...
То что включена ява или нет, это уже другой вопрос, это проверка на стороне клиента так сказать и по идее, если ява выключена, то и запрос на аякс не должен вообще поступить, но "умельцев" масса, которые разберут запрос по косточкам и будут писать "постеры", заваливая твой обработчик( и сервер ) бесконечными многоканальными запросами, так вот самое простое, на мой взгляд, использовать сессию... - нет параметра в сессии - сразу на выход, если есть, то уже тогда подключать базу, проверять имена... явки... пароли...
| Цитата |
| что обычно нужно делать , если отсутствует ожидаемый ключа $_POST-массива . например, ждешь в обработчике $_POST['login'], но isset($_POST['login']) == false? |
1) выдавать ошибку отправки формы ( не все поля заполнены и т.п. )
2) редиректить на пункт правил о читинге
3) заносить в базу подобных юзеров (IP, броузер, размер экрана и т.д.) что бы потом блокировать на определенное время( было в соседней ветке про блокировку при ошибочных вводах )
...
n) Ничего не делать
Все что угодно в общем
Здесь расположена полная версия этой страницы.