• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
  • Mikalai Zaikin

HttpSession and/or Container-managed authentication/authorization

Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 .
Saloon Keeper
Posts: 27863
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
    Bookmark Topic Watch Topic
  • New Topic