Sep 26th, 2012, 10:55 AM
How does SecurityContextHolder work (tracking authenticated users)?
I'm digging through this code but don't understand how this magically works. We're using the default strategy of THREAD_LOCAL which internally uses a ThreadLocalSecurityContextHolderStrategy object. Inside this class I see the ThreadLocal variable for the SecurityContext and while I understand the concept of thread local, I don't understand how two different users hitting the same web application are guaranteed to get their own (and only/just their own) SecurityContext (and thus Authentication and GrantedAuthorities). It's confusing because the call to get the SecurityContext is static. Is there some map or registry backing store?
Can someone please explain this magic?
Sep 26th, 2012, 11:19 AM
Each request that comes into your web app is handled by a single thread. That thread will not be used for any other requests until the current request has completed. If the request goes through Spring Security's filter chain, it will be handled by SecurityContextPersistenceFilter, which *I think* stores the authentication into either thread local or the HttpServletRequest for access by SecurityContextHolder. The filter uses information from the request like the session id cookie or authentication header to figure out who the user is.
Hope this helps,
Last edited by achang; Sep 26th, 2012 at 11:25 AM.
Sep 26th, 2012, 11:57 AM
Ahhh. Excellent. That makes sense. Thanks.
Tags for this Thread