SEC-1244: <ldap-server> doesn't work unless "security" is the default namespace. #1484

Closed
spring-issuemaster opened this Issue Sep 13, 2009 · 7 comments

1 participant

@spring-issuemaster

Greg Turnquist (Migrated from SEC-1244) said:

I coded a pure LDAP authentication/authorization solution (no DAO entities) with the following XML configuration.

xmlns:security="http://www.springframework.org/schema/security"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-2.0.4.xsd">

security:http





/security:http

/beans:beans

This generated the error message:

2009-09-10 12:32:42,328 [main] ERROR [localhost].[/] - Exception sending context initialized event to listener instance of class org.codehaus.groovy.grails.web.context.GrailsContextLoaderListener org.springframework.beans.factory.access.BootstrapException: Error executing bootstraps; nested exception is org.springframework.security.config.SecurityConfigurationException: No SpringSecurityContextSource instances found. Have you added an element to your application context?

I altered resources.xml to make security namespace the default...

xmlns:beans="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-2.0.4.xsd">








/beans:beans

Everything works now!

@spring-issuemaster

Luke Taylor said:

The LDAP sample application doesn't use security as the default namespace, so this can't be a general case.

I would have thought that the XML would be identical once it has been parsed, regardless of whichever namespace is used as the default.

@spring-issuemaster

Greg Turnquist said:

What are the odds this is actually a Grails issue? I thought that only tweaking the resources.xml file pointed the finger at Spring Security. Its tricky to figure out, because most people seem to use DAO-based solutions, so I thought perhaps I had stumbled into a less than common corner case of Spring Security.

I don't use any DAO, and have no entities representing Users or Roles in the database. Instead, all Users and Roles are stored in LDAP, and I just want them transported appropriately into SecurityContextHolder. Hmm....

@spring-issuemaster

Luke Taylor said:

I haven't used Grails so I don't know how it could cause something like this. Can you always reproduce the problem?

@spring-issuemaster

Greg Turnquist said:

I have a java app at work that uses the same authentication mechanism. Currently I'm using Spring JavaConfig. Let me see if I can comment out the Java auth parts, and plugin some XML, to test this out.

@spring-issuemaster

Greg Turnquist said:

Okay, this has to be a Grails issue. I tweaked my pure Java app (no Grails), using security namespace, and it worked fine. I wasn't using Security namespace, but instead Spring JavaConfig, which required me to define all the beans in pure Java. I'll go open a JIRA issue on Grails to report this problem.

@spring-issuemaster

Luke Taylor said:

Ok. Closing as won't fix for the time being.

@spring-issuemaster spring-issuemaster added this to the 3.0.0 RC1 milestone Feb 5, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment