Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

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

Comments

Projects
None yet
1 participant

Greg Turnquist (Migrated from SEC-1244) said:

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

security:http
<security:intercept-url pattern="/**" access="ROLE_USER" />
<security:form-login />
<security:anonymous />
<security:http-basic />
<security:logout />
/security:http
<security:ldap-server url=""/>
<security:ldap-authentication-provider user-dn-pattern="uid={0},ou=people"/>

/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...

<beans:beans xmlns="http://www.springframework.org/schema/security"
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!

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.

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....

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?

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.

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.

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