Analyse der Probleme und Lösungen für wiederholte Übermittlung, wiederholte Aktualisierung und Backoff-Verhinderung

Analyse der Probleme und Lösungen für wiederholte Übermittlung, wiederholte Aktualisierung und Backoff-Verhinderung
eins. Vorwort <br />Sie werden diese Art von Fragen in jedem professionellen BBS sehen. Selbst wenn Sie danach googeln, werden Sie feststellen, dass viele Leute darauf achten und danach fragen. Die Lösungen, die sie anbieten, sind jedoch sehr unterschiedlich. (Einige Leute befürworten die Verwendung von Skripten zur Lösung, andere möchten auf andere Seiten umleiten, wieder andere bringen das Problem aus der Token-Perspektive.) Warum gibt es so große Unterschiede?
zwei. Problemszenario <br />Zuerst sollten wir verstehen, warum wir uns mit einem solchen Problem befassen sollten. Oder professioneller: Für welche Szenarien ist es geeignet? (Es scheint, als würden nur Leute kommen, um zu fragen, aber niemand, um es zu erklären)
1. Szenarien wiederholter Übermittlung und wiederholter Aktualisierung Sowohl wiederholte Übermittlung als auch wiederholte Aktualisierung sollen das Problem doppelter Datensätze im System lösen. Das heißt, jemand übermittelt einen Datensatz mehrfach (warum? Vielleicht hat er nichts zu tun; höchstwahrscheinlich weiß der Benutzer nicht einmal, ob das Ergebnis seiner Übermittlung ausgeführt wurde?!).
Es ist jedoch nicht notwendig, sich mit solchen Problemen zu befassen. Es hängt von der Art des Systems ab, das Sie entwickeln. Wenn Sie beispielsweise für ein Ressourcenverwaltungssystem verantwortlich sind, lässt das System selbst aus Bedarfssicht keine „doppelten“ Datensätze zu. Unter solchen Bedarfsbeschränkungen löst die Durchführung wiederholter Übermittlungsaktionen nur „Ausnahmen auf Geschäftsebene“ aus, die eine erfolgreiche Ausführung unmöglich machen, und Sie müssen sich keine Gedanken darüber machen, ob das Problem vermieden werden kann oder nicht.
2. Szenarien zum Verhindern von Rückwärtszugriffen: Nachdem wir nun die Szenarien wiederholter Aktualisierung und wiederholter Übermittlung kennen, wollen wir den Grund für den Vorgang „Rückwärtszugriff verhindern“ verstehen. Wenn Sie beispielsweise ein Abstimmungssystem entwickeln, umfasst es viele Schritte, und diese Schritte sind miteinander verknüpft. Beispielsweise sendet der erste Schritt bestimmte Informationen an den zweiten Schritt, der zweite Schritt speichert diese Informationen im Cache und sendet seine eigenen Informationen an den dritten Schritt. . . . . Warten Sie, wenn sich der Benutzer zu diesem Zeitpunkt im dritten Schritt befindet. Stellen wir uns vor, ein ungezogener Benutzer klickt auf die Zurück-Schaltfläche und die Seite des zweiten Schritts wird auf dem Bildschirm angezeigt. Er ändert oder sendet erneut und geht zum nächsten Schritt (d. h. zum dritten Schritt). Tritt hier ein Fehler auf? ! Was ist los? Der typischste Fall ist, dass ein solcher Vorgang direkt zum Verlust von Informationen über den ersten Schritt führt! (Wenn solche Informationen in einer Anfrage gespeichert sind, können Sie sie natürlich auch in einer Sitzung oder einem größeren Kontext speichern, aber das ist keine gute Idee! Was die Frage der Informationsspeicherung betrifft, werden wir dieses Problem beim nächsten Mal ausführlich besprechen.)
drei. So gehen Sie mit dem Problem um
 Natürlich müssen viele Systeme (z. B. das Ticketbuchungssystem selbst ermöglicht es Einzelpersonen, wiederholt Reservierungen vorzunehmen) wiederholte Aktualisierungen und wiederholte Übermittlungen vermeiden und Backoff-Probleme verhindern. Aber selbst bei solchen Problemen muss unterschieden werden, wie und wo sie zu behandeln sind (das Internet sagt Ihnen nur, wie Sie sie behandeln sollen, unterscheidet aber selten, wo Sie sie behandeln sollen). Offensichtlich gibt es nur zwei Möglichkeiten, sie zu behandeln: clientseitig oder serverseitig, und die Verarbeitungsmethoden sind für verschiedene Standorte unterschiedlich. Aber eines muss im Voraus gesagt werden: Jede Verarbeitung auf der Clientseite (insbesondere auf der B/S-Seite) ist nicht vertrauenswürdig, und die beste und am besten geeignete Methode ist die serverseitige Verarbeitungsmethode.
Clientseitige Verarbeitung:
Wenn wir dem Client gegenüberstehen, können wir das Problem mithilfe eines Javascript-Skripts wie folgt lösen
1. Wiederholte Aktualisierung, wiederholte Übermittlung
Möglichkeit 1: Legen Sie eine Variable fest, um die Übermittlung nur einmal zuzulassen.

Code kopieren
Der Code lautet wie folgt:

<Skriptsprache="Javascript">
var checkSubmitFlg = false;
Funktion checkSubmit() {
wenn (checkSubmitFlg == true) {
gibt false zurück;
}
checkSubmitFlg = wahr;
gibt true zurück;
}
dokument.ondblclick = Funktion docondblclick() {
Fenster.Ereignis.Rückgabewert = falsch;
}
dokument.onclick = Funktion doc {
wenn (checkSubmitFlg) {
Fenster.Ereignis.Rückgabewert = falsch;
}
}
</Skript>
<html:form action="meineAktion.do" method="post" onsubmit="return checkSubmit();">
Möglichkeit zwei: Deaktivieren Sie die Schaltfläche „Senden“ oder das Bild
<html:form action="meineAktion.do" method="posten"
onsubmit="getElById_r('submitInput').disabled = true; return true;">
<html:Bild styleId="submitInput" src="images/ok_b.gif" border="0" />
</html:Formular>

2. Es gibt viele Möglichkeiten, Benutzer am Zurückgehen zu hindern. Einige Methoden ändern den Browserverlauf, beispielsweise mithilfe der Methode window.history.forward(). Einige Methoden „ersetzen den aktuellen Verlauf durch die URL der neuen Seite, sodass der Browserverlauf nur eine Seite enthält und die Zurück-Schaltfläche nie verfügbar wird.“ Verwenden Sie beispielsweise JavaScript: location.replace(this.href); event.returnValue=false;

2. Serverseitige Verarbeitung (hier wird nur die Verarbeitung des Struts-Frameworks erwähnt)
Struts bietet außerdem eine Referenzimplementierung für die Verwendung des Synchronisierungstoken-Mechanismus, um das Problem wiederholter Übermittlungen in Webanwendungen zu lösen.
Grundprinzip:
Vor der Verarbeitung der eingehenden Anfrage vergleicht der Server den in der Anfrage enthaltenen Token-Wert mit dem in der aktuellen Benutzersitzung gespeicherten Token-Wert.
Prüfen Sie, ob sie übereinstimmen. Nachdem die Anfrage verarbeitet wurde und bevor die Antwort an den Client gesendet wird, wird ein neues Token generiert. Zusätzlich zur Weitergabe an den Client wird auch das alte, in der Benutzersitzung gespeicherte Token ersetzt. Auf diese Weise ist das vom Client gesendete Token nicht mit dem Token auf dem Server konsistent, wenn der Benutzer zur vorherigen Übermittlungsseite zurückkehrt und erneut übermittelt. Dadurch werden doppelte Übermittlungen wirksam verhindert.
wenn (isTokenValid(Anfrage, wahr)) {
// Ihr Code hier
returniere Mapping.findForward("Erfolg");
} anders {
saveToken(Anfrage);
returniere Mapping.findForward("erneut senden");
}
Struts generiert ein eindeutiges Token (für jede Sitzung) basierend auf der Benutzersitzungs-ID und der aktuellen Systemzeit. Eine spezifische Implementierung finden Sie unter
Die Methode generateToken() in der Klasse TokenProcessor.
1. //Überprüfen Sie das Transaktionskontrolltoken. <html:form> generiert automatisch ein implizites Eingaberepräsentantentoken basierend auf der Kennung in der Sitzung, um eine doppelte Übermittlung zu verhindern.
2. In der Aktion:

//<Eingabetyp="versteckt" Name="org.apache.struts.taglib.html.TOKEN"
// Wert="6aa35341f25184fd996c4c918255c3ae">
wenn (!isTokenValid(Anfrage))
Fehler.Hinzufügen(ActionErrors.GLOBAL_ERROR,
neuer ActionError("Fehler.Transaktion.Token"));
resetToken(request); //Token in der Sitzung löschen
3. Aktion hat eine Methode zum Generieren eines Tokens
geschützter String generateToken(HttpServletRequest request) {
HttpSession-Sitzung = Anfrage.getSession_r();
versuchen {
Byte-ID[] = session.getId_r().getBytes_r();
Byte jetzt[] =
neues Long(System.currentTimeMillis()).toString().getBytes_r();
MessageDigest md = MessageDigest.getInstance_r("MD5");
md.update(id);
md.update(jetzt);
zurückgeben (toHex(md.digest()));
} Fang (IllegalStateException e) {
Rückgabe (null);
} Fang (NoSuchAlgorithmException e) {
Rückgabe (null);
}
}
Zusammenfassend lässt sich sagen, dass wiederholtes Senden, wiederholtes Aktualisieren und die Verhinderung von Backoffs alles Probleme sind, die das System lösen muss, um doppelte Datensätze zu vermeiden. Um sie auf der Clientseite zu handhaben, müssen für jede Möglichkeit entsprechende Lösungen vorgeschlagen werden. Auf der Serverseite handelt es sich jedoch nur um ein Problem der Überprüfung der Authentizität der Daten. Die tokenbasierte Verarbeitung ist eine einmalige Methode.
Gleichzeitig erkennen wir auch, dass die Betrachtung des Problems aus unterschiedlichen Blickwinkeln zu unterschiedlichen Lösungen führt. Der Client kümmert sich mehr um Benutzervorgänge, während sich der Server auf die Datenverarbeitung konzentriert. Daher ist ein Problem, das für den Server einfach erscheint, für den Client viel schwieriger zu lösen! Das Gegenteil ist auch der Fall. Bei der Behandlung bestimmter Probleme müssen wir umfassende Überlegungen anstellen und abwägen: Sollten wir zur Lösung den Client hinzuziehen? Oder wird es serverseitig gehandhabt?

Anti-Aktualisierung der Webseite, doppelte Übermittlung, Anti-Backward-Lösung. Deaktivieren Sie die Schaltfläche „Senden“ nach der Übermittlung (das machen die meisten Leute).
Was passiert, wenn der Kunde nach dem Absenden zum Aktualisieren F5 drückt?
Verwenden der Sitzung
Bevor die übermittelte Seite von der Datenbank verarbeitet wird:
wenn session("ok")=true dann
response.write "Fehler beim Senden"
Antwort.Ende
Ende, wenn
Nachdem die Daten verarbeitet wurden, ändern Sie session("ok")=false.
Die Umleitung auf eine andere Seite unmittelbar nach erfolgreicher Datenverarbeitung und Aktualisierung ist tatsächlich ein Problem. Sie können die Sprungseite verwenden und diese Seite schließen. Wenn dies durch Parameterdatenbedingungen gesteuert wird, sollte dies einfach zu bewerkstelligen sein. Sie können den Wert von window.location direkt ändern und alle Parameter ändern. Das ist fast alles.
Nachteile: Die einfache Verwendung von Response.Redirect funktioniert nicht mehr, da wir location.history im Clientcode löschen müssen, wenn der Benutzer von einer Seite zur anderen wechselt. Beachten Sie, dass diese Methode den letzten Zugriffsverlaufsdatensatz löscht, nicht alle Zugriffsdatensätze. Klicken Sie auf die Zurück-Schaltfläche und dann erneut auf die Zurück-Schaltfläche. Sie können sehen, dass die jetzt geöffnete Seite die Seite vor dieser Seite ist! (Dies setzt natürlich voraus, dass JavaScript auf Ihrer Clientseite aktiviert ist.)
Und wenn der Kunde Widerstand leistet?

Zurückgehen von Webseiten verhindern – Caching deaktivieren Wenn wir etwas zur Datenbank hinzufügen, das Zurückgehen zulassen und die Seite zufällig aktualisiert wird, wird der Hinzufügungsvorgang erneut ausgeführt. Das ist zweifellos nicht das, was wir brauchen. Wie viele Codes, die das Caching im Internet verbieten, sind sie manchmal unzuverlässig. Zu diesem Zeitpunkt müssen Sie es nur zur Operationsseite hinzufügen, die neue Seite angeben, zu der auf der Webseite weitergeleitet werden soll, und dann auf Zurück klicken, um zu sehen, ob Sie nicht zur vorherigen Operationsseite zurückkehren. Tatsächlich wurde dieser Verlauf gelöscht.
ASP:
Antwort.Puffer = True
Response.ExpiresAbsolute = Jetzt() - 1
Antwort.Läuft ab = 0
Response.CacheControl = "kein Cache"
ASP.NET:
Antwort.Puffer=true;
Antwort.ExpiresAbsolute=DateTime.Now.AddSeconds(-1);
Antwort.Läuft ab=0;
Response.CacheControl="kein Cache";
Wie genau 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 angezeigten Seiten zurückzukehren?“
Leider können wir die Zurück-Schaltfläche Ihres Browsers nicht deaktivieren.
Verhindern Sie, dass die Webseite zurückgeht - verwenden Sie window.open, um die Formularseite im neu geöffneten Fenster einzublenden, und schließen Sie die Seite, nachdem Sie auf „Senden“ geklickt haben. Die ASP-Seite, die die Übermittlung verarbeitet, verwendet auch Popups, legt das Ziel des Formulars fest, klickt auf window.open("XXX.asp","_blank"), verwendet dann JS, um das Formular zu übermitteln, und verwendet nach Abschluss window.close().
Einfach ausgedrückt: Wenn das Formular abgeschickt wird, wird ein neues Fenster geöffnet und das aktuelle Fenster wird geschlossen. Wie ziehe ich das mit window.open() geöffnete Fenster zurück? Wohin können Sie sich zurückziehen?
Haha, ich habe viel Unsinn erzählt. Weißt du, wie du damit umgehen sollst? Mischen Sie clientseitiges und serverseitiges Scripting.

Ich habe den Online-Artikel über wiederholte JSP-Übermittlung gelesen und mehrere Methoden gefunden:
1 Fügen Sie diesen Code zum HEAD-Bereich Ihrer Formularseite hinzu:
<META HTTP-EQUIV="pragma" CONTENT="kein-cache">
<META HTTP-EQUIV="Cache-Steuerung" CONTENT="kein Cache, muss erneut validiert werden">
<META HTTP-EQUIV="läuft ab" CONTENT="Mi, 26. Februar 1997 08:21:57 GMT">
2
Generieren Sie ein Token und speichern Sie es in der Benutzersitzung. Fügen Sie im Formular ein verstecktes Feld hinzu, um den Wert des Tokens anzuzeigen. Nachdem das Formular übermittelt wurde, wird ein neues Token generiert. Das vom Benutzer übermittelte Token und die Sitzung
Bei Übereinstimmung werden die Token im Vergleich wiederholt.
3
Verwenden Sie die Anweisung Response.Redirect("selfPage") im Code Ihres serverseitigen Steuerelements. Aber die meisten Zahlen verwenden diesen Ansatz nicht.
Es gibt noch viele weitere Methoden. . .
4
<input type="button" value="Senden" onclick="this.disabled=true;this.form.submit()">
5
Fügen Sie dem FORM-Formular der JSP-Seite ein verstecktes Feld hinzu
<Eingabetyp="versteckt" Name="URL"Wert=<%=request.getRequestURL_r()%>>

Fügen Sie Ihrem Serverlet die folgende Anweisung hinzu
Zeichenfolge url = Anfrage.getParameter_r("url");
Antwort.sendRedirect(URL);
Normalerweise benutze ich diese Methode, um zur JSP-Seite zurückzukehren. Ich verstehe nicht ganz, was du mit wiederholtem Aktualisieren meinst.
6 Ajax, kein Refresh, Senden
7. Wie kann verhindert werden, dass die Aktualisierungstaste des Browsers bei der Webentwicklung zu einer wiederholten Übermittlung von Systemvorgängen führt? Eine Umleitung kann das Problem der wiederholten Übermittlung von Daten aufgrund von Seitenaktualisierungen lösen. Wir können dieses Problem natürlich durch eine Umleitung lösen. Wenn Sie jedoch zum Springen in der Struts-Aktion „mapping.findword()“ verwenden, wird standardmäßig die Seite im Projektordner gesucht, zu der gesprungen werden soll. Wie kann diese Situation gelöst werden?
Ändern Sie die Datei struts-config.xml. Es ist ein Redirect-Attribut in Aktion. Der Standardwert in Struts ist false. Fügen Sie dieses Attribut hinzu und ändern Sie es in true. Schreiben Sie die absolute oder relative Adresse der Seite, die in Forword umgeleitet werden soll. Ändern Sie sie wie folgt:
<Aktionszuordnungen>
<action-Attribut="newsActionForm" Name="newsActionForm"
Eingabe="/addnews.jsp" Pfad="/newsAction" Parameter="Methode"
Umfang = "Anfrage" Typ = "com.yongtree.news.action.NewsAction">
<forward name="list" path="/listnews.jsp" redirect="true"></forward>
<forward name="error" path="/addnews.jsp"></forward>
</Aktion>
</Aktionszuordnungen>

Über die Zurück-Schaltfläche des Browsers können wir ganz einfach zu zuvor besuchten Seiten zurückkehren, was zweifellos sehr nützlich ist. Manchmal müssen wir diese Funktion jedoch deaktivieren, um zu verhindern, dass Benutzer die geplante Reihenfolge der Seitenbesuche stören. In diesem Artikel werden verschiedene im Internet verfügbare Lösungen zum Deaktivieren der Zurück-Schaltfläche des Browsers vorgestellt und ihre jeweiligen Vor- und Nachteile sowie die Anwendungsfälle 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 durchsuchten 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-Schaltfläche des Browsers nicht deaktivieren.
Zuerst war ich erstaunt, 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 (sie wollten nur die Zurück-Schaltfläche deaktivieren, nicht die Vorwärts-Schaltfläche des Browsers). Denn standardmäßig kann der Benutzer nach dem Absenden des Formulars über die Zurück-Schaltfläche (anstatt die Schaltfläche „Bearbeiten“ zu verwenden!) zur Formularseite zurückkehren und das Formular anschließend bearbeiten und erneut absenden, um einen neuen Datensatz in die Datenbank einzufügen. 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 mir die verschiedenen dort vorgestellten Implementierungsmethoden angesehen. Wenn Sie häufig ASP-Programmierwebsites besuchen, haben Sie möglicherweise einige der in diesem Artikel vorgestellten Inhalte gesehen. Die Aufgabe dieses Artikels ist es, jedem 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 das serverseitige Skript insbesondere wie folgt:
<%
Antwort.Puffer = True
Response.ExpiresAbsolute = Jetzt() - 1
Antwort.Läuft ab = 0
Response.CacheControl = "kein Cache"
%>
Diese Methode ist sehr effektiv! Dadurch wird der Browser gezwungen, den Server erneut aufzurufen, um die Seite herunterzuladen, anstatt sie aus dem Cache zu lesen. Bei diesem Ansatz besteht die Hauptaufgabe des Programmierers darin, eine Variable auf Sitzungsebene zu erstellen, die bestimmt, ob der Benutzer die Seite weiterhin anzeigen kann, die nicht über die Zurück-Schaltfläche zugänglich ist. Da die Seite im Browser nicht mehr zwischengespeichert ist, wird sie vom Browser erneut heruntergeladen, wenn der Benutzer auf die Zurück-Schaltfläche klickt. Anschließend kann das Programm anhand der Sitzungsvariable prüfen, ob der Benutzer die Seite öffnen darf.

Angenommen, wir haben das folgende Formular:

<%
Antwort.Puffer = True
Response.ExpiresAbsolute = Jetzt() - 1
Antwort.Läuft ab = 0
Response.CacheControl = "kein Cache"
Wenn Len(Session("FirstTimeToPage")) > 0 dann
&single; Der Benutzer hat die aktuelle Seite besucht und kehrt zurück, um sie erneut zu besuchen.
&single; Löscht Sitzungsvariablen und leitet den Benutzer zur Anmeldeseite weiter.
Sitzung("ErstesMalAufSeite") = ""
Antwort.Umleitung "/Bar.asp"
Antwort.Ende
Ende, wenn
&single; Wenn das Programm hier ausgeführt wird, bedeutet dies, dass der Benutzer die aktuelle Seite anzeigen kann
&single; Beginnen wir mit der Erstellung des Formulars
%>
<Formularmethode=Post-Aktion="IrgendeineSeite.asp">
<Eingabetyp=Senden>
</form>

Wir verwenden die Sitzungsvariable FirstTimeToPage, um zu überprüfen, ob der Benutzer die aktuelle Seite zum ersten Mal besucht. Wenn es nicht das erste Mal ist (d. h. Session("FirstTimeToPage") enthält einen Wert), löschen wir den Wert der Sitzungsvariable und leiten den Benutzer auf eine Startseite um. Daher müssen wir „FirstTimeToPage“ einen Wert zuweisen, wenn das Formular übermittelt wird (wenn SompePage.asp geöffnet wird). Das heißt, wir müssen den folgenden Code in SomePage.asp hinzufügen:
Sitzung("FirstTimeToPage") = "NEIN"
Wenn also ein Benutzer, der SomePage.asp geöffnet hat, auf die Zurück-Schaltfläche klickt, fordert der Browser den Server erneut auf, die Seite herunterzuladen. Der Server überprüft, ob Session("FirstTimeToPage") einen Wert enthält, löscht Session("FirstTimeToPage") und leitet den Benutzer auf eine andere Seite um. Dies alles setzt natürlich voraus, dass der Benutzer Cookies aktiviert hat, da sonst die Sitzungsvariablen ungültig sind. (Eine ausführlichere Erläuterung dieses Problems finden Sie unter „Muss der Webbesucher Cookies aktiviert haben, damit Sitzungsvariablen funktionieren?“.)
Alternativ können wir clientseitigen Code verwenden, um zu verhindern, dass der Browser Webseiten zwischenspeichert:
<html>
<Kopf>
<meta http-equiv="Läuft ab" CONTENT="0">
<meta http-equiv="Cache-Steuerung" INHALT="kein-Cache">
<meta http-equiv="Pragma" CONTENT="kein Cache">
</Kopf>
Wenn Sie mit der oben beschriebenen Methode den Browser dazu zwingen, Webseiten nicht mehr zwischenzuspeichern, müssen Sie folgende Punkte beachten:

„Pragma: no-cache“ verhindert, dass der Browser die Seite nur bei Verwendung einer sicheren Verbindung zwischenspeichert. Bei ungesicherten Seiten wird „Pragma: no-cache“ genauso behandelt wie „Expires: -1“, wobei der Browser die Seite zwar noch im Cache speichert, sie aber sofort als abgelaufen kennzeichnet. In IE 4 oder 5 wird das META HTTP-EQUIV-Tag „Cache-Control“ ignoriert und hat keine Wirkung.
In realen Anwendungen können wir alle diese Codes hinzufügen. Da diese Methode jedoch nicht bei allen Browsern funktioniert, wird sie nicht empfohlen. Aber in einer Intranet-Umgebung kann der Administrator steuern, welchen Browser der Benutzer verwendet. Ich denke, dass einige Leute diese Methode trotzdem verwenden werden.
3. Andere Methoden

Der Ansatz, den wir als nächstes besprechen, konzentriert sich auf die Zurück-Schaltfläche selbst und nicht auf den Browser-Cache. Hier ist ein lesenswerter Artikel zum Thema „Neuverdrahtung der Zurück-Taste“. Mir ist jedoch aufgefallen, dass bei Verwendung dieser Methode der Benutzer beim einmaligen Klicken auf die Zurück-Schaltfläche zwar nicht die Seite sieht, auf der er zuvor Daten eingegeben hat, aber nur zweimal klicken muss. Dies ist nicht der gewünschte Effekt, da sture Benutzer oft Wege finden, Präventivmaßnahmen zu umgehen.
Eine andere Möglichkeit, die Zurück-Schaltfläche zu deaktivieren, besteht darin, mithilfe von clientseitigem JavaScript ein Fenster ohne Symbolleiste zu öffnen. Dadurch wird es für den Benutzer schwierig, aber nicht unmöglich, zur vorherigen Seite zurückzukehren. Ein sichererer, aber ziemlich lästiger Ansatz besteht darin, beim Absenden des Formulars ein neues Fenster zu öffnen und gleichzeitig das Fenster mit dem Formular zu schließen. Ich glaube jedoch nicht, dass dieser Ansatz eine ernsthafte Überlegung wert ist, da wir nicht zulassen können, dass der Benutzer bei jedem Absenden eines Formulars ein neues Fenster öffnet.
Können wir also JavaScript-Code zur Seite hinzufügen, zu der die Benutzer nicht zurückkehren sollen? Der dieser Seite hinzugefügte JavaScript-Code kann verwendet werden, um den Effekt eines Klickens auf die Weiter-Schaltfläche zu erzeugen und so die Aktion auszugleichen, die durch das Klicken des Benutzers auf die Zurück-Schaltfläche generiert wird. Der zur Implementierung dieser Funktion verwendete JavaScript-Code lautet wie folgt

Wie gezeigt:
<script language="JavaScript">
<!--
javascript:window.history.forward(1);
//-->
</Skript>
Auch wenn dieser Ansatz funktioniert, ist er bei weitem nicht der „beste Ansatz“. Später hörte ich, wie jemand vorschlug, location.replace zu verwenden, um von einer Seite zur anderen zu gelangen. Das Prinzip dieser Methode besteht darin, den aktuellen Verlaufsdatensatz durch die URL der neuen Seite zu ersetzen, sodass im Browserverlauf nur eine Seite vorhanden ist und die Zurück-Schaltfläche nie verfügbar wird. Ich denke, das ist vielleicht das, was viele Leute suchen, aber es ist trotzdem nicht für jede Situation der beste Ansatz. Nachfolgend sehen Sie ein Beispiel für diesen Ansatz:
<A HREF="Seitenname.htm" onclick="javascript:location.replace(this.href);
event.returnValue=false;">Deaktivieren Sie den Link zur Rückkehr zu dieser Seite</A>
Backlinks auf diese Seite sind untersagt!
Der Nachteil dieses Ansatzes besteht darin, dass die einfache Verwendung von Response.Redirect nicht mehr funktioniert, da wir jedes Mal, wenn der Benutzer von einer Seite zu einer anderen navigiert, location.history im clientseitigen Code löschen müssen. Beachten Sie auch, dass diese Methode den letzten Zugriffsverlauf löscht, nicht alle Zugriffsdatensätze.
Wenn Sie auf den obigen Link klicken, wird eine einfache HTML-Seite geöffnet. Klicken Sie erneut auf die Zurück-Schaltfläche, und Sie sehen, dass nicht die aktuelle Seite geöffnet wird, sondern die Seite vor dieser Seite! (Natürlich muss clientseitiges JavaScript in Ihrem Browser aktiviert sein.)
Nach einiger sorgfältiger Suche konnte ich immer noch keine Möglichkeit finden, die Zurück-Schaltfläche des Browsers vollständig zu deaktivieren. Alle hier beschriebenen Methoden können Benutzer in unterschiedlichem Ausmaß und auf unterschiedliche Weise daran hindern, zur vorherigen Seite zurückzukehren, sie haben jedoch alle ihre eigenen Einschränkungen. Da es keine Möglichkeit gibt, die Zurück-Schaltfläche vollständig zu deaktivieren, sollte die beste Lösung eine Mischung aus clientseitigen und serverseitigen Skripten sein.

<html>
<Kopf>
<meta http-equiv="Läuft ab" CONTENT="0">
<meta http-equiv="Cache-Steuerung" INHALT="kein-Cache">
<meta http-equiv="Pragma" CONTENT="kein-cache">
</Kopf>
<script language="JavaScript">
<!--
javascript:window.history.forward(1);
//-->
</Skript>
</html>
Asp.net verhindert wiederholte Übermittlungen und Backoffs in einfachen Betriebsmethoden, um Backoffs und Aktualisierungen zu verhindern
In Page_Load hinzufügen
Antwort.Cache.SetNoStore();
//Die in der Sitzung gespeicherte Variable "IsSubmit" wird verwendet, um zu markieren, ob die Übermittlung erfolgreich war
wenn (!IsPostBack)
wenn (Sitzung["IsSubmit"]==null)
Session.Add("IsSubmit",false);
wenn ((bool)Sitzung["IsSubmit"])
{
//Wenn die Formulardaten erfolgreich übermittelt wurden, setzen Sie "Session["IsSubmit"]" auf "false".
Sitzung["IsSubmit"] = falsch;
//Informationen zum erfolgreichen Senden anzeigen
TextBox1.Text = " * Erfolgreich gesendet!";
}
anders
{//Andernfalls (nicht übermittelt oder die Seite wird aktualisiert) werden keine Informationen angezeigt
TextBox1.Text = "";
Antwort.Ende();
}
Schaltfläche „Zum Senden hinzufügen“
Sitzung["IsSubmit"] = true;
Response.Redirect ("diese Seite");

Zusätzlich:
1. Normalerweise sollte die Beurteilung (Einzigartigkeit) auf Geschäftsebene erfolgen, um dieses Problem zu lösen
2. Schreiben Sie Response.CacheControl = "no-cache" in das Seitenladeereignis, um den Cache zu leeren
3. Einige Leute sagten auch: Ich bin schon einmal auf ein solches Problem gestoßen. Es war der Lebenslauf einer Person, der schrittweise übermittelt wurde. Nachdem die erste Seite abgeschlossen war, sprang sie zur zweiten Seite. Um zu verhindern, dass der Benutzer mit der Zurück-Schaltfläche zur ersten Seite zurückkehrt und die erste Seite erneut übermittelt, wird die selbstinkrementierende ID-Nummer des in die Datenbank eingefügten Datensatzes in die Sitzung eingefügt, wenn der Benutzer die erste Seite zum ersten Mal übermittelt. Wenn der Benutzer von der zweiten Seite zur ersten Seite zurückkehrt und die Seite erneut übermittelt, verwende ich den Wert in der Sitzung, um die Datenbank zu überprüfen. Wenn die ID gefunden wird, verwende ich die Update-Anweisung, um die Daten der ersten Seite in die Datenbank zu schreiben. Wenn die ID nicht gefunden wird, verwende ich die Insert-Anweisung.

<<:  Detaillierte Erklärung der vier Arten von MySQL-Verbindungen und Multi-Table-Abfragen

>>:  Steuern Sie die vertikale Mitte des Textes im HTML-Textfeld über CSS

Artikel    

Artikel empfehlen

Lösung für das Problem „Tabelle mysql.plugin existiert nicht“ beim Deployment von MySQL

Heute habe ich die kostenlose Version von MySQL i...

MySQL 5.6.27 Installations-Tutorial unter Linux

In diesem Artikel finden Sie das Installations-Tu...

JavaScript implementiert Klicken zum Ändern der Bildform (Transformationsanwendung)

Klicken Sie mit JavaScript, um die Form des Bilde...

Spezifische Verwendung zusammengesetzter CSS-Selektoren

Kreuzungsauswahl Der Schnittpunktselektor besteht...

So führen Sie das React-Projekt auf dem offiziellen WeChat-Konto aus

Inhaltsverzeichnis 1. Verwenden Sie das „A“-Tag, ...

Zwei Methoden zur Implementierung der Mysql-Remoteverbindungskonfiguration

Zwei Methoden zur Implementierung der Mysql-Remot...

Warum sind die Bilder in mobilen Web-Apps nicht klar und sehr verschwommen?

Warum? Am einfachsten lässt es sich so ausdrücken:...

Vue - benutzerdefinierte gekapselte Schaltflächenkomponente

Der benutzerdefinierte Kapselungscode der Vue-But...

Setzen Sie den Eingang auf schreibgeschützt über deaktiviert und schreibgeschützt

Es gibt zwei Möglichkeiten, schreibgeschützte Eing...

Beispiel für den Aufbau eines Redis-Sentinel-Clusters basierend auf Docker

1. Übersicht Redis Cluster ermöglicht hohe Verfüg...

Detaillierte Erläuterung der drei Möglichkeiten zum Konfigurieren virtueller Nginx-Hosts (basierend auf IP)

Nginx unterstützt drei Möglichkeiten zum Konfigur...

MySQL-Datenbank Daten laden, vielfältige Verwendungsmöglichkeiten

Inhaltsverzeichnis Vielfältige Einsatzmöglichkeit...

CSS3-Animation zum Erzielen des Streamer-Button-Effekts

Beim Erlernen von CSS3 habe ich festgestellt, das...

Viewport-Parameter für mobile Browser (Web-Frontend-Design)

Mobile Browser platzieren Webseiten in einem virtu...

Verwendung des Linux-Befehls bzip2

1. Befehlseinführung bzip2 wird zum Komprimieren ...