This week's book giveaways are in the Java EE and JavaScript forums.
We're giving away four copies each of The Java EE 7 Tutorial Volume 1 or Volume 2(winners choice) and jQuery UI in Action and have the authors on-line!
See this thread and this one for details.
The moose likes JSF and the fly likes HttpSession and/or Container-managed authentication/authorization Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Java » JSF
Bookmark "HttpSession and/or Container-managed authentication/authorization" Watch "HttpSession and/or Container-managed authentication/authorization" New topic
Author

HttpSession and/or Container-managed authentication/authorization

immer alvarado
Greenhorn

Joined: Nov 18, 2010
Posts: 9
I am building a web application using JSF, EJB, Eclipse, and Tomcat. I am concerned with saving key user session information, such as name and user_id. When i use container-managed authentication, the users are required to enter their credentials in order to view the desired webpage. However, i want to save their information so that i could access other user related information from the database later. But, with container-managed authentication i dont get to actually program the login method, so my question is how or when do i put the user information into the httpsession? I dont want to ask them to re-enter their log in. How should i do it. Or do i have to user another for of authentication and authorization in order to do this, if so which form? Thank you .
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16019
    
  20

The user ID is available directly (getRemoteUser) and indirectly (getUserPrincipal) from the HttpServletRequest object. When these objects are null, that's an indication that the user is not logged in.

The password is not retained. It would be a major security risk to have passwords floating around in memory. Normally, server applications access resources as the application rather than as a specific user in the application. For example, database connections belong to the appserver, rather than a specific app user, which is much more efficient.

The downside of that is that the appserver has to have the greatest-common-denominator of all the privileges of all of its users. However, the appserver itself normally runs locked down and only accessing the resources via app-specific code, that's not generally an issue. In fact, we were doing that on mainframes back in the 1980s.


Customer surveys are for companies who didn't pay proper attention to begin with.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: HttpSession and/or Container-managed authentication/authorization