Come impedire l'invio di più moduli quando l'utente ricarica la pagina

5

Attualmente sto lavorando a un progetto che richiede l'integrazione di un'API SOAP di terze parti per gestire un numero di operazioni di tipo CRUD di base.

La nostra attuale implementazione ci consente di sfruttare le classi di convalida dei moduli del framework Laravel prima dell'esecuzione di questi dati delle richieste API; tuttavia nutro qualche preoccupazione poiché non stiamo sfruttando alcun tipo di meccanismo di accodamento.

L'attuale stack di soluzioni comporta un pesante onere sul server Web NGINX per generare ulteriori worker per ogni richiesta dell'utente bloccante. Ovviamente, questo potrebbe portare ad alcuni problemi in termini di scalabilità.

C'è anche la possibilità che gli utenti aggiornino frequentemente le pagine dopo aver inviato i dati di richiesta del modulo.

Ho esaminato il Post / Redirect / Get pattern come possibile soluzione, tuttavia Non sono abbastanza sicuro di capire completamente il concetto.

Ecco una citazione da una discussione stackoverflow :

  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.

Come indicato sopra, si tratta di chiamate API lunghe e il passaggio 3 potrebbe richiedere fino a 10 secondi per completare l'esecuzione: cosa impedire all'utente di aggiornare continuamente la pagina dopo il passaggio 2?

    
posta user2308097 05.07.2015 - 23:33
fonte

3 risposte

3

Ho risposto a questa domanda anche su StackOverflow - Ho posto la mia risposta qui per un facile riferimento ...

Il pattern PRG da solo non lo impedirà, poiché l'azione P in esso richiede tempo (che di solito è il caso) e l'utente può inviare di nuovo il modulo (tramite clic o aggiornamento del browser), che farà sì che il pattern PRG "fail".

Tieni presente che gli utenti malintenzionati possono anche ignorare tutte le misure del lato client eseguendo più post http in rapida successione.

Una soluzione a tutto quanto sopra è verificare la presenza di invii duplicati sul lato server rispetto al token anti-contraffazione.

Se utilizzi un token anti-contraffazione nascosto nel tuo modulo (come dovresti), puoi mettere in cache il token anti-contraffazione al primo invio e rimuovere il token dalla cache, se necessario, o scadere la voce nella cache dopo il set quantità di tempo.

Sarai quindi in grado di verificare con ogni richiesta sulla cache se il modulo specifico è stato inviato e rifiutarlo se lo è.

    
risposta data 26.04.2016 - 11:31
fonte
1

Penso che secondo lo schema PRG se c'è un aggiornamento dopo il passaggio 2 non ci sarà un problema come il client (browser) riceverà e userà l'url di reindirizzamento.

Il problema si verifica quando l'utente si aggiorna prima che venga completato il passaggio 2 (prima di inviare l'URL di reindirizzamento)!

    
risposta data 06.07.2015 - 01:47
fonte
0

La soluzione server con token unici è la più robusta, ma non così facile da usare. Non è una buona esperienza utente aspettare che una pagina venga caricata e ricevere errori durante il caricamento.

Sul lato client è possibile riprogettare per utilizzare le richieste XHR con suggerimenti UI che i dati stanno elaborando e rifiutando qualsiasi invio / richiesta, prima che la risposta sia ricevuta.

    
risposta data 03.08.2018 - 16:41
fonte

Leggi altre domande sui tag