Heim  >  Artikel  >  Web-Frontend  >  Eine umfassende Untersuchung von „Browser zurück deaktivieren“_CSS/HTML

Eine umfassende Untersuchung von „Browser zurück deaktivieren“_CSS/HTML

WBOY
WBOYOriginal
2016-05-16 12:10:421555Durchsuche

Mit der Zurück-Schaltfläche des Browsers können wir problemlos zu zuvor besuchten Seiten zurückkehren, was zweifellos sehr nützlich ist. Aber manchmal müssen wir diese Funktion deaktivieren, um
zu verhindern, dass Benutzer die geplante Seitenzugriffssequenz stören. In diesem Artikel werden verschiedene Lösungen zum Deaktivieren der Browser-Zurück-Schaltfläche vorgestellt, die im Internet zu finden sind, und ihre jeweiligen Vor- und Nachteile sowie mögliche Anlässe analysiert.
1. Übersicht
Viele Leute haben gefragt: „Wie kann ich die Zurück-Schaltfläche des Browsers ‚deaktivieren‘?“ oder „Wie kann ich verhindern, dass Benutzer auf die Zurück-Schaltfläche klicken, um zu zuvor besuchten Seiten zurückzukehren?“ Diese Frage ist auch eine der am häufigsten gestellten Fragen im ASP-Forum. Leider ist die Antwort ganz einfach: Wir können die Zurück-Taste
des Browsers nicht deaktivieren.
Zuerst war ich ungläubig, dass jemand die Zurück-Schaltfläche des Browsers deaktivieren wollte. Später war ich erleichtert, als ich sah, dass so viele Leute die Zurück-Schaltfläche
deaktivieren wollten (die einzigen, die sie deaktivieren wollten, waren die Zurück-Schaltfläche, nicht die Vorwärts-Schaltfläche des Browsers). Denn standardmäßig kann der Benutzer nach dem Absenden des Formulars über die Schaltfläche
„Zurück“ zur Formularseite zurückkehren (anstatt die Schaltfläche „Bearbeiten“ zu verwenden!) und das Formular dann erneut bearbeiten und absenden, um neue Datensätze einzufügen die Datenbank. Das ist etwas, was wir
nicht sehen wollen.
Also beschloss ich, einen Weg zu finden, diese Situation zu vermeiden. Ich habe viele Websites besucht und verschiedene Implementierungsmethoden konsultiert, die auf diesen Websites vorgestellt wurden. Wenn Sie
häufig ASP-Programmierwebsites besuchen, haben Sie möglicherweise einige der in diesem Artikel vorgestellten Inhalte gesehen. Die Aufgabe dieses Artikels besteht darin, allen alle möglichen Methoden vorzustellen und dann
die beste Methode zu finden!
2. Caching deaktivieren
Unter den vielen Lösungen, die ich gefunden habe, schlug eine vor, das Seiten-Caching zu deaktivieren. Verwenden Sie insbesondere ein serverseitiges Skript wie folgt:
Response.Buffer = True
Response.ExpiresAbsolute = Now() - 1 Response.Expires = 0
Response.CacheControl = "no-cache"
%>
Diese Methode ist sehr effektiv! Dadurch wird der Browser gezwungen, den Server erneut aufzusuchen, um die Seite herunterzuladen, anstatt die Seite aus dem Cache zu lesen. Bei dieser Methode besteht die Hauptaufgabe des Programmierers darin, eine Variable auf Sitzungsebene zu erstellen, die bestimmt, ob der Benutzer die Seite, die für den Zugriff über den Zurück-Button nicht geeignet ist, noch sehen kann. Da der Browser
die Seite nicht mehr zwischenspeichert, lädt der Browser die Seite erneut herunter, wenn der Benutzer auf die Schaltfläche „Zurück“ klickt, und das Programm kann dann diese Sitzungsvariable überprüfen, um zu sehen, ob
dem Benutzer das Öffnen gestattet werden sollte die Seite.
Angenommen, wir haben das folgende Formular:
Response.Buffer = True
Response.ExpiresAbsolute = Now() - 1
Response.Expires = 0 Response .CacheControl = "no-cache"
If Len(Session("FirstTimeToPage")) > 0 then
&single;
&single; Sitzungsvariablen löschen und den Benutzer zur Anmeldeseite weiterleiten.
Session("FirstTimeToPage") = ""
Response.Redirect "/Bar.asp"
Response.End
End If
&single; Wenn das Programm hier ausgeführt wird, bedeutet dies, dass das Der Benutzer kann die aktuelle Seite anzeigen
&single; Folgendes beginnt mit der Erstellung des Formulars





Wir verwenden die Sitzungsvariable FirstTimeToPage, um Überprüfen Sie, ob der Benutzer zum ersten Mal die aktuelle Seite besucht. Wenn es nicht das erste Mal ist (d. h. Sitzung ("FirstTimeToPage") enthält einen bestimmten Wert), löschen wir den Wert der Sitzungsvariablen und leiten den Benutzer auf eine Startseite um. Auf diese Weise müssen wir FirstTimeToPage einen Wert geben, wenn das Formular
gesendet wird (wenn SompePage.asp geöffnet wird). Das heißt, in SomePage.asp müssen wir den folgenden
-Code hinzufügen:
Session("FirstTimeToPage") = "NO"
  Auf diese Weise klickt der Benutzer, der SomePage.asp geöffnet hat, auf die Rückseite Schaltfläche, der Browser Der Server wird erneut aufgefordert, die Seite herunterzuladen. Der Server überprüft, ob Session
("FirstTimeToPage") einen Wert enthält, löscht also Session("FirstTimeToPage") und leitet den Benutzer zu anderen Seiten weiter. Natürlich
all dies setzt voraus, dass der Benutzer Cookies aktiviert hat, andernfalls sind die Sitzungsvariablen ungültig.(Pour plus d'explications sur ce problème, voir Pour que les variables de session
fonctionnent, le visiteur Web doit-il avoir les cookies activés ?)
De plus, nous pouvons également utiliser du code côté client pour empêcher le navigateur de mettre en cache les pages Web :






Si vous utilisez la méthode ci-dessus pour forcer le navigateur à plus de cache Pour les pages web, vous devez faire attention aux points suivants :
"Pragma : no-cache" empêche uniquement le navigateur de mettre la page en cache lors de l'utilisation d'une connexion sécurisée. Pour les pages qui ne sont pas protégées par la sécurité, « Pragma : no-cache »
est traité de la même manière que « Expire : -1 ». À ce stade, le navigateur met toujours la page en cache, mais marque la page comme expirant immédiatement.
Sous IE 4 ou 5, la balise META HTTP-EQUIV "Cache-Control" sera ignorée et n'aura aucun effet.
Dans les applications pratiques, nous pouvons ajouter tous ces codes. Toutefois, comme cette méthode ne fonctionne pas dans tous les navigateurs, elle n’est pas recommandée. Mais
S'il s'agit d'un environnement intranet et que l'administrateur peut contrôler le navigateur utilisé par l'utilisateur, je pense que certaines personnes utiliseront toujours cette méthode.
3. Autres méthodes
La méthode dont nous allons parler ensuite est centrée sur le bouton de retour lui-même, et non sur le cache du navigateur. Voici un article Recâblage du bouton Retour qui mérite
d’être référencé. Cependant, j'ai remarqué que si cette méthode est utilisée, même si l'utilisateur ne verra pas la page sur laquelle il a précédemment saisi les données lorsqu'il clique sur le bouton de retour, il lui suffit de cliquer deux fois sur
. Ce n'est pas l'effet que nous souhaitons, car. Souvent, les utilisateurs têtus parviennent à trouver des moyens de contourner les mesures préventives.
Une autre façon de désactiver le bouton de retour consiste à utiliser JavaScript côté client pour ouvrir une fenêtre sans barre d'outils. Cela rend difficile pour l'utilisateur de revenir à la page précédente, mais
pas impossible. Une méthode plus sûre, mais plutôt ennuyeuse, consiste à ouvrir une nouvelle fenêtre lorsque le formulaire est soumis et en même temps à fermer la fenêtre où se trouve le formulaire. Mais j’estime
que cette méthode ne mérite pas d’être sérieusement envisagée, car on ne peut pas laisser les utilisateurs ouvrir une nouvelle fenêtre à chaque fois qu’ils soumettent un formulaire.
Alors, pouvons-nous également ajouter du code JavaScript à la page sur lequel nous ne voulons pas que l’utilisateur revienne ? Le code JavaScript ajouté à cette page peut
être utilisé pour produire l'effet de cliquer sur le bouton Suivant, contrecarrant ainsi l'action provoquée par le clic de l'utilisateur sur le bouton Précédent. Le code JavaScript utilisé pour implémenter cette fonction est le suivant
:


Encore une fois, bien que cette méthode soit efficace, elle est encore loin d'être la "meilleure méthode". Plus tard, j'ai vu quelqu'un suggérer d'utiliser location.replace pour passer d'une
page à une autre. Le principe de cette méthode est de remplacer l'enregistrement de l'historique actuel par l'URL de la nouvelle page, afin qu'il n'y ait qu'une seule page dans l'historique de navigation, et que le bouton retour
ne devienne jamais disponible. Je pense que c’est probablement ce que recherchent beaucoup de gens, mais ce n’est toujours pas la meilleure approche dans toutes les situations. Un exemple d'utilisation de cette
méthode est le suivant : Désactivez les liens vers cette page

Essayez ce lien :
Désactivez les liens vers cette page !
L'inconvénient de cette approche est que la simple utilisation de Response.Redirect ne fonctionnera plus car chaque fois que l'utilisateur passe d'une page à une autre,
nous devons effacer location.history avec le code client . Notez également que cette méthode efface le dernier enregistrement de l'historique d'accès, pas tous les
enregistrements d'accès.
Cliquez sur le lien ci-dessus et vous ouvrirez une simple page HTML. Cliquez à nouveau sur le bouton retour, et vous verrez que ce qui est ouvert n'est pas cette page, mais la page
avant cette page ! (Bien sûr, vous devez activer le code JavaScript côté client dans le navigateur.)
Après quelques recherches minutieuses, j'ai découvert que je ne parvenais toujours pas à trouver un moyen de désactiver complètement le bouton de retour du navigateur. Toutes les méthodes
décrites ici peuvent empêcher les utilisateurs de revenir à la page précédente à des degrés divers et de différentes manières, mais elles ont toutes leurs propres limites. Puisqu'il n'existe aucun moyen de désactiver complètement le bouton de retour <script> <BR><!-- <BR>javascript:window.history.forward(1); <BR>//--> <BR></script>, la meilleure solution consiste à utiliser un mélange de scripts côté client et côté serveur.
Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn