All geek questions in one place

How is Spring Security currently logging in to the user in concept?

I get a registered user SecurityContextHolder.getContext().getAuthentication() on the server side and do some user registrations.

Here's the question: Suppose I have three users. How the server side can identify the user simply by calling SecurityContextHolder.getContext().getAuthentication(); ?

Thanks for your reply.

+4
source share
2 answers

By default, there are 3 important things here:

  • HTTP session - saves the authentication object between requests
  • Servlet API filter - populates the SecurityContextHolder before each request from the HTTP session (and saves the authentication object after the request is completed)
  • ThreadLocal - saves authentication object during request processing

After authentication, the corresponding SecurityContext is stored in the HTTP session. Before each request processing, a special SecurityContextPersistenceFilter is launched. He is responsible for loading the SecurityContext object from the HTTP session (through the SecurityContextRepository instance) and for injecting the SecurityContext object into the SecurityContextHolder . Take a look at the source code for the SecurityContextPersistenceFilter class for more details. Another important part is that, by default, the SecurityContextHolder stores the SecurityContext object using the ThreadLocal variable (so that you will have another authentication object in the stream).

EDIT. Additional questions:

  • The HTTP session is stored in the client browser and is updated between requests. No, the HTTP session is stored on the server side. It is associated with some user through a coockie session (the browser sends this cookie during each request).
  • SecurityContext, SecurityContextHolder, and SecurityContextRepository are server-side instances. They are used on the server side. But SecurityContextHolder not an instance, it is a helper class with static methods.
  • ThreadLocal is a variable that stores the SecurityContextHolder that stores the SecurityContext No, the SecurityContext is stored in the ThreadLocal variable. SecurityContextHolder - a helper class that can be used to get / set an instance of SecurityContext using the ThreadLocal variable.
  • If there are three connections, there will be three SecurityContext objects in the Server. Yes.
  • One SecurityContextHolder saves one SecurityContext No, the same static SecurityContextHolder methods that are used by all threads to get / set the corresponding SecurityContext .
  • And suppose there are three instances of SecurityContext on the server side, how does he know which one refers to the corresponding client? ThreadLocal variable has different values ​​for different threads.
+7
source

Each logged-in user will have different sessions. Each session has its own configuration. Therefore, on the server side of SecurityContext load session specific data. You can visualize data in SecurityContext as a map (key-value) pair.

0
source

Source: https://habr.com/ru/post/1497949/

More articles:


All Articles