• 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

A question about login in JSF application

 
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Hi all!

I am following this link (http://benjmaz.blogspot.com) for handling session in my application.

I am unable to understand that what attributes and methods would be there in the MemberManager class, object of which we have created in LoginBean.java class, please give me some clue about this.

Thanks in advance.
 
Saloon Keeper
Posts: 22266
151
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There's a technical term for applications that do their own login and security code.

It's "insecure".

I've worked with J2EE since before it was called J2EE and JSF since about 2005. In all those years I've seen uncounted webapps, and every stupid stinking one of the ones that had their own login code had major security holes in them. Including the military and financial ones.

I wish people would stop using "login" as an example of how to program for the web. The web is insecure enough as it is. And Java has a perfectly good pre-debugged security system designed by security experts and proven by years of use that requires no login code whatsoever and will block unauthorized users from even getting to the secured parts of the webapp, much less attacking them.



OK. Sorry. Blood pressure returning to normal now, I hope.

Speaking from the point of view of JSF forms in general and ignoring the "login" aspects (whoops, breathe deeply, now!), a JSF backing bean can be counted on to have 2 major components.

1. Properties. Usually these are instance variables in private scope accessed by "get" and "set" methods. In other words, a POJO (Plain Old Java Object) or more precisely, a JavaBean.

2. Action methods. In the original JSF, a public method taking no arguments and returning a String. JSF2 adds some other alternatives, but basically, the action method is tied to a commandButton or commandLink (please don't use actionListener unless necessary! That's a whole different rant). When the button/link is clicked, the JSF lifecycle kicks in, first validating the form data, then updating the properties (calling the "set" methods), then finally invoking the action method itself. The string the action method returns is the navigation token for JSF1, or optionally a View ID in JSF2.

Sessions in J2EE are not limited to only being logged in. In fact, JSF will automatically construct a session any time a View references a session-scoped object. However, destroying (invalidating) a session will log a user out when using the J2EE standard security system.
 
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
And what's the name of the security system?
 
Tim Holloway
Saloon Keeper
Posts: 22266
151
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Rui Azevedo wrote:And what's the name of the security system?



Container-managed Security. But it's not a named component - just a description of how security is handled. J2EE, like Java, was designed to be secure from the bottom up, so there's not something like a special JAR file or add-on that has to be added to do security. The security is there regardless, just waiting to be switched on using specifications in the web.xml file and security configuration of the webapp container. There are a few API methods as well, but the underlying premise is that security is something that should be wrapped around apps, not crammed into the program logic. The less security code you have to write (and maintain), the less likely that it will be defective or not in effect at a critical point. And, of course, the less time you spend writing security code, the more time you have for the "productive" part of the app.
 
    Bookmark Topic Watch Topic
  • New Topic