Feb 14th, 2012, 11:26 AM
Issue with Spring Security PrePost scanner not picking up some beans
In a spring MVC application, I am having issues with the scanning only picking up certain classes when looking for protected methods.
In this case, there is a child context (for MVC) with the global-method-security namespace tag. All beans in the child context are scanned for method security.
There is a parent context which contains the managers, daos, etc, which includes the primary spring-security configuration, and also includes a global-method-security namespace tag.
Unfortunately, only some of the beans in the parent context are scanned for method security. I am unable to recognize a pattern as to which classes are scanned and which are not. In all cases, some classes within one context file are scanned, while others are not. For example, only 2 classes in the security-context.xml are scanned, while all of the other beans are ignored.
There are no errors on startup with both org.springframework and org.springframework.security set to trace debugging (which is how i can tell that only some classes are scanned).
Does anyone have any pointers as to the means used to determine which classes are or are not scanned for method level security? Is there a location where I might place a breakpoint in the spring security code to attempt to discover why the classes absent are excluded from scanning?
Please let me know if there is any additional information I can provide to help get closer to an answer.
Feb 14th, 2012, 03:03 PM
I found the answer to this after many hours of debugging by placing a breakpoint on AbstractBeanFactory.addBeanPostProcessor(BeanPostP rocessor) and observing that only ApplicationContextAware and ServletContextAware were registered before the instantiation of my beans. It turns out, I guess, that the security annotation post-processor does not get registered until after the full security framework is instantiated, so any beans which are dependencies of the framework or dependencies of those dependencies are not protectable.
My solution to the problem for now is to provide those dependencies by method injection (lookup-method). Is there a better way to accomplish this?
Feb 29th, 2012, 05:07 AM
I was running into the same problem: protecting resources using a PermissionEvaluator which would access one of the DAO's. Naturally, only that DAO was not protected, and I couldn't figure out why.
It seems to me that it would be impossible to initialize a bean before the security framework and still apply method security as Spring won't be able to create the proxies which enforce the security as long Spring Security is not initialized. Your lookup-method is a nice hack around that dependency, because it defers the need for initialization to when the method is invoked.
Idea for an enhancement: Would it be possible to log a WARNING, so a user knows that a class is not being scanned because of a dependency?