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 S
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 Raibl
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,
An
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
--
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 ne
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,
An
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 m
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
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
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? As the Contacts Sample is
working, it points to configuration. I checked the URL above a
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
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
sessi
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
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 use
Ray Krueger 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 have now fi
On Mar 17, 2005, at 4:51 PM, Ben Alex wrote:
Ray Krueger 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 a
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 HttpSessionContex
On Mar 18, 2005, at 7:40 PM, Ben Alex wrote:
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.
Perha
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
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 HttpSessionContextIn
20 matches
Mail list logo
