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.Matt, did you get it working in the end?
http://tinyurl.com/6y4jd
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
