Deshabilitar el botón Atrás del navegador
¿Cómo deshabilitar el botón ATRÁS del navegador (en todos los navegadores)?
No desactive el comportamiento esperado del navegador.
Haga que sus páginas admitan la posibilidad de que los usuarios retrocedan una página o dos; No intentes dañar su software.
Se me ocurrió un pequeño truco que desactiva el botón Atrás usando JavaScript. Lo comprobé en Chrome 10, Firefox 3.6 e IE9:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<title>Untitled Page</title>
<script type = "text/javascript" >
function changeHashOnLoad() {
window.location.href += "#";
setTimeout("changeHashAgain()", "50");
}
function changeHashAgain() {
window.location.href += "1";
}
var storedHash = window.location.hash;
window.setInterval(function () {
if (window.location.hash != storedHash) {
window.location.hash = storedHash;
}
}, 50);
</script>
</head>
<body onload="changeHashOnLoad(); ">
Try to hit the back button!
</body>
</html>
¿Qué está haciendo?
De comentarios:
Este script aprovecha el hecho de que los navegadores consideran todo lo que viene después del signo "#" en la URL como parte del historial de navegación. Lo que hace es esto: cuando se carga la página, se agrega "#1" a la URL. Después de 50 ms, se elimina el "1". Cuando el usuario hace clic en "atrás", el navegador cambia la URL a lo que era antes de que se eliminara el "1", PERO, es la misma página web, por lo que el navegador no necesita recargar la página. – Yossi Shasho
Otros han adoptado el enfoque de decir "no hagas esto", pero eso realmente no responde a la pregunta del cartel. Supongamos que todo el mundo sabe que esto es una mala idea, pero de todos modos tenemos curiosidad por saber cómo se hace...
No puede desactivar el botón Atrás en el navegador de un usuario, pero puede hacerlo de modo que su aplicación se interrumpa (muestre un mensaje de error que requiera que el usuario comience de nuevo) si el usuario regresa.
Un enfoque que he visto para hacer esto es pasar un token en cada URL dentro de la aplicación y dentro de cada formulario. El token se regenera en cada página y, una vez que el usuario carga una nueva página, todos los tokens de páginas anteriores se invalidan.
Cuando el usuario carga una página, la página solo se mostrará si se le pasó el token correcto (que se proporcionó a todos los enlaces/formularios en la página anterior).
La aplicación de banca en línea que ofrece mi banco es así. Si usa el botón Atrás, no funcionarán más enlaces y no se podrán realizar más recargas de página; en su lugar, verá un aviso que le indica que no puede regresar y que debe comenzar de nuevo.
Esta pregunta es muy similar a esta ...
Debe forzar la caducidad del caché para que esto funcione. Coloque el siguiente código en el código de su página detrás.
Page.Response.Cache.SetCacheability(HttpCacheability.NoCache)
Mientras busco la respuesta, las "Mejores prácticas" están... desactualizadas... Al igual que los navegadores (en realidad, los navegadores son fósiles feos).
La solución mejor/más segura sería que los navegadores implementen un método/solicitud donde el usuario pueda otorgar a la página la capacidad de controlar la interfaz.
¿Por qué? Porque para mi proyecto actual estoy creando una interfaz 100% construida y controlada por JavaScript. Y los botones de retroceso no tienen lugar en mi proyecto ya que no hay cambios de página. (Es decir, increíblemente rápido y sin parpadeos de página debido a una actualización... ¡Como una aplicación real!)
Sé por qué no existe la capacidad de "secuestrar" la interfaz y lo entiendo. ¡Pero al menos deberíamos poder solicitarlo desde el navegador! Esa sería verdaderamente la "mejor práctica" sin los peligros del secuestro.
Pero los navegadores son navegadores... No espero que suceda nada interesante en este sentido.
