The other weird thing is that request parameters don't propagate either across the protected/unprotected boundary. If the user is viewing a form on a protected page and submits with an action that subsequently does a forward (via a forward mapping in a Struts action) to an unprotected page, the parameters don't show up in the request object.
I'm thinking this could be a bug in the JBoss security implementation, a bug in Struts, or maybe a bug in Tomcat. Either that, or it might be a design decision -- I remember reading a few days ago that session data does not remain valid when switching between HTTP and HTTPS. Is this the case with protected/unprotected pages as well for both user credentials and parameters? -----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]>
