Why doesn't grails' acegi plugin work in weblogic?

Question

I have a grails(v1.2.1) app using the acegi plugin(v0.5.2) to authenticate users against an Active Directory domain.

Everything works perfectly as long as I run the app using "grails run-app"; The correct controller/actions are protected, users can successfully log in, they don't have to log in on each page request, etc.

When I run the app as a war inside of Weblogic 10.3, the whole thing breaks down. The correct controller/actions require authentication, but after a successful login, the user is ALWAYS sent to defaultTargetUrl instead of their originally requested URL. After a successful login, if I try to go back to the same protected page that just caused me to log in, it asks to log in again (which is unhelpful because successful login still sends me to defaultTargetUrl). If if I intentionally enter a bad user/pass on a login page, I'm sent back to the login page, as designed, but the validation messages don't appear.

I've added some logging/done some debugging and determined the following:

• The filter chain has instances of the same classes in the same order whether I run from weblogic or standalone: [org.springframework.security.context.HttpSessionContextIntegrationFilter, org.codehaus.groovy.grails.plugins.springsecurity.FixRedirectLogoutFilter, org.codehaus.groovy.grails.plugins.springsecurity.GrailsAuthenticationProcessingFilter, org.springframework.security.wrapper.SecurityContextHolderAwareRequestFilter, org.springframework.security.ui.rememberme.RememberMeProcessingFilter, org.springframework.security.providers.anonymous.AnonymousProcessingFilter, org.springframework.security.ui.ExceptionTranslationFilter]
• When running standalone (grails run-app) my session has org.codehaus.groovy.grails.FLASH_SCOPE and SPRING_SECURITY_SAVED_REQUEST_KEY attributes saved before the security filter attempts to authenticate the user's credentials. In weblogic the session has NO attributes at that point. I have checked and the attribute value classes are all serializable.
• When running in weblogic, at the beginning of the HttpSessionContextIntegrationFilter request.getSession(false) returns null.

Answer 1

SOLVED.

If you ever see behavior like this, check your cookies. My browser had several "JSESSIONID" cookies for localhost. The path for 2 of these JSESSIONIDs matched the path of my app (one for the path "/" and one for the path of my app.

The browser was sending both matching JSESSIONIDs in the HTTP headers. The first JSESSIONID in the header was not the one just set, so my app didn't think the request was part of the same session. Hence, the loss of all session attributes. Particularly the login-related ones.