+-
据我所知, Spring Security使用过滤器从HttpSession获取SecurityContext,并将其存储到ThreadLocal变量中.处理完请求后,过滤器会将SecurityContext保存回HttpSession.
我的问题是为什么Spring Security不直接使用SecurityContext？
为什么要保存到Threadlocal并再次保存回HttpSession？
我的问题是为什么Spring Security不直接使用SecurityContext？
为什么要保存到Threadlocal并再次保存回HttpSession？
最佳答案
Spring Security有一个可配置的策略来在SecurityContextHolder中存储SecurityContext. ThreadLocal变量只是一种策略.以下是3种策略.
> ThreadLocalSecurityContextHolderStrategy
> InheritableThreadLocalSecurityContextHolderStrategy
> GlobalSecurityContextHolderStrategy
就ThreadLocalSecurityContextHolderStrategy而言,
My problem is way don’t Spring Security just use the SecurityContext directly?
因为Web / Application Server的工作方式在多个供应商(Tomcat,JBOSS)之间并不相同. Spring Security不能100％确定1个线程将仅用于满足一个用户会话.当涉及线程池时,主要可以共享线程.因此,将SecurityContext存储在ThreadLocal变量中并不会使其行为与HttpSession中的行为相同.
Why save to Threadlocal and save back to HttpSession again?
如上所述,相同的线程可用于处理来自不同用户的多个请求.因此,在请求结束时,必须从ThreadLocal变量中腾出SecurityContext,以便下一个请求可以使用它.在HttpSession中的存储是为了在来自同一会话的下一个请求进入时创建SecurityContext.
点击查看更多相关文章
转载注明原文：为什么Spring Security将SecurityContext存储在线程局部变量中 - 乐贴网
