This week's book giveaway is in the OCAJP forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide 1Z0-808 and have Jeanne Boyarsky & Scott Selikoff on-line! See this thread for details.
No, you don't have a "login bean", since the container doesn't formally notify the application when a user has logged in. The only way to detect a login is to monitor page requests and check the HttpRequest object. When the userName/userPrincipal values transition from null to not-null, a login has just occurred. This is usually best done in a Filter.
It sounds like you want to force the user to a "home page" after they login. I don't recommend that, since it's a royal pain to those of us who like to bookmark direct links into secured functions, but you can use the above-mentioned filter code to hijack the incoming URL and redirect the request.
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: Jul 10, 2011
Thank you Mr. Holloway! Your answers are always spot on!
The main problem seems to be that I've chosen the wrong authentication system in the first place.
What I need is a role based user login and some kind of session management.
Correct me if I'm wrong but Tomcat REALM authentication seems more of a "protect some folders" system.
I wasn't even able to direct my visitors to a login and proceed. Tomcat wants me to request a protected URL and login afterwards.
Can somebody point me to the right direction for my needs?
It isn't really "Tomcat Realm" authentication, it's J2EE standard Container-managed authentication and authorization, to give it it's full name. Tomcat is just one of many servers that implement the standard, although the actual Realms themselves are plug-ins that adhere to the common specs.
Although when I said "you're wrong" what I really meant wasn't that - that's just nitpicking. What I meant was that the system isn't a "folder protection system". In fact, it doesn't protect folders AT ALL! It works on URLs, and a URL level only corresponds to a filesystem folder when the server and application want it to. JSF developers get their noses rubbed in that pretty quickly, since the JSF URLs don't track the underlying resource paths as closely as non-JSF framework URLs generally do.
One of the greatest strengths of the container-managed system is that it cannot be bypassed by jumping around a login screen. If you attempt to access a protected URL, the container itself hijacks the request, presents the login screen, and processes it. If AND ONLY IF the login succeeded, the original request is rescheduled and passed to the app. So the application code is not vulnerable to non-authenticated users, since their attempts will never get anywhere near the application itself.
There are several reasons why Tomcat doesn't support setting up a "login home". One of which is because twerps like me often like to bookmark their way directly to commonly-used secured pages and would be really annoyed if we were instead forced to a "home page". Another is that in a single signon system, the user could have signed into a different application on a different server 3 days earlier, but because it's SSO, your app would not force a new, separate login - because it wouldn't be SINGLE signon then!
In short, J2EE is designed for on-demand security. If you want the user to have a login screen pushed in their face first thing, make the welcome page be secured. That will force the login screen to be presented followed by the home screen, assuming no one jumps to a direct URL. Or use Tomcat 7, where the latest JEE standard has added a "login" API call and put the login on a screen that invokes it.
Which brings me to a Best Practices recommendation. I like the JEE login. My apps may be friendly, but my security is not. I'm just fine with a stark plain login form with maybe a Doberman on it. I most definitely don't recommend putting menus and other bling on the login page no matter how you do it. At best, they won't work, since secured access is required, at worst they could possibly be used to bypass security. When using container-managed security it shouldn't be possible, but I prefer NOT to discover loopholes the hard way, myself.