Qual è il requisito per il browser per mostrare il messaggio onnipresente "questa pagina è scaduto" quando l'utente preme il pulsante Indietro?mostra "pagina web è scaduta" sul pulsante Indietro
Quali sono alcuni modi semplici per impedire all'utente di utilizzare il pulsante Indietro in una webapp?
Bene, per impostazione predefinita ogni volta che si ha a che fare con un modulo POST, e quindi l'utente esegue un riscontro e quindi aggiorna, vedrà il messaggio che indica che il browser sta inviando nuovamente i dati. Ma se la pagina è impostata per scadere immediatamente, non sarà nemmeno necessario effettuare il refresh e vedranno la pagina scaduta quando torneranno indietro.
Per evitare entrambi i messaggi ci sono un paio di cose da provare:
1) usare una forma GET invece. Dipende da cosa stai facendo, ma questa non è sempre una buona soluzione dato che ci sono ancora restrizioni sulle dimensioni di una richiesta GET. E le informazioni sono passate nella querystring che non è la più sicura delle opzioni.
- o -
2) Eseguire un server-side redirect ad una pagina diversa dopo il form POST.
Sembra una domanda simile è stato risposto qui:
Come terza opzione si potrebbe impedire a un utente di tornare nel loro browser a tutti. L'unica volta che ho sentito il bisogno di fare questo è stato di impedire loro di fare qualcosa di stupido come pagare due volte. Sebbene ci siano migliori metodi sul lato server per gestirlo. Se il tuo sito utilizza sessioni, puoi impedire che paghino due volte prima disabilitando la cache nella pagina di checkout e impostando la scadenza immediatamente. E poi puoi usare una bandiera di qualche tipo memorizzata in una sessione che cambierà il comportamento della pagina se torni indietro.
è necessario impostare l'opzione di controllo pragma-cache nelle intestazioni HTTP: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9
Tuttavia, dal punto di vista dell'usabilità, questo è l'approccio alla materia scoraggiato. Ti incoraggio fortemente a cercare altre opzioni.
ps: come proposto da Steve, il reindirizzamento tramite GET è il modo corretto (o controllare il movimento della pagina con JS).
Non sono sicuro se si tratta di una procedura standard, ma in genere risolvo questo problema non inviando un'intestazione Vary solo per IE. In Apache, è possibile inserire la seguente in httpd.conf:
BrowserMatch MSIE force-no-vary
Secondo il RFC:
Il Vary valore del campo indica l'insieme di campi request-header che completamente determina, mentre la risposta è fresca, se una cache è autorizzata a utilizzare la risposta per rispondere a una richiesta successiva senza ricontrazione .
L'effetto pratico è che quando si ritorna "indietro" a un POST, IE ottiene semplicemente la pagina dalla cache della cronologia. Nessuna richiesta va al lato server.Posso vederlo chiaramente in HTTP Watch.
Sarei interessato a conoscere potenziali effetti collaterali negativi di questo approccio.
uso una delle seguenti operazioni prima session_start:
session_cache_expire(60); // in minutes
ini_set('session.cache_limiter', 'private');
/Nota:
Lingua è PHP
compreso quale lingua sarebbe utile – mkoryak
meglio sarebbe per progettare la tua app in modo che il pulsante Indietro abbia un significato ragionevole. Trovo esasperante quando non sono autorizzato a usare il pulsante Indietro. – Peter
Peter, sono d'accordo. Ci sono momenti (come la procedura di checkout di un sito di e-commerce) quando potresti essere tentato di impedire all'utente di tornare indietro. Tuttavia, c'è una migliore soluzione lato server per quel problema che suggerisco nella mia risposta. –
@Peter, sono completamente d'accordo, ma ho a che fare con i flussi di lavoro, quindi il pulsante Indietro non si applica qui. – mkoryak