【深入浅出 Spring Security（四）】登录用户数据的获取，超详细的源码分析
登录用户数据的获取
- 一、SecurityContextHolder 源码分析
-
- ListeningSecurityContextHolderStrategy 使用案例
- SecurityContextPersistenceFilter 说明
- 二、登录用户数据的获取
- 三、总结
在【深入浅出Spring Security（一）】Spring Security的整体架构 中叙述过一个SecurityContextHolder 这个类。说在处理请求时，Spring Security 会先从 Session 中取出用户登录数据，保存到 SecurityContextHolder 中，然后在请求处理完毕后，又会拿 SecurityContextHolder 中的数据保存到 Session 中，然后再清空 SecurityContextHolder 中的数据。且说了 SecurityContextHolder 内部数据保存默认是通过 ThreadLocal 来实现的。
下面分析 SecurityContextHolder 的源码，并述说如何在代码中获取登录用户的数据。
(如果不想看源码分析的可以直接跳过看怎么获取用户数据）
一、SecurityContextHolder 源码分析
在分析源码之前，可以看一下下面这个图，它展示了 SecurityContextHolder 和 用户数据信息 的结构关系。SecurityContextHolder 依赖 SecurityContext，SecurityContext 封装了 Authentication，而Authentication 即是我们所指的认证后的用户数据信息。（从这关系以及上面的分析，大概应该可以猜测到 SecurityContextHolder 中用了策略设计模式，命名也都很规范化，~ Context，~ ContextHolder）
策略模式（Strategy）：它定义了算法家族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化，不会影响到使用算法的客户。
既然说它用了策略模式，那SecurityContextHolder中定义的算法家族呢？下面来看一下SecurityContextHolder类中的属性。
public class SecurityContextHolder {
// 指的是算法策略中的ThreadLocalSecurityContextHolderStrategy
public static final String MODE_THREADLOCAL = "MODE_THREADLOCAL";
//InheritableThreadLocalSecurityContextHolderStrategy
public static final String MODE_INHERITABLETHREADLOCAL = "MODE_INHERITABLETHREADLOCAL";
// GlobalSecurityContextHolderStrategy
public static final String MODE_GLOBAL = "MODE_GLOBAL";
// 这个表示不适用任何策略，用原先的HttpSession
private static final String MODE_PRE_INITIALIZED = "MODE_PRE_INITIALIZED";
// 配置名称
public static final String SYSTEM_PROPERTY = "spring.security.strategy";
// 首先是从系统配置中获取
// idea中可以在vmoptions中进行配置，
// 例如：-Dspring.security.strategy=MODE_THREADLOCAL
private static String strategyName = System.getProperty(SYSTEM_PROPERTY);
private static SecurityContextHolderStrategy strategy;
}
可以看见有一个 SecurityContextHolderStrategy 对象 strategy，它就是“算法的封装体”。SecurityContextHolderStrategy 是一个接口，下面是其源代码，比较简单。
public interface SecurityContextHolderStrategy {
// 清除SecurityContext
void clearContext();
// 获取SecurityContext
SecurityContext getContext();
// 存取SecurityContext
void setContext(SecurityContext context);
// 得到一个空的SecurityContext
SecurityContext createEmptyContext();
}
看下图可以知道算法家族的成员。
-
ThreadLocalSecurityContextHolderStrategy：存储数据的载体是一个 ThreadLocal，所以针对 SecurityContext 的清空、获取以及存储，都是在 ThreadLocal 中进行操作。源码过于简单，不分析了，自己看吧。
-
InheritableThreadLocalSecurityContextHolderStrategy：和前者实现策略没有区别，只不过用的是ThreadLocal的子类InheritableThreadLocal，这样子线程和父线程都可以获取到用户数据了。源码也没啥，自己看看就OK了。
-
GlobalSecurityContextHolderStrategy：它实现起来就更更更简单了，直接用个静态变量保存 SecurityContext，所以多线程环境下它是可以使用了，但一般在web开发中，这肯定是使用的少的。
-
ListeningSecurityContextHolderStrategy：SecurityContext 的事件监听策略，它是5.6版本后推出来放到SecurityContextHolderStrategy 策略中的。《深入浅出 Spring Security》书中并没有提到它，但我还是有必要了解的。使用它可以在不去配置系统配置的情况下更换策略，也可以监听 SecurityContext 的创建和销毁事件。注意这里没有获取事件。- 它构造方法进行了重载，可以看一下（有些构造源码上说5.7更新的，不管了，现在都 6点 多了），一些判断是否为空的代码我就去调了，留核心代码。
public final class ListeningSecurityContextHolderStrategy implements SecurityContextHolderStrategy {
// 监听器集合
private final Collection<SecurityContextChangedListener> listeners;
// 委托策略对象，默认的话也是ThreadLocalSecurityContextHolderStrategy
private final SecurityContextHolderStrategy delegate;
public ListeningSecurityContextHolderStrategy(Collection<SecurityContextChangedListener> listeners) {
this(new ThreadLocalSecurityContextHolderStrategy(), listeners);
}
public ListeningSecurityContextHolderStrategy(SecurityContextChangedListener... listeners) {
this(new ThreadLocalSecurityContextHolderStrategy(), listeners);
}
public ListeningSecurityContextHolderStrategy(SecurityContextHolderStrategy delegate,
Collection<SecurityContextChangedListener> listeners) {
this.delegate = delegate;
this.listeners = listeners;
}
// 可变参数重载，可进行配置自己想要的策略对象(delegate)
public ListeningSecurityContextHolderStrategy(SecurityContextHolderStrategy delegate,
SecurityContextChangedListener... listeners) {
this.delegate = delegate;
this.listeners = Arrays.asList(listeners);
}
在看看它的其他源码，在创建和销毁 SecurityContext 的时候会调用监听器去监听。
@Override
public void clearContext() {
SecurityContext from = getContext();
this.delegate.clearContext();
publish(from, null);
}
@Override
public SecurityContext getContext() {
return this.delegate.getContext();
}
@Override
public void setContext(SecurityContext context) {
SecurityContext from = getContext();
this.delegate.setContext(context);
publish(from, context);
}
@Override
public SecurityContext createEmptyContext() {
return this.delegate.createEmptyContext();
}
// 执行监听措施
private void publish(SecurityContext previous, SecurityContext current) {
if (previous == current) {
return;
}
SecurityContextChangedEvent event = new SecurityContextChangedEvent(previous, current);
for (SecurityContextChangedListener listener : this.listeners) {
listener.securityContextChanged(event);
}
}
监听器SecurityContextChangedEvent 是一个函数式接口，咱配置的时候直接使用 lambda 就好了。
讲了半天的策略，回归策略的封装者 SecurityContextHolder。来看看它的初始化操作，它是提供了一个静态代码块，执行初始化。
static {
initialize();
}
private static void initialize() {
initializeStrategy();
initializeCount++;
}
private static void initializeStrategy() {
// 首先判断是否是不使用策略
if (MODE_PRE_INITIALIZED.equals(strategyName)) {
Assert.state(strategy != null, "When using " + MODE_PRE_INITIALIZED
+ ", setContextHolderStrategy must be called with the fully constructed strategy");
return;
}
// 然后判断是否为空，为空就默认设置为ThreadLocalSecurity...
if (!StringUtils.hasText(strategyName)) {
// Set default
strategyName = MODE_THREADLOCAL;
}
// 这后面就一系列的判断没啥。
if (strategyName.equals(MODE_THREADLOCAL)) {
strategy = new ThreadLocalSecurityContextHolderStrategy();
return;
}
if (strategyName.equals(MODE_INHERITABLETHREADLOCAL)) {
strategy = new InheritableThreadLocalSecurityContextHolderStrategy();
return;
}
if (strategyName.equals(MODE_GLOBAL)) {
strategy = new GlobalSecurityContextHolderStrategy();
return;
}
// Try to load a custom strategy
try {
// 如果以上都没匹配到的话，就默认使用的是类的全路径引出策略
// 通过反射去构造
Class<?> clazz = Class.forName(strategyName);
Constructor<?> customStrategy = clazz.getConstructor();
strategy = (SecurityContextHolderStrategy) customStrategy.newInstance();
}
catch (Exception ex) {
ReflectionUtils.handleReflectionException(ex);
}
}
了解了其如何进行初始化的后，那就好办了，直接看它内部方法吧。其内部方法都是静态的。
// 清除SecurityContext
public static void clearContext() {
strategy.clearContext();
}
// 获取SecurityContext
public static SecurityContext getContext() {
return strategy.getContext();
}
// 初始化次数，emmm，发送请求的次数？
public static int getInitializeCount() {
return initializeCount;
}
// 配置SecurityContext
public static void setContext(SecurityContext context) {
strategy.setContext(context);
}
// 配置StrategyName
public static void setStrategyName(String strategyName) {
SecurityContextHolder.strategyName = strategyName;
initialize();
}
// 出于5.6版本，估计是让你更好的配置监听策略用的，事实上也就这个方法可以做到了
public static void setContextHolderStrategy(SecurityContextHolderStrategy strategy) {
Assert.notNull(strategy, "securityContextHolderStrategy cannot be null");
SecurityContextHolder.strategyName = MODE_PRE_INITIALIZED;
SecurityContextHolder.strategy = strategy;
initialize();
}
// 获取策略对象
public static SecurityContextHolderStrategy getContextHolderStrategy() {
return strategy;
}
// 创建空的SecurityContext
// 也就是创建SecurityContextImpl
public static SecurityContext createEmptyContext() {
return strategy.createEmptyContext();
}
源码分析到这，差不多就很清晰了，再看看SecurityContextImpl的源码吧，其实不用看也知道，就是 Authentication 对象的封装，这看一下属性和构造就差不多可以猜到大概了。
最后还需要注意：ThreadLocalSecurityContextHolderStrategy、InheritableThreadLocalSecurityContextHolderStrategy、GlobalSecurityContextHolderStrategy 访问权限都是default默认的，不是本包下的是不让new的，也就是对外不让实例化，你只能通过它给的进行对内策略更改。
ListeningSecurityContextHolderStrategy 使用案例
@Component
@Slf4j
public class InitCommandRun implements CommandLineRunner {
@Override
public void run(String... args) throws Exception {
// 配置 InheritableThreadLocalSecurityContextHolderStrategy
SecurityContextHolder.setStrategyName(SecurityContextHolder.MODE_INHERITABLETHREADLOCAL);
// 去获取这个策略对象
SecurityContextHolderStrategy initStrategy = SecurityContextHolder.getContextHolderStrategy();
// 将获取到的策略对象用到监听策略中，当委托策略
SecurityContextHolderStrategy strategy = new ListeningSecurityContextHolderStrategy(
initStrategy,
event -> {
if(event.getNewContext() != null)
log.warn("new context->{}",event.getNewContext());
});
SecurityContextHolder.setContextHolderStrategy(strategy);
}
}
测试结果
SecurityContextPersistenceFilter 说明
Persistence（持久性）。
在【深入浅出Spring Security（二）】Spring Security的实现原理 中概述了Spring Security 中默认加载的过滤器，SecurityContextPersistenceFilter 即是其中的一员。它的作用是为了存储 SecurityContext 而设计的。
它整体来说做了两件事：
- 当一个请求到来时，从 HttpSession 中获取 SecurityContext 并存入 SecurityContextHolder 中，这样在同一个请求的后续处理过程中，开发者始终可以通过 SecurityContextHolder 获取到当前登录用户信息。
- 当一个请求处理完毕时，从 SecurityContextHolder 中获取 SecurityContext 并存入 HttpSession 中（
主要针对异步 Servlet，不是异步的相应提交自动就会保存到HttpSession中），方便下一个请求到来时，再从 HttpSession 中拿出来使用，同时擦除 SecurityContextHolder 中的登录用户信息。
下面是 SecurityContextPersistenceFilter 过滤器的核心代码（下面出现的 repo 是 SecurityContextRepository 对象，默认是HttpSessionSecurityContextRepository对象）：
private void doFilter(HttpServletRequest request, HttpServletResponse response, FilterChain chain)
throws IOException, ServletException {
// 获取 SecurityContext 对象
HttpRequestResponseHolder holder = new HttpRequestResponseHolder(request, response);
SecurityContext contextBeforeChainExecution = this.repo.loadContext(holder);
try {
// 存入到 SecurityContextHolder 中
SecurityContextHolder.setContext(contextBeforeChainExecution);
// 让下一个过滤器处理请求
chain.doFilter(holder.getRequest(), holder.getResponse());
}
finally {
// 请求结束后清楚SecurityContextHolder 中的用户信息
// 并把信息保存在HttpSession中
SecurityContext contextAfterChainExecution = SecurityContextHolder.getContext();
// Crucial removal of SecurityContextHolder contents before anything else.
SecurityContextHolder.clearContext();
this.repo.saveContext(contextAfterChainExecution, holder.getRequest(), holder.getResponse());
request.removeAttribute(FILTER_APPLIED);
}
}
注意：SecurityContextPersistenceFilter被标记为已过时（Deprecated），但它仍然被包含在Spring Security默认的过滤器链中。这是因为虽然存在一些问题，但它仍然是一个广泛使用的过滤器，并且在某些情况下仍然是有用的。新版本是去拿 PersistentTokenBasedRememberMeServices 去取代它。
二、登录用户数据的获取
通过上面的源码分析呢？咱可以知道如何获取用户信息了（Authentication）。
调用 SecurityContextHolder 中的 getContext() 静态方法获取其对应策略中保存的 SecurityContext 对象，再调用 getAuthentication() 方法获取 Authentication 对象。
@RestController
public class TestController {
@GetMapping("/test")
public Object test(){
Authentication authentication = SecurityContextHolder.getContext().getAuthentication();
User user = (User) authentication.getPrincipal();
/*return "Spring Security Test Success！";*/
return user;
}
}
getPrincipal() 是去获取主要的用户信息，它是一个User对象，所以可以进行强转。
测试效果
由于我做了如下配置，所以即使在多线程情况下，也是可以使用的（子线程可以用父线程中的 SecurityContext）。
三、总结
- SecurityContextPersistenceFilter 完成了 SecurityContext 的存储和擦除；
- 在 5.6 版本（准确来说是5.7）后引入了
ListeningSecurityContextHolderStrategy监听SecurityContext策略； - 可以使用 SecurityContextHolder.getContext.getAuthentication() 的方式获取登录用户数据；
- SecurityContext 的存储和擦除内部用了策略设计模式，SecurityContextHolder 中定义了 SecurityContextHolderStrategy 策略，去获取、擦除、存储SecurityContext。
当使用 ListeningSecurityContextHolderStrategy 时，可以向如下这样使用。当然它默认的执行策略是 ThreadLocalSecurity… ，所以当不需要换策略的话直接用监听器对象当构造参数构造即可，如果想切换成多线程，就像如下那样配置吧。
当然也可以去配置idea的vmoptions参数，但小编并不觉得它是个好主意。你觉得呢？