SecurityContextHolder可以跨用户共享

Question

回答这个问题securitycontextholder-session-or-request-bound。我正在使用此示例how-to-customAuthenticationManager实现CustomAuthenticationManager。事实证明，我的用户体验得到了持续会话。

例如，用户A与Web App交互，有时在访问配置文件时，用户A可以获得用户B配置文件（这是因为应用程序从SecurityContextHolder的主体检索UserProfileLoggedIn并访问数据库）并且同时用户B已登录，但可能不访问个人资料。

我想知道这是一个SecurityContextHolder漏洞吗？我知道SecurityContextHolder只是一种实现HttpSession作为容纳userDetails等的容器的方法。

现在，遇到问题后，我将customAuthenticationManager更改为customAuthenticationProvider。有关其他信息，用户在中午约有100-500个并发用户。

有关其他信息，我正在我的@Service类中实现SecurityContextHolder，因此可以轻松获得另一个团队成员

@Service
public MyServiceImpl implement MyServiceInterface{
    public UserDetail findUser(){
       return (UserDetail) SecurityContextHolder.getContext().
              getAuthentication().getPrincipal();
     }
}

Answer 1

默认情况下，SecurityContextHolder的实现绑定到ThreadLocal的实例：

• 它可以扩展，就像容器为Spring Security提供同步线程一样。
• 抽象不是HttpSession的实现;但是，它提供了与底层HTTP Servlet提供程序的集成，以将HTTP安全信息传输到Spring管理的应用程序层。
• ThreadLocal上的组合使API的用户能够利用不同线程中的多个数据视图。这也是为什么如果你的HTTP容器中有适当的线程配置，你就不应该在用户数量方面存在可扩展性问题。

Answer 2

我终于找到了代码中的基本问题。我的团队成员之一，在@Service Class中添加一个变量......就像这样....

@Service 
public AnotherServiceImpl implements AnotherService{

  UserDetail userdetail;  //This is hillarious

  @Autowired
  MyServiceImpl myService;

  @Override
  public .......

   //......
}

显然我没有看到即将到来.....删除“UserDetail”变量后，一切都回来了，因为它应该是..谢谢，我希望有人可以从我的“愚蠢”错误中吸取教训