In SpringSecurity it has a class name SecurityContextHolder and its spec: 'Associates a given SecurityContext with the current execution thread.' With web application whenever a request comes to server then Spring also reload and set SecurityContext of that request in SecurityContextHolder for its thread?
Yes, the SecurityContextPersistenceFilter takes care of this. By default it locates the SecurityContext in the HttpSession and binds it to the thread via the SecurityContextHolder. When the request is finished processing it does the reverse - it takes the SecurityContext from the thread and puts it in the session.
From the Javadoc:
Populates the SecurityContextHolder with information obtained from the configured SecurityContextRepository prior to the request and stores it back in the repository once the request has completed and clearing the context holder. By default it uses an HttpSessionSecurityContextRepository.
With web application whenever a request comes to server then Spring also reload and set SecurityContext of that request in SecurityContextHolder for its thread?
Basically yes.
The default behavior of SecurityContextHolder.getInstance()
is to return a SecurityContextHolder
instance that it stored as a thread-local of the current thread. (This is only the default mechanism. You can use a different strategy for locating the SecurityContextHolder
by calling SecurityContextHolder.setStrategemName()
)
A SpringSecurity filters ensure that the request's SecurityContextHolder
(however it is located) is loaded with the request credentials at the start and that the holder is cleared at the end of request processing.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With