-
Notifications
You must be signed in to change notification settings - Fork 6.1k
SecurityContextHolder setDeferredContext(Supplier<SecurityContext>) / Supplier<SecurityContext> getDeferredContext() #10913
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Is this referring to the situation mentioned in https://docs.spring.io/spring-security/reference/servlet/authentication/architecture.html#servlet-authentication-securitycontextholder ? Should it change? SecurityContext context = SecurityContextHolder.createEmptyContext();
Authentication authentication = new TestingAuthenticationToken("username", "password", "ROLE_USER");
context.setAuthentication(authentication);
SecurityContextHolder.setContext(context); |
@linghengqian You would still be allowed to use the methods that you provided, but there will be additional methods to support delayed lookup of the |
Uh oh!
There was an error while loading. Please reload this page.
In order to support a lazy access of the
SecurityContext
we should add methods to theSecurityContextHolder
that allow setting and getting aSupplier<SecurityContext>
. A benefit is that if it takes some work to obtain theSecurityContext
, the it is only looked up if necessary.For example, currently the
SecurityContext
is looked up from theHttpSession
for every page. When using distributed sessions (i.e. Spring Session + Redis) this is a lot of unnecessary overhead for accessing public css, javascript, and images. With these changes Spring Security can avoid accessing theHttpSession
for public resources like javascript, css, images, public html pages, etc.The context would be set like this:
Then code that wasn't sure if the
SecurityContext
was needed could use:If the
AuthorizationManager
did not need to access theSecurityContext
(i.e. public invocation was allowed), it would not ever access theSupplier<Authentication>
and thus theSupplier<SecurityContext>
wouldn't be accessed either.These changes will largely be internal and not impact users.
This is blocked by
The text was updated successfully, but these errors were encountered: