Igor Mihalik (Migrated from SEC-1627) said:
There's a problem if spring-security is used in application deployed to dmServer. At happens when "global-method-security" is defined in spring context. When using "global-method-security" "org.springframework.security.config.method.ProtectPointcutPostProcessor" is created. However in dmServer "OsgiServiceFactoryBean" bean is created by default in application context and "PPPP" tries to match "OSFB" with the given expression.
If application bundle does not "import" package "org.springframework.osgi.service.exporter.support" an exception is thrown (attached). One option is to declare "import" in spring-security-config bundle, however that would bias spring-security towards dmServer.
Other option, and that is what is proposed in this improvement, suggests to modify the attemptMatch (#107) method in org.springframework.security.config.method.ProtectPointcutPostProcessor to handle reflection exception.
Currently attemptMatch reads like this:
// Determine if the presented AspectJ pointcut expression matches this method
boolean matches = expression.matchesMethodExecution(method).alwaysMatches();
Proposed change:
// Determine if the presented AspectJ pointcut expression matches this method
boolean matches = false;
try {
matches = expression.matchesMethodExecution(method).alwaysMatches();
} catch (ReflectionWorld.ReflectionWorldException ex) {
// no match
}
An exception occurring there could easily be interpreted as a non match.
Note: this improvement suggestion was submitted directly to SpringSource via support channel by customer.
Comment From: spring-projects-issues
Luke Taylor said:
Could you clarify what the attemptMatch is actually trying to match against when the exception is thrown?
I'm kind of reluctant to add code which treats an exception as a non-match as I'm not sure whether it could occur in other situations and cause a security constraint to be silently bypassed.
Comment From: spring-projects-issues
Stefan Reuter said:
It tries to match the pattern against the methods of OsgiServiceFactoryBean which is included in the application context by Spring-DM
Comment From: rwinch
Thank you for the report.
Spring Security intentionally removed OSGi support as part of SEC-2506 This is because Spring's OSGi repository is now frozen and Spring Framework (which Spring Security depends on) no longer supports OSGi.
The SpringSource EBR was made read-only in September, so Spring Framework 3.2.x (and any other) releases after that date will not be published there. Please refer to the FAQ and the announcement over in the Eclipse Bundle Recipes project which should be the successor to the SpringSource EBR.
SpringSource made available the necessary information for the community to take over creation of OSGi bundles for Spring Framework, so you may like to collaborate with others in the creation of Spring Framework 3.2.5 bundles which could then be published to Maven Central.