Web-Design: "Zurück" verhindern

[Glombi]

Folgendes Problem: Ich habe eine Anwendung, in der der Web-User ein Dokument mit Speichern & Schließen verlassen kann. Daraufhin läuft ein Script-basierter Agent, der gewisse Felder setzt und den User dann die Ausgangsansicht anzeigt.
Wie verhindere ich, dass der User mit "Zurück" wieder ins Dokument kommt?
Über die Ansicht soll er natürlich in das Dokument kommen.

Irgendwie stehe ich da nun auf dem Schlauch.

Danke für alle Tipps.
Andreas

[Thomas Schulte]

gar nicht.
Du kannst zwar die Menü Leiste ausblenden, aber im Extremfall gibt jemand einfach Javescript:Goback() ein und das wars dann.

Wenn du das verhindern willst dann musst du über eine Hilfskonstruktion gehen eine DocEditID die immer unique ist oder so was.

[Glombi]

Ich werde mal folgendes versuchen:

@SetHTTPHeader("Cache-Control";"no-cache");
@SetHTTPHeader("Pragma" Content";"no-cache");
@SetHTTPHeader("Expires";"0")

Oder spricht was dagegen?

Andreas

[Ayhan]

Hi,

es geht dir soviel ich verstanden habe darum, dass der user auf diese "Zwischenseite" nicht gelangen soll, da dies evtl. in deiner Anwendung zu Fehlern führen könnte.

Ich habe mal in einer solchen Anwendung (das aktuelle Dokument wird bei mir als XML auf dem File-System abgelegt, dann parse ich das XML auf gültigkeit, nehme evtl. korrekturen vor, danach erstelle ich daraus ein PDF etc.; an sich sollte dies nur dann passieren, wenn der User wirklich nur auf Speichern klickt und nicht wenn der User ausversehen auf ZURÜCK in seinem Browser klickt) folgendes gemacht:
1. Der User befindet sich in einem Dokument im Bearbeitungsmodus
2. Möchte er das Dokument speichern drückt er auf den Knopf speichern.
3. Nun öffnet sich ein kleines PopUp-Fenster (hier übergebe ich die Aktion [speichern] + die DOK-ID). Dieses Pop-UP ist eine weitere Maske in der Anwendung mit einem WQO-Agenten. Dieser lädt über eine JS-Funktion die ich über ein RTITEM generiere, nach erfolgreicher Ausführung die ursprungsdokument im Lesemodus neu auf (<script>opener.document.location.href='/db.nsf/ansicht/id?OpenDocument'</script> (die ID des entsprechenden Dokumentes habe ich ja über das PopUP als Parameter mitgegeben.

Damit verhindere ich, dass ein User direkt über den Zurück-Link die Verarbeitungsmaske aufruft. Im IE kann man sogar das Pop-Up-Fenster verstecken (das Fenster an sich wird von PopUP-Blockern nicht geblockt, da der User durch einen Klick den PopUP aufruft und dieser nicht automatisch startet).

Hilft das evtl. weiter?

Nachtrag:
Natürlich kannst du dem JS auch sagen, dass er statt das Dokument im Lesemodus neuzuladen eine Ansicht öffnen soll. Klickt der Benutzer nun in diesem Fenster auf zurück, landet er wieder in seinem Dokument. Mit deinen zusätzlichen Headern verhinderst du evtl. Caching.

[flaite]

@SetHTTPHeader("Cache-Control";"no-cache");
@SetHTTPHeader("Pragma" Content";"no-cache");
@SetHTTPHeader("Expires";"0")

Oder spricht was dagegen?

Ich denke, dass dies nicht reicht.
So schaltest du den cache aus. Aber der Request geht immer noch gegen den Server und läd von dort eine neue Seite.
Was du aber willst ist die history ausschalten. Das sind afaik 2 verschiedene Sachen.
Im Grunde handelt es sich hier um eines der härtesten Probleme der Webprogrammierung.
Mit diesem google Search erhälst du einige mehr oder weniger umfassende Erörterungen:
http://www.google.de/search?hl=de&q=disable+back+button+browser&btnG=Google-Suche&meta=
Der Vorschlag von Ayhan hört sich eigentlich gangbar an.
Es gibt vielleicht noch andere trickige Möglichkeiten, die ich aber nie ausprobiert habe.

[Glombi]

Ok, das mit dem Cache löst das Problem wohl nicht.

Mitr fällt nun nur noch ein, mittels location.replace in Javascript die Historie zu überschreiben.

Andreas

[Ayhan]

Hi,

hab mal den Link von Axel verfolgt und diesen Artikel gefunden:

http://www.htmlgoodies.com/tutorials/buttons/article.php/3478911

1. Du rufst deine Maske mit dem WQO-Agenten auf, verarbeitest das Dokument.
2. Du rufst ein neues Fenster mit deiner Ansicht auf.
3. Im Zuge von Schritt 2 schließst du das Hauptfenster

Hört sich doch gut an (bis auf die Tatsache, dass das Fenster öffnen und schließen dem Benutzer mal auf die Nerven gehen könnte).

[m3]

1. Du rufst deine Maske mit dem WQO-Agenten auf, verarbeitest das Dokument.
2. Du rufst ein neues Fenster mit deiner Ansicht auf.
3. Im Zuge von Schritt 2 schließst du das Hauptfenster

Das Problem ist nur, dass er nachfragt, ob der das Ursprungsfenster schließen soll. Ausser Du verwendest ein signiertes JavaScript.

[flaite]

Wenn du den google link mal nachgehst, findest du eventuell etwas, das für deinen Fall passt.
Den Königsweg gibt es für diese Back-Button Probleme einfach nicht.

Übrigens funktionieren Back Buttons auch bei vielen JSR 168 Portalen (JBoss Portal, IBM Websphere Portal, Jetspeed, etc.) nicht richtig. Hat was damit zu tun, dass http von Hause aus einfach sehr stateless ist und die Synchronisation zwischen dem State auf dem Browser und dem auf dem Server einfach kein triviales Problem darstellt.

[Ayhan]

Ok,

dann 2 weiter Möglichkeiten:

1) Thomas Idee: Beim speichern generierst du erst ein Dokument in der DB und übergibst die ID  an dein Zwischenfenster mit. Beim Aufrufen dieser Maske überprüfst du, ob in der DB ein Dokument mit der ID noch existiert. Wenn ja, rufst du deinen Agenten auf und führst ihn aus und löschst danach dein Dokument - wenn nicht, dann machst du einen redirect auf deine Ansicht.

2) Wenn dir Prototype oder JSON etwas sagen, könntest du dein Dokument ohne Zwischenfenster speichern + verarbeiten. Ich habe es im kleinen Stile mal ausprobiert (Dokument speichern und mit einem Agenten verarbeiten - hat geklappt). Auf www.codestore.net findest du dazu einige Beispiele von Jake Howlett.