Защита от повторной обработки POST запроса

[SeoTron]

Поместил в WEB-разработку, полагаю наиболее подходит.

[KrasivayaSvo]

Мне кажется в некоторых случая достаточно будет md5-хеша не изменяемых данных транзакции (например, без учета id и даты времени).

[Power]

А если пользователь в рамках сессии откроет больше одной вкладки?

[dohlik]

Имя для ключа сессии тоже можно генерировать (и передавать в $_POST).

[SeoTron]

Вообще, метод никоим образом не работает, если форму отправляет бот, который не принимает и не отдает куки.

[Fortop]

Сессия вообще-то может работать без кук.

[SeoTron]

Тоже неплохой вариант

[SeoTron]

Есть ли что-то с защитой от ботов, которые не принимают и не передают куки?

[Fortop]

В чем прикол? Чем не подошел обычный редирект без этого бубна?

[maxatwork]

Вот вот.
После обработки формы сделать редирект на другую страницу можно ведь.

[SeoTron]

Защита от невыполнения редиректа. Не разу разьве не видели, когда отправляешь форму, браузер зависает в режиме «скачано 0/0». Данные POST уже отправлены, а результаты выполнения скрипта, и Ваш редирект планируемый браузер не взял. Случается такое с не очень качественным интернетом, тем же gprs. Не дождавшись результата — пользователь может обновить страницу, остановить и иобновить — и данные передадутся вновь, и никакой редирект не спасет.

Ну конечно, в говнокодинге это лишнее, используйте редирект.

[barker]

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

[eugeneorlov]

То что Вы предлагаете реализовать на самом деле является классической защитой от CSRF.

[IGlukhov]

Не только от CSRF.

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

[eugeneorlov]

А это тоже CSRF — сейчас этот термин несколько расширен и, конечно, правильнее было бы просто RF. Метод не просто эффективный, а вообще непробиваемый, как показала моя практика.

[IGlukhov]

Расширять его таким образом, на мой взгляд, неправомерно.
Просто многие рассуждающие на эту тему плохо представляют суть вопроса.

В данном случае речь идёт об RF, но совсем не CS.

[vimruler]

А почему нельзя ключ хранить в $_SESSION?

[Evengard]

Не понимаю зачем такие сложности с «уникальным ключом» и всё такое… Всё проще! При переходе на страницу формы делаем:

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

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

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

Что нужно больше?? И никаких вам запросов в базу

[Evengard]

12345 — уникальный идентификатор каждой формы (типа 123 — для авторизации, 124 — для транзакциии тд), дабы позволить пользователям вбивать сразу в несколько форм одновременно…

[SeoTron]

Что нужно больше? Как Ваш метод защищает от долблений в форму ботов, которые не передают и не принимают печеньки?

[Evengard]

Сессия — та же печенька :D главное правильно настроить веб сервер )
Нет печеньки — нет переменной $_SESSION[«formId12345InputAllowed»] — нет ввода данных )
Здесь просто в качестве уникального ключа используется SessionID и всё )