Cuál es el requisito para el navegador para mostrar el ubicuo "esta página ha caducado" mensaje cuando el usuario pulsa el botón de retroceso?espectáculo "página web ha expirado" en el botón de regreso
¿Cuáles son algunas maneras fáciles de usar para prevenir que el usuario utilice el botón de retroceso en una aplicación web?
Bueno, por defecto cada vez que usted está tratando con un POST forma, y luego el usuario golpea en la espalda y luego actualice a continuación, van a ver el mensaje que indica que el navegador se vuelve a presentar los datos. Pero si la página está configurada para caducar inmediatamente, entonces ni siquiera tendrán que presionar actualizar y verán que la página ha caducado cuando devuelven el mensaje.
para evitar tanto los mensajes hay un par de cosas para probar:
1) utiliza un formulario GET lugar. Depende de lo que esté haciendo, pero esta no siempre es una buena solución ya que todavía hay restricciones de tamaño en una solicitud GET. Y la información se transmite en la cadena de consulta, que no es la opción más segura.
- o -
2) Realizar una del lado del servidor redirigir a una página diferente después de la forma POST.
Parece una pregunta similar fue respondida aquí:
Como tercera opción se podría evitar que un usuario que se remonta en su navegador en absoluto. La única vez que sentí la necesidad de hacer esto fue para evitar que hagan algo estúpido, como pagar dos veces. Aunque hay mejores métodos del lado del servidor para manejar eso. Si su sitio utiliza sesiones, puede evitar que paguen dos veces deshabilitando primero el caché en la página de pago y configurando su caducidad inmediatamente. Y luego puede utilizar una bandera de algún tipo almacenada en una sesión que realmente cambiará el comportamiento de la página si regresa a ella.
debe configurar la opción de control pragma-caché en las cabeceras HTTP: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9
Sin embargo, desde el punto de vista de la facilidad de uso, este es el enfoque desanimado a la materia. Le recomiendo encarecidamente que busque otras opciones.
ps: según lo propuesto por Steve, a través de la redirección GET es la forma correcta (o comprobar el movimiento página con JS).
no estoy seguro si esto es una práctica habitual, pero por lo general me soluciona este problema al no enviar una cabecera Vary por sólo IE. En Apache, puede poner lo siguiente en httpd.conf:
BrowserMatch MSIE force-no-vary
De acuerdo con la RFC:
El Vary valor de campo indica el conjunto de campos petición de cabecera que determina totalmente , mientras la respuesta es fresca, si se permite una caché para su uso la respuesta para responder a una solicitud posterior sin revalidación.
El efecto práctico es que cuando "vuelve" a un POST, IE simplemente obtiene la página de la memoria caché del historial. Ninguna solicitud pasa al lado del servidor.Puedo ver esto claramente en HTTPWatch.
Me interesaría escuchar posibles malos efectos secundarios de este enfoque.
uso uno de lo siguiente antes de session_start:
session_cache_expire(60); // in minutes
ini_set('session.cache_limiter', 'private');
/Nota:
lenguaje es PHP
incluyendo qué idioma es útil – mkoryak
mejor sería para diseñar su aplicación para que el botón de retroceso tenga un significado razonable. Me resulta exasperante cuando no estoy 'permitido' usar el botón Atrás. – Peter
Peter, estoy de acuerdo. Hay momentos (como el proceso de finalización de la compra de un sitio de comercio electrónico) en los que puede verse tentado a evitar que el usuario regrese. Sin embargo, hay una mejor solución en el lado del servidor para ese problema que sugiero en mi respuesta. –
@Peter, estoy completamente de acuerdo, pero estoy tratando con flujos de trabajo, por lo que el botón Atrás no se aplica aquí. – mkoryak