-
Notifications
You must be signed in to change notification settings - Fork 6.1k
Description
Now that applications can use a SecurityContextHolderStrategy
bean, there's value in assisting applications with what may be a sizeable transition away from using SecurityContextHolder
.
There are some cases where an application may not want to copy the SecurityContextHolderStrategy
bean into SecurityContextHolder
's static field:
- The application may not want to risk potential memory leaks from setting a bean to a static field
- The application uses more than one application context, each with a
SecurityContextHolderStrategy
. Given that arrangement, it is undefined which bean will be set to the static field. - The application may want to discourage the use of static lookups.
- The application may otherwise need more control over deciding what goes into the static field.
Given the foundational nature of SecurityContextHolder
in Spring Security, it's likely that applications for a time will want to assume the above risks. As such, this should be property-driven.
One way to do this is to introduce useSecurityContextHolder
into @EnableWebSecurity
. It would default to true
.
If useSecurityContextHolder
is true, then Spring Security will look for a SecurityContextHolderStrategy
bean and call SecurityContextHolder.setSecurityContextHolderStrategy
. If it's false, then no action will be taken.