On Tue, 15 Mar 2005 06:00:42 -0700, Matt Raible <[EMAIL PROTECTED]> wrote: > I was able to reproduce this problem in the Contacts sample > application. If logout.jsp *doesn't* do a redirect, the problem occurs > and the user stays logged in. If it *does* a redirect, everything works > and the user is logged out and prompted to login again. > > I'm guessing the desired behavior is that session.invalidate() logs out > the user, regardless of redirect or not. I tried adding > <dispatcher>REQUEST</dispatcher> and <dispatcher>FORWARD</dispatcher> to > the Acegi Filter Chain Proxy, but no luck. > > Still digging... > > Matt > > Matt Raible wrote: > > > FYI... > > > > I just upgraded the sample app for Spring Live to 0.8.0 and I'm > > experiencing this same issue. Invalidating the session does not > > logout a user. I'll dig into Acegi Security code later tonight and > > see if the ContextHolder is still holding an Authentication object > > outside of the session. That seems to be what is happening. > > > > Does my httpSessionContextIntegrationFilter need to explicitly say > > "use the session"? I tried setting allowSessionCreation to "false" > > and "true" and neither seemed to have any effect. Maybe my > > logout.jsp needs to have "outside" of a secure URL? I also deleted > > all my filter-mappings except for the Acegi Security one. > > > > Matt > > > > > > On Mar 14, 2005, at 6:59 AM, Matt Raible wrote: > > > >> > >> On Mar 12, 2005, at 6:46 PM, Ben Alex wrote: > >> > >>> Matt Raible wrote: > >>> > >>>> Here's a link to AppFuse's applicationContext-security.xml file - > >>>> the filters are specified in the first bean at the top. > >>>> > >>>> http://tinyurl.com/6y4jd > >>>> > >>> Matt, did you get it working in the end? > >> > >> > >> Nope. > >> > >>> As the Contacts Sample is working, it points to configuration. I > >>> checked the URL above and couldn't see any issues with the filter > >>> configuration. Could another filter (SiteMesh?) be re-creating the > >>> HttpSession and conflicting with the session invalidation? Consider > >>> this: > >>> > >>> 1. HttpSessionContextIntegrationFilter obtains Context from > >>> HttpSession and puts it in ContextHolder > >>> 2. Session invalidated during view > >>> 3. Some object/filter uses HttpServletRequest.getSession() or > >>> .getSession(true), which re-creates a new session > >>> 4. HttpSessionContextIntegrationFilter obtains a session, and > >>> copies ContextHolder Context into it > >>> 5. On next request, HttpSessionContextIntegrationFilter finds > >>> Context in the HttpSession > >>> > >>> The above could explain the behaviour you're observing. Especially > >>> as you can ContextHolder.setContext(null) during step 2 and it > >>> achieves logout. I'd try commenting out all the other non-Acegi > >>> Security filters and progressively re-adding them. > >> > >> > >> I commented out *all* the filters I have, except for the > >> FilterChainProxy: > >> > >> <filter> > >> <filter-name>securityFilter</filter-name> > >> > >> <filter-class>net.sf.acegisecurity.util.FilterToBeanProxy</filter- > >> class> > >> <init-param> > >> <param-name>targetClass</param-name> > >> > >> <param-value>net.sf.acegisecurity.util.FilterChainProxy</param-value> > >> </init-param> > >> </filter> > >> > >> <filter-mapping> > >> <filter-name>securityFilter</filter-name> > >> <url-pattern>/*</url-pattern> > >> </filter-mapping> > >> > >> Then I changed logout.jsp to remove any references to tag libraries > >> or JSP declarations: > >> > >> <%session.invalidate();%> > >> <a href="mainMenu.html">mainMenu.html</a> > >> > >> The strange thing is I can click on the mainMenu.html link and I'll > >> see the main menu w/o being logged in. However, if I try to edit my > >> profile (which uses request.getRemoteUser()), I get a NPE. Here's > >> my "filterChainProxy" definition. > >> > >> <bean id="filterChainProxy" > >> class="net.sf.acegisecurity.util.FilterChainProxy"> > >> <property name="filterInvocationDefinitionSource"> > >> <value> > >> CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON > >> PATTERN_TYPE_APACHE_ANT > >> / > >> **=httpSessionContextIntegrationFilter,authenticationProcessingFilter,r > >> emoteUserFilter,anonymousProcessingFilter,securityEnforcementFilter > >> </value> > >> </property> > >> </bean> > >> > >> Matt > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Home: http://acegisecurity.sourceforge.net > Acegisecurity-developer mailing list > Acegisecurity-developer@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer >
Hey Matt, I was just getting ready for work and some things dawned on me. If you are logging out the user, you should either redirect them or bounce them out by responding with a 401 and forcing them to re-authenticate. If you intend to let the SecurityEncorcementFilter do the 401 response, you should have your LoginFilter first in the chain so that the session is invalid for everyone behind it. A problem there is that if all the proper headers are in place to authorize the user, the whole authentication process will just start from scratch; new session, read the header, authorize it, and the user is logged right back in again. Another idea is to put in a 401 after your request.getSession().invalidate(); line, response.sendErrorCode(401, "User has been logged out"); That may end up in your user getting a big blue Tomcat error page though, those are always nice. I think putting in a response.redirect() back to the login form is your safest bet in your "logout" check, invalidate the session and send the user back to the front door. Nothing above is based on me looking at code right now, like I said; I was just thinking about the problem for some reason and those thoughts jumped in my head. Gook luck -Ray P.S. I subscribed to Spring Live yesterday, hopefully I'll actually get a chance to read it soon :P ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
