Hi Ian,
Indeed, the Wicket base class from Wicket-auth-roles does keep the 'is
signed in' state. This is okay; it is the intention that you invalidate
the session upon logout. This should of course happen automatically on a
timeout after you close the browser.
If the browser did not keep the cookie, you should have gotten a new
session in which isSigned() should return false. If this is really the
case, then this sounds like a bug in Wicket core and not in
Wicket-auth-roles.
If your browser /did/ keep the cookie and brought you back to the same
session, you should also have gotten the security context from Acegi.
It this is the case the problem is either (again) a Wicket bug, or a
problem with the session authentication store of Acegi. Please
investigate whether you configured the Acegi filter on all relevant URLs.
Regards,
Erik.
Ian Godman wrote:
Hi
I am trying to get Acegi (Spring Security) working with Wicket.
It almost works except that if I close the browser and reopen the page I get a
null pointer exception because the
SecurityContextHolder.getContext().getAuthentication() is null in the
getRoles() method of the appSession, which is actually what I would expect as
the use should not be logged on because the browser was closed.
It appears to me that Wicket-auth-roles is not noticing that the user is not
authenticated (its remembering the previous authentication) so checks to see if
they have the role required to access the page and because the authentication
does not exist in the security context I get NullPointerException.
Been going around this all morning, completely out of ideas.
Ian
___________________________________________________________
Yahoo! Answers - Got a question? Someone out there knows the answer. Try it
now.
http://uk.answers.yahoo.com/
--
Erik van Oosten
http://2008.rubyenrails.nl/
http://www.day-to-day-stuff.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
