A question about login in JSF application

[Adnan Gondal]

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.

[Tim Holloway]

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.

[Rui Azevedo]

And what's the name of the security system?

[Tim Holloway]

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.