Повторные POST запросы.

хеш последнего запроса в куки класть.

Как раз это третий из известных - его и использую. Просто при некоторых действиях таких куков накапливается по несколько десятков... Или пофиг?

Просто при некоторых действиях таких куков накапливается по несколько десятков.

Так только последний POST запрос хранить надо. Не так уж много людей по сайту параллельно с двух вкладок ходят.

Именно потому что сам хожу с 2-3 вкладок запросто, стал хранить все. Достойного механизма как хранить последние 3-4 запроса не придумал.

Именно потому что сам хожу с 2-3 вкладок запросто, стал хранить все.

Ну значит, либо забить на таких пользователей, либо всю их сессию таскать 5 последних запросов (ограничить всё же надо).

Не вижу красивого способа ограничить кроме переписывания куков типа hash -> POST5 -> POST4 -> POST3 -> POST2 -> POST1

Это выглядит не экономно...

Хотя наверное можно добавить куку CURRENTPOST с указателем...

Хм. А это похоже на решение. Видимо так и надо.

Это выглядит не экономно...

Экономный вариант - хранить одну - последнюю. А так хоть кольцевой буфер делай, выглядит всё равно криво.

токен

ограничить количество вкладок? лоооол

ограничить количество вкладок? лоооол

Ограничить число таскаемых последних запросов. lol yourself ^_^

Плюнул на все и сделал хранение только последнего POST. Наверное ты прав - если кто и наткнется - ССЗБ.

Спасибо.

Э... Как?

Что токен?

аякс, не?

генеришь токен в сессии, вставляешь в формочку, в посте проверяешь совпадает или нет. Как бы это один из способов защиты от CSRF и должен присутствовать во всех запросах.

уже ответили
CSRF тебе ничего не говорит?

Как можно бороться с повторной отправкой данных в POST запросе,

А нельзя сделать, чтобы сайт просто не тормозил. Ведь, если пользователь умудрится за пол секунды, пока генерируется редирект на Get запрос к новой странице умудрится заново отправить запрос, то может и не париться с таким пользователем? Кроме тормозов сети и особо странных пользователей тут и не остается слабых мест.

Это второй способ который я знаю. Да я использую уникальный ключ в формах сохраненный в сессии пользователя. Но я хотел бы невозможности отправки повторного POST запроса даже если его форму, разрабы непосредственно уже сайта, воткнут прямо в html и она не будет генерируемой моим API.

Предлагаешь после получения POST запроса сразу же делать редирект? Это первый способ который я знаю. Он используется в BITRIX например. И он самый плохой на мой взгляд вот почему - представь что разраб добавляет некоторый допобработчик POST запроса. И встраивает его в свой модуль/компонент/etc. (в разных фреймворках/CMS по разному зовется). Но он не сможет получить данный из POST, потому что обработчик запросы выполняется раньше и после обработки он сразу выполнит редирект. В итоге до обработчика конкретного разраба не долетят данные POST запроса. Придется городить костыли.

Я напротив, даже получив повторный запрос просто очищаю массив POST, но перед этим перебрасываю данные в массив REPOST - мало ли для чего они разрабу понадобятся - у него в этом случае появится возможность как-то обработать даже повторный запрос.

от reload'а спасает redirect в том скрипте который обрабатывает форму

Повторные POST запросы. (комментарий)

ну тут проблема в твоей архитектуре на серверной стороне, а не в методе

Да - когда я столкнулся с этим я действительно городил костыль к подпорке. Но проблема был точно не в моей архитектуре. Подпорка была прилеплена до меня. Но то что запрос не проходит все обработчики это тоже костыль.

После удачной операции, делаешь редирект на страницу с сообщением об успехе. И нехай её релоадят до посинения.

Но он не сможет получить данный из POST, потому что обработчик запросы выполняется раньше и после обработки он сразу выполнит редирект.

А что мешает автору добавлять свой код в обработчик POST-а?

Конкретно мне в моей ситуации мешало то, что обработчик поста в стандартном компоненте и внедрить туда свой код - сделать компонент необновляемым.

представь что разраб добавляет некоторый допобработчик POST запроса. И встраивает его в свой модуль/компонент/etc. (в разных фреймворках/CMS по разному зовется).

Придется городить костыли.

Но ведь уже?

Уже где?

Уже в обработчике POST запроса.

Предлагаешь после получения POST запроса сразу же делать редирект?

Возможно, мы друг друга не правильно понимаем. После получения POST запроса сервер обрабатывает его и генерирует редирект, получив который браузер делает GET на другую страницу (обычно с результатами обработки предыдущего POST). Т.е. между получением POST и отправкой редиректа идет обработка запроса. Вот смысл в том, чтобы сделать эту обработку достаточно быстрой (причем это стандартны способ обработки POST).

А когда браузер сделает GET, получив редирект, его, как уже сказали, можно повторно отправлять до посинения.

Если же сервер дико тормозит сам по себе, то тут решения нужно принимать на другом уровне, а не пытаться сделать очередную хитрость, которая чуть улучшит ситуацию в одном месте, но сильно ухудшит во многих других.

P.S. Возможно, я чего-то не догоняю, тогда хотелось бы узнать чего именно (вполне возможно, что с такими задачами, как у тебя я не сталкивался...)

самое правильное решение на мой взгляд — использовать POST ТОЛЬКО внутри AJAX (и ни в коем случае НЕ напрямую из HTML-формочки)

но этот способ уже назвали. так-что я просто высказываю тут своё скромное мнение :)

принудительный GET after POST — самое простое и стандартное решение