Seite nicht gesichert nach Abmeldung und Klick auf die Zurück-Schaltfläche

Question

In meiner vorherigen Anstellung hatte ich das bekannte Problem, dass es mir nicht gelang, den Benutzer davon abzuhalten, nach dem Ausloggen die Seite mithilfe der Zurück-Taste zu navigieren. Meine Technologien umfassen Spring, JavaScript und potenziell das Mobile-Modul der Java AJAX-Bibliothek ZK. Abgesehen vom Navigieren mithilfe der Zurück-Taste funktionierte der autorisierte Zugriff ansonsten einwandfrei. Ich habe keinen Zugriff mehr auf den Anwendungscode. Die Anwendung war eine mobile Anwendung, deren ursprünglicher Autor ich nicht war.

Ich habe die folgenden gängigen Lösungen ausprobiert:

• Habe versucht, einen WebContentInterceptor hinzuzufügen (wie hier beschrieben)
• Habe meinen eigenen Filter definiert, indem ich eine Kombination aus dieser Filterfrage und dieser Antwort zum Einfügen zusätzlicher Filter verwendet habe. Der Filtercode wird während des Debuggens nicht ausgeführt
• Habe RequestMappingHandlerAdapter hinzugefügt, um cacheSeconds auf 0 zu setzen

In t2-spring-security-context.xml haben wir folgende Definition:

Weitere Details zu unserer Implementierung:

• Java-Methoden werden mithilfe von @RequestMapping von JavaScript auf einer als @Controller markierten Klasse aufgerufen (z.B. t2-metrics.jsp hat JS zum Feuern auf eine URL, die dem Request-Mapping entspricht)
• Habe versucht, security:global-method-security zum Anwendungskontext hinzuzufügen und Rollenannotation zur Methode
• Habe Skriptcode hinzugefügt, um das Caching auf den JSP-Seiten zu deaktivieren, was jedoch nichts bewirkte. Habe auch die Anwendung im Debug-Modus in IntelliJ gestartet und ein Debug-Punkt innerhalb meines Filter wird nicht erreicht.
• Sobald sie die Zurück-Taste benutzt haben, um in die Anwendung zurückzukehren, kann der Benutzer immer noch in der Anwendung navigieren.

Meine einzige verbleibende Idee war, dass das Problem möglicherweise in unserem Client-Code (JavaScript) oder in den Bibliotheken (Falsche Integration mit Spring Security) liegt, denn anhand des Debugs scheint die Spring Security Filterkette nicht erreicht zu werden.

Answer 1

Verwenden Sie den folgenden Code in der servlet-context-Datei

Es wird genauso funktionieren wie der folgende Code auf der JSP-Seite:

  response.setHeader("pragma", "no-cache");              
  response.setHeader("Cache-control", "no-cache, no-store, must-revalidate");             
  response.setHeader("Expires", "0");

Answer 2

Rendern Sie die Ansichten (JSPs) direkt?

Wenn ja, fügen Sie die no-cache Direktiven direkt in die JSPs ein:

<% response.setHeader("Cache-Control", "no-cache"); %>
...

Eine weitere (bevorzugte) Option besteht darin, den direkten Zugriff auf die JSPs zu verhindern und sie durch einen Controller zu rendern:

@RequestMapping(value = "/login", method = GET)
public String renderLoginPage() {
    return "login";
}

um die Ansicht nach Name aufzulösen (der vom Controller-Methode zurückgegebene String):

mit /WEB-IBF/views/login.jsp als Ansicht.

Die Verwendung des letzteren Ansatzes ermöglicht die Verwendung des WebContentInterceptor Ansatzes, um das Caching elegant zu verhindern.

Stellen Sie außerdem sicher, dass alle Anfragen die Spring-Sicherheitsfilterkette durchlaufen.

Answer 3

Wir verwenden kein Spring-Sicherheit, daher kenne ich nicht alle seine Konfigurationsattribute, aber wenn ich du wäre, würde ich mich mit Problemen des Browser-Cachings befassen. Sollte einfach zu testen sein... (1) Erzwingen Sie das Neuladen der Seite nach dem Klicken auf die Zurück-Schaltfläche ODER (2) nach dem Abmelden, leeren Sie den Browser-Cache (nicht Cookies) und klicken Sie dann auf die Zurück-Schaltfläche. Wenn dadurch das gewünschte Verhalten erzielt wird, sollte der nächste Schritt die Einbeziehung von HTTP-Antwortheaderattributen zur Steuerung des Browser-Cachings sein.

Wenn das nicht stimmt, wüsste ich nicht, wonach ich in Ihrer Spring Security-Konfiguration suchen soll. Hoffentlich kennt jemand anders die Antwort.

EDIT: Ich habe gerade eine weitere ähnliche Frage gefunden, die den Teil des Browser-Caching-Problems bestätigt - die Antwort auf diese Frage enthält einen Mechanismus, den sie zum Setzen von Antwortheadern verwendet haben, falls das Ihnen helfen sollte - Spring Security Logout Back Button.

Answer 4

Leider kann ich nicht mehr zu diesem Code zurückkehren, um zu lösen, was wir hier getan haben, das verhindert hat, dass wir eine Antwort auf diese Frage erhalten haben. Es ist erstaunlich, was Entwickler erschaffen können, um uns zu verwirren.

Obwohl ich denke, dass dies die Antwort ist (noch zu beweisen), sind die anderen Antworten auch nützlich (und verdienen die Upvotes), sowie diese hier. Die Lösung, die ich damals dachte, war der Front-End-Code, der anstelle eines Spring-Konstrukts wie MVC, das von Spring Security filters gesteuert werden kann, haben wir wahrscheinlich Spring's Schedulers verwendet (siehe Dokumentation hier) und auf irgendeine Weise die Filter-Technologie umgangen, die, wie ich mich erinnere, unerlässlich ist, um Spring Security zu implementieren.

Ich werde versuchen, etwas Front-End-Code zu posten, der zeigt, wie wir unsere REST-Services aufrufen und beweist, dass wir Spring Security umgehen.

Bitte zögern Sie nicht, mich zu kontaktieren, wenn Sie anderer Meinung sind.