1

I'm working on a legacy app (Spring 2.2.5, Spring Security 2.0.8). Authentication is achieved by custom PreAuthenticationProcessingFilter, where SecurityContext is populated with Authentication object. This authentication is available in most places (be it direct SecurityContextHolder call, or AccessDecisionManager/AfterInvocationProvider arguments). However there are places where Authentication object (accessed by SecurityContextHolder) is null. What is really bizzare is that this happens within single Http request. Class A gets Authentication object, Class B, called later in the stack gets null. Naturally, this happens within the same thread which rules out the simpliest answer to this problem. It appears that despite the thread being the same SecurityContextHolder returns different SecurityContext objects (SecurityContext.toString() returns different memory addresses). What is important is that the place where this happens is not your usual Spring bean. This is a rather custom module subsystem with custom class loader involved and I think that this might have to do something with this bizzare effect.

So the question is: What, besides spawning different thread can cause SecurityContextHolder to "lose" SecurityContext object?

4

1 回答 1

0

这里的关键问题是使用 ThreadLocal 的 SecurityContextHolder 和使用自定义类加载器的子系统。SecurityContextHolder 在类中调用，由自定义类加载器创建，将导致该类加载器加载 SecurityContextHolder 类并使用空上下文对其进行初始化，因此产生上述效果。

所以简而言之，ThreadLocal 和自定义类加载器不能很好地混合，如下所述：

ThreadLocals 和并行类加载的效果

于 2013-09-23T13:24:41.657 回答