-
1. Re: a different null Principal problem
starksm64 Feb 20, 2002 12:46 PM (in response to dward2)You do not say if this behavior is specific to the integrated tomcat4. Does a standalone tomcat using the simple xml file based realm show the same behavior?
-
2. Re: a different null Principal problem
dward2 Feb 20, 2002 2:02 PM (in response to dward2)Thanks for responding, Scott. Hey, you know what? It works as intended (Principal everywhere after login) in vanilla Tomcat-4.0.2. However, when coming bundled with JBoss-2.4.4, it doesn't...
Here's what I did - I have two standalone copies of Tomcat 3.2.3 and Tomcat 4.0.2.
For 3.2.3:
----------
1) cd $TOMCAT3_HOME/webapps/examples/jsp/security/.
2) cp ./protected/index.jsp ./test.jsp
3) start tomcat
4) surf to http://localhost:8080/examples/jsp/security/protected/
5) after logging in, surf to http://localhost:8080/examples/jsp/security/test.jsp - you will still have a non-null Principal.
6) stop tomcat
That works the same for me with my custom app with bundled JBoss-2.4.4_Tocmat-3.2.3.
For 4.0.2
---------
1) cd $TOMCAT4_HOME/webapps/examples/jsp/security/.
2) cp ./protected/index.jsp ./test.jsp
3) start tomcat
4) surf to http://localhost:8080/examples/jsp/security/protected/
5) after logging in, surf to http://localhost:8080/examples/jsp/security/test.jsp - you will still have a non-null Principal.
6) stop tomcat
That DOES NOT work the same for me with my custom app with bundled JBoss-2.4.4_Tocmat-4.0.1. I also tried replacing the catalina subdir with 4.0.2, but got the same behavior: I lose my request Principal when surfing in non-protected paths, but get it (the same one) back when surfing back to the protected area.
Thanks again for your help,
David -
3. Re: a different null Principal problem
starksm64 Feb 21, 2002 3:02 PM (in response to dward2)The issue here is that when tomcat is embedded into JBoss caching of principal information at the tomcat level is disabled. This was necessary to ensure that the JBossSecurityMgrRealm is called on every request that needs authentication to avoid leaking security information associated with the request thread. Its not clear from the servlet spec where getUserPrincipal must return a non-null value. I have submitted question to the servlet list on this topic.
-
4. Re: a different null Principal problem
starksm64 Feb 22, 2002 12:54 AM (in response to dward2)The reply I got on the servlet interest list was that when getUserPrincipal should or should not return null is not currently defined. The only guarenteed context in which getUserPrincipal will not be null is under a secured path with tomcat embedded in JBoss.
-
5. Re: a different null Principal problem
dward2 Feb 22, 2002 10:11 AM (in response to dward2)Thanks for looking into this, but then how am I supposed to get the username on pages in non-protected paths? I guess I could shove it into the HTTPSession after a successful log in but that sounds real hacky.
-
6. Re: a different null Principal problem
starksm64 Feb 22, 2002 9:07 PM (in response to dward2)Your going to have to do it in an application specific way. Using a session or a cookie would be one way.
-
7. Re: a different null Principal problem
dward2 Feb 26, 2002 12:29 PM (in response to dward2)Got it to work by using HttpSession (yuck). Thanks for your help, Scott. Though I've worked around it, my opinion is that (in light of spec fuzziness), it should work in Tomcat4 just like it did in Tomcat3. Might as well err toward the status quo, so to speak. Thanks again.
-
8. Re: a different null Principal problem
lychan Feb 28, 2002 8:50 PM (in response to dward2)Can you elaborate how you did it with httpsession.
My understanding of the web container managed security is that the login page will come up the first you hit a protected resource, and after authentication (using j_security_check), it redirect backs to the page you are trying to access.
So, did you find a way to intercept it to stick attribute in the httpsession after j_security_check but before going to the actual page, or you use a filter, or you have codes in every protected page/resource?
Yes, I agree that it would be nicer if getUserPrincipal() will return the actual principal if the user has actually logged on instead of null for unprotected resources. Makes it much easier to have dynamic menus or output depending on user role.
Rgds
Leonard -
9. Re: a different null Principal problem
dward2 Mar 1, 2002 8:39 AM (in response to dward2)Sure. In our application, no user accesses JSP's directly. There is a single "control" Servlet that gathers request params and delegates to EJBs to do work. Based on the success/failure of that work, the Servlet uses a workflow manager to forward to a particular screen (jsp page).
Now, since every request goes through the same Servlet, after a user logs in using container managed security I grab the request.getRemoteUser() and throw it into the HttpSession. So from then on if a user hits an unprotected resource I can still tell if he/she is logged in by checking the remoteUser (username) I put into the HttpSession. When the user logs out, I invalidate the HttpSession which effectively blows away the stored username.
The only thing this doesn't cover is roles, as there is no way in the servlet api to gather all the roles for a user. Only a way (via the request) to tell if they are in a specified role or not. The way that I got around this is again attributed to the fact that all requests go through the same control servlet. I just make sure if they are going to access a path where I want to check on a role that I make sure they get redirected to a path that is protected by the container.
Hope this helps,
David -
10. Re: a different null Principal problem
hanenkamp May 19, 2002 4:38 PM (in response to dward2)I have a problem with this feature/bug. In fact, the whole servlet 2.3 security specification and integration with J2EE has me rather peeved. It doesn't take into account a lot of obvious things. Anyway, I digress...
My problem is, very similar to dward2. I am designing a general content management system and I need to be able to programmatically authenticate to the J2EE server. The system itself does not directly support EJBs at this time as I wish the system to be relatively free of data/logic bindings and leave such things up to the desires of the plugin writers/deployers of the system. However, I would like to perform authentication through the J2EE ssrver so that restricted EJBs may be used.
However, the system also maintains its own security settings independent of the servlet container and verifies roles programmatically. Upon attempt to access a restricted resource, the client is forwarded to a "return" page that is declaratively restricted in the web.xml file. Then, the user is forwarded to a login screen, logs in and the user now has a role allowing him to access the "return" page which then sends the user back to the first request--which is on an unrestricted page. So, as this discussion indicates, my code only works if unrestricted pages also show the user logged in.
I believe I have a couple possible solutions, under JBoss, for this problem. One is to keep a user under some restricted URL after login until logout. Or two, restrict all pages, but only by a "Guest" role which will be granted by some custom LoginManager. I consider both solutions to be hacks and wandered if anyone had a better idea?
Thanks,
Sterling