Eso nunca debería suceder.
Sin ningún ejemplo de código que pueda ver, una de las razones por las que puedo imaginar que suceda es un flujo de trabajo de autenticación como se muestra a continuación:
En el siguiente diagrama, /login POSTs a /member , donde se realiza la verificación de autenticación.
Si la autenticación pasa, las páginas continúan enviando el contenido del "usuario registrado". Esto hace que esta página ( /member ) aparezca en el historial de los navegadores. Cada vez que haga clic en el botón de retroceso / avance de su navegador para acceder a esta página, le preguntará si desea POSTAR el contenido del formulario en esta página. En este caso, la fecha son las credenciales de inicio de sesión.
WRONG WAY:
+---------------------------+ +------------------------------+
| Login Page (/login) | | Member Page(/member) |
|---------------------------| |------------------------------|
| +--------------+ | | if creds wrong |
| UserName | | | | redirect_to /login |
| +--------------+ |+-------->| else |
| +--------------+ | | "Welcome Back, |
| Password | | | | Here is your super secret |
| +--------------+ | | member area where you can |
| | | check out the cool stuff" |
+---------------------------+ | end |
+------------------------------+
En su lugar, debería tener este tipo de flujo de autenticación:
- La página de inicio de sesión publica en una página
/verify (o / auth como se llame).
- La página de verificación no tiene ningún resultado de http. Según si las credenciales son buenas o malas, simplemente redirige a la página correspondiente. Si el inicio de sesión es correcto, establece un indicador de cookie que indica una sesión válida.
- La página del miembro valida la sesión al verificar el valor de la cookie y redirige a la página
/login si la sesión ha caducado o no está establecida.
En este flujo de trabajo, la página /verify nunca aparece en el historial del navegador y no hay forma de que el usuario pueda "hacer clic en actualizar" en esa página para desencadenar el envío de datos POST.
CORRECT WAY POST +-----------------------------+
+------------>| Verify page (/verify) |
| |-----------------------------|
+-------------------------+-+ | if creds wrong |
| Login Page (/login) |<---+---------+redirect_to /login |
|---------------------------| | | else |
| +--------------+ | | | set_session_cookie |
| UserName | | | | +-------+redirect_to /member |
| +--------------+ | | | | end |
| +--------------+ | | | | |
| Password | | | | | +-----------------------------+
| +--------------+ | | |
| | | | +------------------------------+
+---------------------------+ | +----->| Member Page(/member) |
| |------------------------------|
| | if session_cookie not set |
+-----------+redirect_to /login |
| else |
| "Welcome Back, |
| Here is your super secret |
| member area where you can |
| check out the cool stuff" |
| end |
+------------------------------+
Este es el modelo común de Post / Redirect / Get. Puedes consultar esta página wiki para ver fotos más bonitas: enlace
Además, si desea evitar que el navegador almacene en caché ciertas páginas HTML, puede configurar el encabezado HTTP de control de caché en 'no-caché' para esas páginas.
Control de caché: no-caché