In SpringSecurity hat es den Klassennamen SecurityContextHolder und seine Spezifikation: 'Verknüpft einen bestimmten SecurityContext mit dem aktuellen Ausführungsthread.' Mit Web-Anwendung, wann immer eine Anfrage an den Server kommt, lädt Spring auch SecurityContext dieser Anfrage in SecurityContextHolder für seinen Thread neu und setzt sie.
Ja, der SecurityContextPersistenceFilter wird ausgeführt Sorge dafür. Standardmäßig findet es den SecurityContext in der HttpSession und bindet ihn über den SecurityContextHolder an den Thread. Wenn die Anfrage beendet ist, wird das Gegenteil getan - es wird der SecurityContext aus dem Thread genommen und in die Sitzung eingefügt.
Aus dem Javadoc:
Füllt den SecurityContextHolder mit Informationen, die er von der konfigurierte SecurityContextRepository vor der Anfrage und speichert sie es zurück in das Repository, sobald die Anfrage abgeschlossen und gelöscht wurde der Kontexthalter. Standardmäßig verwendet es ein HttpSessionSecurityContextRepository.
Mit Web-Anwendung, wann immer eine Anfrage an den Server kommt, lädt Spring auch SecurityContext dieser Anfrage in SecurityContextHolder für seinen Thread neu und setzt sie.
Grundsätzlich ja.
Das Standardverhalten von SecurityContextHolder.getInstance() besteht darin, eine SecurityContextHolder -Instanz zurückzugeben, die als Thread-Local des aktuellen Threads gespeichert wurde. (Dies ist nur der Standardmechanismus. Sie können eine andere Strategie verwenden, um SecurityContextHolder zu finden, indem Sie SecurityContextHolder.setStrategemName() aufrufen)
Ein SpringSecurity-Filter stellt sicher, dass das SecurityContextHolder der Anfrage (wie auch immer es sich befindet) zu Beginn mit den Anforderungsinformationen geladen wird und dass der Inhaber am Ende der Anforderungsverarbeitung gelöscht wird.
Tags und Links java multithreading spring spring-security