Re: [Acegisecurity-developer] session.invalidate() vs. ContextHolder.setContext(null)
I was able to confirm that the contacts-filter sample works fine. I'm fine with a 0.8.1 since I have workarounds (redirect and ContextHolder.setContext(null)) for both my apps. Matt On Mar 20, 2005, at 3:38 PM, Ben Alex wrote: Matt Raible wrote: Unfortunately, I looked at HttpSessionContextIntegrationFilter.java and found that I did use version 1.4 in my tests. Matt, I'm pretty sure it works fine now. I'm using Tomcat 5.5.7 on Win32 with JDK 1.5.0_01. I've edited the standard logout.jsp used in the Contacts Sample to the following: %@ page import=javax.servlet.http.Cookie % %@ page import=net.sf.acegisecurity.ui.rememberme.TokenBasedRememberMeServices % % session.invalidate(); Cookie terminate = new Cookie(TokenBasedRememberMeServices.ACEGI_SECURITY_HASHED_REMEMBER_ME_C OOKIE_KEY, null); terminate.setMaxAge(0); response.addCookie(terminate); // response.sendRedirect(index.jsp); % Then: cd core maven clean maven jar:install cd ../samples/contacts maven clean maven multiwar:multiwar cp target\*filter*.war $TOMCAT_HOME/webapps Then in my browser: Visit http://localhost:8080/acegi-security-sample-contacts-filter/ Click manage Login as scott Click logoff - you then get a blank page, as there is no redirect Re-enter the home page URL, http://localhost:8080/acegi-security-sample-contacts-filter/ Click manage You are prompted to login I'd really like to release 0.8.1, but I'm holding-off on the basis of this issue not being confirmed as corrected. Would people please let me know if they can continue to reproduce this issue, or if they agree it's fixed. Thanks Ben --- 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=6595alloc_id=14396op=click ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer --- 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=6595alloc_id=14396op=click ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] session.invalidate() vs. ContextHolder.setContext(null)
Matt Raible wrote: I updated from CVS and tried the new JAR on AppFuse and the security chapter's sample application. The behavior continues to happen. I'll try it on the Contacts sample app in few days. Maybe anonymous CVS is not in synch. Perhaps... The latest version of HttpSessionContextIntegrationFilter is 1.4. Please let me know how it goes. Cheers Ben --- 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=6595alloc_id=14396op=click ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] session.invalidate() vs. ContextHolder.setContext(null)
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 dispatcherREQUEST/dispatcher and dispatcherFORWARD/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-namesecurityFilter/filter-name filter-classnet.sf.acegisecurity.util.FilterToBeanProxy/filter- class init-param param-nametargetClass/param-name param-valuenet.sf.acegisecurity.util.FilterChainProxy/param-value /init-param /filter filter-mapping filter-namesecurityFilter/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.htmlmainMenu.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=6595alloc_id=14396op=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
Re: [Acegisecurity-developer] session.invalidate() vs. ContextHolder.setContext(null)
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 dispatcherREQUEST/dispatcher and dispatcherFORWARD/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-namesecurityFilter/filter-name filter-classnet.sf.acegisecurity.util.FilterToBeanProxy/filter- class init-param param-nametargetClass/param-name param-valuenet.sf.acegisecurity.util.FilterChainProxy/param-value /init-param /filter filter-mapping filter-namesecurityFilter/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.htmlmainMenu.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=6595alloc_id=14396op=click ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] session.invalidate() vs. ContextHolder.setContext(null)
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-namesecurityFilter/filter-name filter-classnet.sf.acegisecurity.util.FilterToBeanProxy/filter- class init-param param-nametargetClass/param-name param-valuenet.sf.acegisecurity.util.FilterChainProxy/param-value /init-param /filter filter-mapping filter-namesecurityFilter/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.htmlmainMenu.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,re moteUserFilter,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=6595alloc_id=14396op=click ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] session.invalidate() vs. ContextHolder.setContext(null)
Ben Alex wrote: Andreas Brenk wrote: You could use a HttpSessionListener to keep the coupling to Acegi Security separate from your controller. See http://forum.springframework.org/viewtopic.php?t=1106 for an earlier discussion. Perhaps this should be mentioned in the upgrade readme. Regards, Andreas Matt Raible wrote: With Acegi Security 0.7.0, I was able to use session.invalidate() to logout a user - much like I do when using container-managed authentication. However, with 0.8.0, I've found that I have to use ContextHolder.setContext(null). Is there anyway to change back to the old behavior so I don't have any Acegi Security-specific code in my app - so users can easily switch back to CMA (non-Acegi Security based) if they want? Hi Matt Which container are you using? What does DEBUG-level logging show for HttpSessionContextIntegrationFilter? It seems to work OK for me in Tomcat 5.5 with the Contacts Sample application's logout.jsp. For some reason, calling session.invalidate() (in a filter or in a JSP) doesn't seem to help get rid of any Acegi authentication information. Adding ContextHolder.setContext(null) in a filter that's mapped to logout.jsp seems to be the only thing that works for me. Here's my LoginFilter that gets hit: http://static.raibledesigns.com/downloads/appfuse/api/org/appfuse/webapp/filter/LoginFilter.java.html And my console is printing out: [appfuse] DEBUG [http-8080-Processor3] LoginFilter.doFilter(72) | logging out 'mraible' Matt 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=6595alloc_id=14396op=click ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] session.invalidate() vs. ContextHolder.setContext(null)
On Mar 11, 2005, at 2:17 AM, Ben Alex wrote: Matt Raible wrote: For some reason, calling session.invalidate() (in a filter or in a JSP) doesn't seem to help get rid of any Acegi authentication information. Adding ContextHolder.setContext(null) in a filter that's mapped to logout.jsp seems to be the only thing that works for me. Here's my LoginFilter that gets hit: http://static.raibledesigns.com/downloads/appfuse/api/org/appfuse/ webapp/filter/LoginFilter.java.html And my console is printing out: [appfuse] DEBUG [http-8080-Processor3] LoginFilter.doFilter(72) | logging out 'mraible' Sorry Matt, what container was it again? Does the 0.8.0 official Contacts Sample app work properly in the same container (ie its logout page works)? I'm wondering if the filter ordering is correct, as it changed in version 0.8.0. It would be good to get to the bottom of this Tomcat 5.5.7 on Windows XP and JDK 1.4.2. Yes, the Contacts sample app from CVS works when I logout. I've used both the FilterChainProxy and the specify-each-filter in web.xml methods and it happens with both. It could be a filter ordering problem, but I'm pretty sure the order I have is needed to make other things work. Matt Cheers Ben --- 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=6595alloc_id=14396op=click ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer --- 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=6595alloc_id=14396op=click ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] session.invalidate() vs. ContextHolder.setContext(null)
On Mar 11, 2005, at 6:28 AM, Matt Raible wrote: On Mar 11, 2005, at 2:17 AM, Ben Alex wrote: Matt Raible wrote: For some reason, calling session.invalidate() (in a filter or in a JSP) doesn't seem to help get rid of any Acegi authentication information. Adding ContextHolder.setContext(null) in a filter that's mapped to logout.jsp seems to be the only thing that works for me. Here's my LoginFilter that gets hit: http://static.raibledesigns.com/downloads/appfuse/api/org/appfuse/ webapp/filter/LoginFilter.java.html And my console is printing out: [appfuse] DEBUG [http-8080-Processor3] LoginFilter.doFilter(72) | logging out 'mraible' Sorry Matt, what container was it again? Does the 0.8.0 official Contacts Sample app work properly in the same container (ie its logout page works)? I'm wondering if the filter ordering is correct, as it changed in version 0.8.0. It would be good to get to the bottom of this Tomcat 5.5.7 on Windows XP and JDK 1.4.2. Yes, the Contacts sample app from CVS works when I logout. I've used both the FilterChainProxy and the specify-each-filter in web.xml methods and it happens with both. It could be a filter ordering problem, but I'm pretty sure the order I have is needed to make other things work. 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 --- 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=6595alloc_id=14396op=click ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] session.invalidate() vs. ContextHolder.setContext(null)
You could use a HttpSessionListener to keep the coupling to Acegi Security separate from your controller. See http://forum.springframework.org/viewtopic.php?t=1106 for an earlier discussion. Perhaps this should be mentioned in the upgrade readme. Regards, Andreas Matt Raible wrote: With Acegi Security 0.7.0, I was able to use session.invalidate() to logout a user - much like I do when using container-managed authentication. However, with 0.8.0, I've found that I have to use ContextHolder.setContext(null). Is there anyway to change back to the old behavior so I don't have any Acegi Security-specific code in my app - so users can easily switch back to CMA (non-Acegi Security based) if they want? --- 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=6595alloc_id=14396op=click ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] session.invalidate() vs. ContextHolder.setContext(null)
Matt Raible wrote: Ben Alex wrote: It seems to work OK for me in Tomcat 5.5 with the Contacts Sample application's logout.jsp. I tried building/deploying the contacts WAR with maven (according to the Building with Maven instructions) - there is no web.xml included in the WAR file. Matt You need to use multiwar:multiwar from samples/contacts to build the Contacts sample. Or from docs using multiproject:artifact. I just checked the 0.8.0 official release ZIP (build with multiproject:artifact from docs) and it includes acegi-security-sample-contacts-filter.war which does include web.xml. Ben --- 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=6595alloc_id=14396op=click ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
