Reputation: 63
I'm having trouble using Spring Security successfully in my Grails application. I installed the spring-security-core plugin, then ran the command to perform the initial setup:
s2-quickstart my.package ReUser ReRole
where ReUser and ReRole are my user and role domain classes, respectively. I then continued to follow the setup instructions in Peter Ledbrook's Simplified Spring Security screen, but when I actually tried to run the application and authenticate a user I ran into trouble. The usernames I created in the Bootstrap were never recognized (with a BadCredentialsException) and it was if I had never stored those User, Role, and join class values. But stored they were, with the count of the saved values asserted in the Bootstrap. As well, the relevant classes were correctly identified in Config.groovy as:
grails.plugins.springsecurity.userLookup.userDomainClassName = 're.sec.ReUser'
grails.plugins.springsecurity.userLookup.authorityJoinClassName = 're.sec.ReUserReRole'
grails.plugins.springsecurity.authority.className = 're.sec.ReRole'
These results were leaving me mystified, until I noticed the following sequence in my logs:
web.FilterChainProxy Converted URL to lowercase, from: '/index.gsp'; to: '/index.gsp'
web.FilterChainProxy Candidate is: '/index.gsp'; pattern is /**; matched=true
web.FilterChainProxy /index.gsp at position 1 of 8 in additional filter chain; firing Filter: 'SecurityContextPersistenceFilter'
context.HttpSessionSecurityContextRepository No HttpSession currently exists
context.HttpSessionSecurityContextRepository No SecurityContext was available from the HttpSession: null. A new one will be created.
web.FilterChainProxy /index.gsp at position 2 of 8 in additional filter chain; firing Filter: 'MutableLogoutFilter'
web.FilterChainProxy /index.gsp at position 3 of 8 in additional filter chain; firing Filter: 'RequestHolderAuthenticationFilter'
web.FilterChainProxy /index.gsp at position 4 of 8 in additional filter chain; firing Filter: 'SecurityContextHolderAwareRequestFilter'
web.FilterChainProxy /index.gsp at position 5 of 8 in additional filter chain; firing Filter: 'RememberMeAuthenticationFilter'
web.FilterChainProxy /index.gsp at position 6 of 8 in additional filter chain; firing Filter: 'AnonymousAuthenticationFilter'
authentication.AnonymousAuthenticationFilter Populated SecurityContextHolder with anonymous token: 'org.springframework.security.authentication.AnonymousAuthenticationToken@9055c2bc: Principal: anonymousUser; Credentials: [PROTECTED]; Authenticated: true; Details: org.springframework.security.web.authentication.WebAuthenticationDetails@b364: RemoteIpAddress: 0:0:0:0:0:0:0:1; SessionId: null; Granted Authorities: ROLE_ANONYMOUS'
web.FilterChainProxy /index.gsp at position 7 of 8 in additional filter chain; firing Filter: 'ExceptionTranslationFilter'
web.FilterChainProxy /index.gsp at position 8 of 8 in additional filter chain; firing Filter: 'FilterSecurityInterceptor'
intercept.FilterSecurityInterceptor Public object - authentication not attempted
web.FilterChainProxy /index.gsp reached end of additional filter chain; proceeding with original chain
access.ExceptionTranslationFilter Chain processed normally
context.HttpSessionSecurityContextRepository SecurityContext is empty or anonymous - context will not be stored in HttpSession.
context.SecurityContextPersistenceFilter SecurityContextHolder now cleared, as request processing completed
Do these enties (specifically 'SecurityContext is empty or anonymous - context will not be stored in HttpSession', all which show up during the Bootstraping process), explain why my application won't recognize the user names/passwords I try to store during the Bootstrap? What am I doing wrong?
Upvotes: 0
Views: 1088
Reputation: 75681
Did you see the note about double-encoding the password in the blog post you referenced? As of version 1.2 the user domain class encodes the password. If you do this again when creating the users (e.g. in BootStrap) then they'll be double-encoded.
Upvotes: 1