removeattr - Evite cualquier forma de actualización de página utilizando jQuery/Javascript
removeattribute jquery (7)
Una vez que el usuario está en mi página, no quiero que actualice la página.
En cualquier momento, el usuario pulsa F5 o el botón de actualización en la parte superior. Debería recibir un mensaje de alerta
No puedes actualizar la página.
Además, si el usuario abre una nueva pestaña e intenta acceder a la misma URL en la pestaña anterior, debería recibir una alerta
No puedes abrir la misma página en 2 pestañas
De todos modos, puedo hacer esto usando JavaScript o jQuery? El primer punto es realmente importante.
Aunque no es una buena idea desactivar la tecla F5, puedes hacerlo en JQuery como se muestra a continuación.
<script type="text/javascript">
function disableF5(e) { if ((e.which || e.keyCode) == 116 || (e.which || e.keyCode) == 82) e.preventDefault(); };
$(document).ready(function(){
$(document).on("keydown", disableF5);
});
</script>
Espero que esto ayude!
El Issue # 2 ahora se puede resolver usando BroadcastAPI .
Por el momento, solo está disponible en Chrome, Firefox y Opera.
var bc = new BroadcastChannel(''test_channel'');
bc.onmessage = function (ev) {
if(ev.data && ev.data.url===window.location.href){
alert(''You cannot open the same page in 2 tabs'');
}
}
bc.postMessage(window.location.href);
El número (2) es posible mediante el uso de una implementación de socket (como websocket, socket.io, etc.) con un latido personalizado para cada sesión en la que participa el usuario. Si un usuario intenta abrir otra ventana, tiene una verificación de controlador de JavaScript con el servidor si está bien, y luego responde con un mensaje de error.
Sin embargo, una mejor solución es sincronizar las dos sesiones si es posible, como en google docs.
En los viejos tiempos de CGI, teníamos muchas formas que desencadenarían varias acciones de back-end. Tales como notificaciones de texto a grupos, trabajos de impresión, agricultura de datos, etc.
Si el usuario estaba en una página que estaba diciendo "Por favor, espere ... Realizar un trabajo ENORME que podría llevar algo de tiempo". ¡Era más probable que pulsaran REFRESH y esto sería MALO!
¿POR QUÉ? Porque desencadenaría trabajos más lentos y eventualmente empantanaría todo.
¿La solución? Permitirles hacer su forma. Cuando envían su formulario ... Comience su trabajo y luego diríjalos a otra página que les indique que esperen.
Donde la página en el medio contenía los datos del formulario que se necesitaban para comenzar el trabajo. Sin embargo, la página WAIT contiene un historial de javascript destruido. Por lo tanto, pueden recargar esa página de espera todo lo que deseen y nunca desencadenará el inicio del trabajo original en segundo plano, ya que esa página de espera solo contiene los datos de formulario necesarios para la propia WAIT.
Espero que tenga sentido.
La función de destrucción de historial también les impidió hacer clic en ATRÁS y luego refrescarse también.
Fue muy sencillo y funcionó de maravilla durante MUCHOS años hasta que la organización sin fines de lucro fue liquidada.
Ejemplo: ENTRADA DE FORMULARIO: recopila toda su información y, cuando se envíe, activará tu trabajo de back-end.
RESPUESTA desde la entrada del formulario - Devuelve HTML que realiza un redireccionamiento a su página de espera estática y / o POST / GET a otro formulario (la página de espera).
PÁGINA DE ESPERA - Solo contiene los datos de FORMA relacionados con la página de espera, así como javascript para destruir el historial más reciente. Me gusta (-1 o -2) para destruir solo las páginas más recientes, pero todavía les permite volver a su página de entrada de FORM original.
Una vez que están en su página WAIT, pueden hacer clic en ACTUALIZAR tanto como lo deseen y nunca generarán el trabajo FORM original en el back-end. En cambio, su página de espera debe incluir una actualización cronometrada de META para que siempre pueda verificar el estado de su trabajo. Cuando se completa su trabajo, son redirigidos fuera de la página de espera a donde lo desee.
Si lo hacen ACTUALMENTE ACTUALMENTE ... Simplemente están agregando una verificación más de su estado laboral allí.
Espero que ayude. Buena suerte.
No puede evitar que el usuario se actualice, ni debería intentarlo realmente. Debería volver al por qué necesita esta solución, ¿cuál es el problema raíz aquí? Comience allí y encuentre una forma diferente de resolver el problema. Tal vez esté más elaborado sobre por qué cree que necesita hacer esto, ayudaría a encontrar tal solución.
Romper las características fundamentales del navegador nunca es una buena idea, más del 99.999999999% de las obras de Internet y actualizaciones con F5, esta es una expectativa del usuario, una que no debería romperse.
No, no hay.
Estoy bastante seguro de que no hay forma de interceptar un clic en el botón de actualización de JS, e incluso si lo hubiera, JS se puede desactivar.
Probablemente deberías alejarte de tu X (evitando refrescar) y encontrar una solución diferente a Y (cualquiera que sea).
# 1 se puede implementar a través de window.onbeforeunload .
Por ejemplo:
<script type="text/javascript">
window.onbeforeunload = function() {
return "Dude, are you sure you want to leave? Think of the kittens!";
}
</script>
Se le solicitará al usuario el mensaje y se le dará una opción para permanecer en la página o continuar su camino. Esto se está volviendo más común. lo hace si intenta navegar desde una página mientras escribe una publicación. No puede detener por completo al usuario de volver a cargar, pero puede hacer que suene realmente aterrador si lo hacen.
# 2 es más o menos imposible. Incluso si realiza un seguimiento de las sesiones y los inicios de sesión de los usuarios, aún no podrá garantizar que está detectando una segunda pestaña correctamente. Por ejemplo, tal vez tengo una ventana abierta, luego ciérrela. Ahora abro una nueva ventana. Es probable que lo detecte como una segunda pestaña, aunque ya cerré la primera. Ahora su usuario no puede acceder a la primera ventana porque la cerraron y no pueden acceder a la segunda ventana porque las está negando.
De hecho, el sistema en línea de mi banco se esfuerza realmente por hacer # 2, y la situación descrita anteriormente ocurre todo el tiempo. Normalmente tengo que esperar hasta que la sesión del lado del servidor caduque antes de poder utilizar el sistema bancario nuevamente.