Pull to refresh

Comments 22

Поместил в WEB-разработку, полагаю наиболее подходит.
Мне кажется в некоторых случая достаточно будет md5-хеша не изменяемых данных транзакции (например, без учета id и даты времени).
UFO just landed and posted this here
А если пользователь в рамках сессии откроет больше одной вкладки?
Имя для ключа сессии тоже можно генерировать (и передавать в $_POST).
Вообще, метод никоим образом не работает, если форму отправляет бот, который не принимает и не отдает куки.
Сессия вообще-то может работать без кук.
Тоже неплохой вариант
Есть ли что-то с защитой от ботов, которые не принимают и не передают куки?
В чем прикол? Чем не подошел обычный редирект без этого бубна?
Вот вот.
После обработки формы сделать редирект на другую страницу можно ведь.
Защита от невыполнения редиректа. Не разу разьве не видели, когда отправляешь форму, браузер зависает в режиме «скачано 0/0». Данные POST уже отправлены, а результаты выполнения скрипта, и Ваш редирект планируемый браузер не взял. Случается такое с не очень качественным интернетом, тем же gprs. Не дождавшись результата — пользователь может обновить страницу, остановить и иобновить — и данные передадутся вновь, и никакой редирект не спасет.

Ну конечно, в говнокодинге это лишнее, используйте редирект.
На самом деле почти везде (в известных движках) в таких случаях используется редирект, почему сразу гавнокодинг. С другой стороны везде идёт вдобавок проверка по ключу. Методы никак друг другу не противоречат, а, наоборот, успешно дополняют. В чём проблема редиректа то?
То что Вы предлагаете реализовать на самом деле является классической защитой от CSRF.
Не только от CSRF.

Я так отшиваю тупых спамботов, которые пытаются кидать свои запросы минуя страницу с формой.
В моём случае это 98% всего спама, так что метод оказывается очень эффективен.
А это тоже CSRF — сейчас этот термин несколько расширен и, конечно, правильнее было бы просто RF. Метод не просто эффективный, а вообще непробиваемый, как показала моя практика.
Расширять его таким образом, на мой взгляд, неправомерно.
Просто многие рассуждающие на эту тему плохо представляют суть вопроса.

В данном случае речь идёт об RF, но совсем не CS.
А почему нельзя ключ хранить в $_SESSION?
Не понимаю зачем такие сложности с «уникальным ключом» и всё такое… Всё проще! При переходе на страницу формы делаем:

//не забудьте проинициализировать сессию
$_SESSION[«formId12345InputAllowed»] = true;

При отправки в форму вот такой:

//не забудьте проинициализировать сессию
if($_SESSION[«formId12345InputAllowed»] == true)
{
unset($_SESSION[«formId12345InputAllowed»] );
// дальше то что вам нужно с формой этой делать
}
else
{
echo «error!»;
die();
}

Что нужно больше?? И никаких вам запросов в базу
12345 — уникальный идентификатор каждой формы (типа 123 — для авторизации, 124 — для транзакциии тд), дабы позволить пользователям вбивать сразу в несколько форм одновременно…
Что нужно больше? Как Ваш метод защищает от долблений в форму ботов, которые не передают и не принимают печеньки?
Сессия — та же печенька :D главное правильно настроить веб сервер )
Нет печеньки — нет переменной $_SESSION[«formId12345InputAllowed»] — нет ввода данных )
Здесь просто в качестве уникального ключа используется SessionID и всё )
Sign up to leave a comment.

Articles