It's within the same webapp (the context path is the same). At first I thought it was a cache issue, but I hit reload on both protected and unprotected pages and it shows what I originally pulled up on each particular page. That is, users remain logged in, but when they visit unprotected sites, request.getRemoteUser() and other authentication methods behave as if the user is unauthenticated until the user revisits a protected page, at which point the authentication methods return valid information. Tomcat does not ask the user to log back in, so it remembers. I can visit other web sites and return to my application, and Tomcat still remembers authentication information, and Tomcat still returns null for request.getRemoteUser() on the unprotected pages (most served by Struts and Tiles).
Do you think using Struts or Tiles could influence the scope of the security attributes so that they only showed up in the protected areas? I'm also running an integrated JBoss. It's almost as if the cookie used for security only has scope within a subtree of the application -- I'm just speculating wildly here. The problem is not that severe since I can create a session attribute that stores the authentication information, but it is mildly annoying. -----Original Message----- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 02, 2002 6:02 PM To: Tomcat Users List Subject: Re: Question about container-managed security On Tue, 2 Apr 2002, Wellie W. Chao wrote: > Date: Tue, 2 Apr 2002 16:59:38 -0500 > From: Wellie W. Chao <[EMAIL PROTECTED]> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > To: Tomcat Users List <[EMAIL PROTECTED]> > Subject: Question about container-managed security > > I'm using Tomcat 4.0.2 and noticed that the security attributes returned by > request.getRemoteUser(), request.isUserInRole("x"), and > request.getUserPrincipal() seem to only be present when the user is in a > protected directory, even if he has already logged in. That is to say, the > user can log in and go to a protected URL, and request.getRemoteUser() works > fine. If he then goes to a "common" area that is not protected by a > security-constraint block in web.xml, request.getRemoteUser() returns null. > If he then goes back to a different protected page, request.getRemoteUser() > returns the username again, so clearly Tomcat is storing the information. > > Does anyone know how to get access to the authentication information on a > non-protected page after the user has logged in? I could set a session > attribute right after login, but I figured that Tomcat already has the > information, so it would be nice to not have to resort to a hack. > As long as your "common area" is within the same web application, you should continue to see the security attributes, even when accessing an unprotected resource. However, if your common area is in some other webapp, then the attributes won't be set, because they are specific to a particular webapp only. Craig -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]> -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>
