Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
SEC-1455: SecurityNamespaceHandler problems in OSGi environment, need to import spring-security-web packages #1695
Imagine the following situation: there is an OSGi (in my case DM Server) environment, which contains some bundles. One of them uses the security namespace to protect some methods. This bundle has nothing to do with the web, this is the responsibility of the web bundle, which contains some web pages and expose some of the services from that bundle. . Within the web bundle, a filter-chain-map is used to protect some URLs.
The manifest of the first bundle imports some Spring Security related packages, but not org.springframework.security.web, this package is only imported by the web bundle. The SecurityNamespaceHandler seems to be a singleton, and when the org.springframework.security.web.FilterChainProxy is not available on the classpath when the SecurityNamespaceHandler is loaded for the first time (in my case, when the first bundle is started), an exception will be thrown when another bundle is using the security:http and security:filter-chain-map elements.
Daniël van 't Ooster said:
see the attached jars or eclipse projects.
They are tested on dm server 2.0.1 with spring security 3.0.0. First start bundle1 which will create an instance of the security namespace handler. After that, start bundle2, it will give the problem as described in the case. Imho the problematic code is in the SecurityNamespaceHandler:
Because this is a singleton and the org.springframework.security.web class it not imported in bundle1 (imaging bundle1 has nothing to do with the web), the handler cannot handle the http related elements.
Christopher Frost said:
Luke has asked me to look at this as I work on dm Server and will have a little more insight from that point of view, I haven't managed to get to it today but I understand the issue. I need to recreate it and have a look myself, will do so next week.
Christopher Frost said:
I've looked in to this and tried deploying you test bundles with different headers. Your diagnoses is correct, because the SecurityNamespaceHandler is a singleton and the way it loads the web stuff if you want to use the web elements anywhere in an instance of the dm Server then the first bundle loaded that uses security must import the security web bundle, bundles after that don't matter. This should not impact what you need to have deployed as the security.web bundle is required by the security.config bundle anyway. This is far from ideal though, having to have this unintuitive import but from OSGi's point of view it is working as intended. This isn't even a dm Server issue, it's fundamental OSGi. A better solution to get around the singleton issue would be to make the code in the security.config bundle a little smarter about OSGi, as it imports the security.web bundle anyway I would want this 'if statement' to always return true in an OSGi environment, i.e. be aware of the OSGi classloader system.
Luke, please ping me if you want to discuss...
P.S. Thanks for the well cut-down test bundles, made recreating it a breeze.
Luke Taylor said:
Apparently dmServer has some specialized internal behaviour related to classloading and namespace-handling (bundles which contain spring.schemas files), so this may account for why the web classes are not visible, even though they are declared in the config bundle. I have altered the code to attempt to load the parsers when they are required, rather than just when the init() method is called (which presumably only happens the first time the class is registered). This appears to solve the problem, though the second test bundle fails to deploy because it doesn't import the package that contains BasicAuthenticationFilter. Adding the import solves that problem too.