Craig R. McClanahan wrote: > >On Thu, 25 Jul 2002, Graham Lounder wrote: > >>Date: Thu, 25 Jul 2002 11:19:30 -0300 >>From: Graham Lounder <[EMAIL PROTECTED]> >>Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> >>To: Struts Users Mailing List <[EMAIL PROTECTED]> >>Subject: Remote User and Logoff >> >>In my logoff action, I'm invalidating my session. The problem is, the >>getRemoteUser still returns the username when I forward to my jsp page. >>Once I process another request, the remote user is set to null. >> > >Invalidating a session doesn't change the fact that the existing user was >authenticated for the entire length of the current request. > That was my suspicion.
>In Servlet 2.4, a new logout() method is being discussed that would >formalize logout semantics. > That would be very helpful :-) Are they going to add some way to cause authentication to be invoked manually too? ;-) That would seal CMA as the solution for FORM-based auth where you want to be able to log a user in without them first having to access a restricted resource. Of course, I have ideas for working around this, but nothing I've even tried to implement yet. Still, I would think you could work around that somehow using JavaScript. >>Is there any way in my LogoffAction servlet to set the remote user to null >>before forwarding to the jsp page? >> > >There is not a way to do that. I would suggest having your page look for >some session attribute to check for this scenario, because you will have >invalidated the old session and created a new one, and the attribute won't >be there. > ... as I eluded to. You explained it better though. >>Graham >> > >Craig > Are you aware, Craig, of any movement to add some higher degree of flexibility wrt CMA + FORM-based logins? ... for spec 2.5 maybe? ;-) It astounds me this hasn't been addressed in a specification yet - though, having read other posts you've made on this topic, I do understand it takes time and that there is likely no "perfect" solution. It would seem to me that merely allowing some parameter to be passed to j_security_check (a path, for instance) would pretty much cure things. Of course, I can't pretend to have any idea of what the security implications of allowing such a thing would be. Thanks for your efforts, by the way, Craig :-) Regards, Eddie -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
