Eddie: Thanks for the reply. Yes, I am using BASIC authentication. You mention FORM-based authorization, and it sounded to me as if you were speaking of another version of container-managed authentication; however, I'm not familiar with it. Can you point me in the right direction, and I'll do the research?
Also in passing, I should mention that one of the reasons I switched to container-managed authentication is that I anticipate my app having to run inside a client's portal, and I anticipate that I'll have to avoid a 2nd login; in other words, their users will login to the portal, and I won't have the option of requiring them to login again to my app. -----Original Message----- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 10:30 AM To: Struts Users Mailing List Subject: Re: Logout in a container-managed security environment (see below) Charles McClain wrote: >All: > >When I first converted my app to use the Struts framework, I cribbed >the login mechanism from the Struts example application. This worked >nicely; besides the initial login function, the combination of the >global "loginpage" forward and the app:checklogin tag (as well as the >login check in the Actions) forced the user to the application login >page if he tried to come into the application "in the middle" via a >bookmark or something. Finally, there was a "logout" action with a >session.invalidate() method call that also threw the user back to the >application login page. > >After some reading which recommended container-managed security -- and >also after I decided I would like to use the Jakarta Taglibs >req:isUserInRole tag to vary menus, etc., by user role -- I switched >over to using a Tomcat security constraint. > >Everything still works fine -- when the user links to the app "welcome" >page, Tomcat throws up a login dialog, and if he tries to come into the >app "in the middle" via a bookmark, he also is required to login via >Tomcat. However, since the application no longer has its own login >page, I seem to have lost the ability to log him out and require a >re-login. The logout action still performs the session.invalidate() >method and takes him to the "you have logged out" page, but I don't >know how to force the Tomcat login dialog; in other words, if I put a >link back to the "welcome" page on the "you have logged out" page, it >just goes back to the "welcome" page without requiring him to login >again. > It *sounds* like you're doing it right. One important note is that the session dies with the request in which it is invalidated - meaning that, if you expect to see the session disappear right after you invalidate it, you're going to be disappointed. Once the current request is "dead" so should be the session. Having a "link to the welcome page" indicates to me that the user is making another request for that page. That being the case, I think the session should be dead. Here's how I kill one: HttpSession session = request.getSession(false); if (session != null) session.invalidate(); >If he closes the browser, of course, he has to login again, but I'm >looking for the same kind of forced re-login behavior that the original >application-controlled login mechanism gave me. > I'm not sure what is going on here. What method of authentication are you using? I'm not 100% certain, but this could actually be a problem with BASIC auth (seems I recall hearing something like that, but I could be mistaken). Why? The browser caches your credentials and gives them to Tomcat when it asks for them again (with BASIC, I believe). Personally, I use FORM-based auth. >Any ideas? > > >Charles McClain >Phone: 603.659.2046 >email: [EMAIL PROTECTED] > -- Eddie Bush -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
