К слову при сабмите формы происходит проверка по на мультисабмит (с помощью токенов и сессий) . Во время проверки обнаружилось, что это повторный запрос и при этом предыдущий ещё не завершён . Как в таком случае запретить повторный сабмит и при этом не прерывать тот запрос , который ещё не завершился ?
На клиентской стороне необходимо делать проверки, блокировать кнопки и и.п., а так же и на фронте и на бэке использовать correlation token. Чтобы одна форма дважды не приводила к успешной обработке
На стороне клиента кнопка блокируется. Также есть проверка на стороне сервера, а вот что делать, если проверка вернула false (то есть обнаружен повторный сабмит)
Иван Шумов, В данном случае использую ларавел и сравниваю токены из сессии с токеном из Request. Если совпадают перезаписываю токен в сессии, а если нет то возвращаю false
netrox, не очень прозрачно. При генерации формы генерируйте в форму скрытое поле с токеном (форм-то может быть много, технически). На сервере проверяйте, например, в memcached или Redis наличие этого токена. Если есть - возвращайте http code 422 и забывайте. Токены в кэше храните, допустим, на сутки, а в виде токена используйте guid
Иван Шумов, Ну да в ларавел предусмотренно скрытое поле с токеном, которые посылается в теле запроса. И потом уже его значение сравнивется со значением токена в сессии . А клиент ожидает редиректа , возвращая ошибку http 422 она отобразится у него и редиректа уже не будет
Иван Шумов ,А в случае если нужен редирект? А можно ли как то дождаться завершения первого запроса и при этом игнорировать лишние запросы (без вывода ошибок клиенту) ?
Чем совершается запрос? jQuery? Если да - ждать ответа и не давать выполнять onSubmit, пока предыдущий не выполнен (успешно или нет - без разницы, главное, чтобы не было лишних).
Без проверки на клиентской стороне - вам никак не запретить создание второго запроса пока не выполнен первый. Вы только можете делать то, что вы уже делаете - проверять токены на бэке и смотреть, но да, если это из браузера - второй запрос прервёт первый.
Иван правильно пишет ниже - такое поведение должно "обрабатываться" на клиенте - на время исполнения запроса блокировать кнопки и, желательно, но не обязательно, - блокировать повторные запросы пока самый первый не выполниться, после выполнения первого - разблокировали кнопку и позволили отправить следующий, если нужно выполнили ещё что-то (редирект/оповещение и т.д.).
xtress, На стороне клиента блокируется кнопка. Допустим на стороне сервера было выявлено, что это повторный запрос и при этом первый ещё на завершён (после завершения следует редирект) как "блокировать" такой запрос ?
Помимо того, что вам советует Иван выше, я бы предложил, как вариант, что-нибудь такое - tpcg.io/MvE83q . Это не даст повторно засабмитить форму, пока первый запрос не выполнен, проверка на клиенте.
Это, имхо не самый лучший вариант. В качестве других вариантов можно рассмотреть ответы отсюда: https://stackoverflow.com/questions/2830542/preven...
