Como evitar envio de vários formulários quando o usuário recarrega a página

5

Atualmente, estou trabalhando em um projeto que exige a integração de uma API SOAP de terceiros para lidar com várias operações básicas do tipo CRUD.

Nossa implementação atual nos permite alavancar as classes de validação de formulários do framework Laravel antes da execução desses dados de solicitações de API; No entanto, tenho algumas preocupações, já que não estamos aproveitando qualquer tipo de mecanismo de enfileiramento.

A pilha de soluções atuais envolve sobrecarregar o servidor da Web NGINX para gerar funcionários adicionais para cada solicitação de usuário de bloqueio. Obviamente, isso pode levar a alguns problemas em termos de escalabilidade.

Existe também a possibilidade de os usuários "atualizarem" frequentemente as páginas depois de enviar os dados da solicitação de formulário.

Eu estive pesquisando o Post / Redirect / Get pattern como uma possível solução. Não tenho certeza se entendi completamente o conceito.

Aqui está uma citação de uma discussão do :

  1. The client gets a page with a form.

  2. The form POSTs to the server.

  3. The server performs the action, and then redirects to another page.

  4. The client follows the redirect.

Como dito acima, essas são chamadas de API longas e a etapa 3 pode levar mais de 10 segundos para concluir a execução - o que impede o usuário de atualizar continuamente a página após a etapa 2?

    
por user2308097 05.07.2015 / 23:33
fonte

3 respostas

3

Eu também respondi essa pergunta no StackOverflow - coloco minha resposta aqui para referência fácil ...

O padrão PRG não impedirá isso, já que a ação P leva tempo (o que geralmente é o caso) e o usuário pode enviar o formulário novamente (por meio de clique ou atualização do navegador), o que fará com que o padrão PRG seja "falhar".

Observe que os usuários mal-intencionados também podem ignorar todas as medidas do lado do cliente executando várias postagens http em uma sucessão rápida.

Uma solução para todos os itens acima é verificar se há envios duplicados no servidor contra seu token anti-falsificação.

Se você usar um token anti-falsificação oculto em seu formulário (como deveria), poderá armazenar em cache o token anti-falsificação no primeiro envio e remover o token do cache, se necessário, ou expirar a entrada em cache após o conjunto quantidade de tempo.

Em seguida, você poderá verificar com cada solicitação no cache se o formulário específico foi enviado e rejeitá-lo, se houver.

    
por 26.04.2016 / 11:31
fonte
1

Acho que, conforme o padrão PRG, se houver uma atualização após a etapa 2, não haverá um problema, pois o cliente (navegador) receberá e usará a URL de redirecionamento.

O problema acontece quando o usuário atualiza antes da conclusão da etapa 2 (antes de enviar o URL de redirecionamento)!

    
por 06.07.2015 / 01:47
fonte
0

A solução de servidor com tokens exclusivos é mais robusta, mas não tão amigável. Não é uma ótima experiência do usuário esperar que uma página seja carregada e receba erros no recarregamento.

No lado do cliente, você pode reformular para usar solicitações de XHR com dicas de interface do usuário que os dados estão processando e rejeitando qualquer envio / solicitação antes que a resposta seja recebida.

    
por 03.08.2018 / 16:41
fonte