Ok so this thing has had me pulling my hair for the past three days and I sincerely hope that someone here can help me out.
I am fairly fresh to Java/JSF or Tomcat for that matter but so far have been managing to win all the battles.
I've got a web app running on Tomcat 7 and Mojarra JSF2. I've decided to implement form based authentication.
That's the deployment security descriptor in my web.xml :
In the Tomcat's server.xml I have the following, enclosed within the Host:
As for the JDBC and driver, I've tested the connection numerous times on my local machine as well as on the actual server where it's to be deployed and it work's all right (I'm using Weld with JPA2), persistence and dependency injection.
I've set up the users and user_roles tables exactly as prescribed in the Tomcat's docs and inserted a user and a role for testing.
Now I've tried to use the form within a JSF and later (as you can see in the above descriptor) with just plain .jsp as I've read in an earlier post here that JSF with container managed form authorization is no go.
The form itself is a plain HTML form (no JSF/JSP) with j_security_check action and j_username and j_password fields.
So what is the actual problem ? Whenever I try to log in (be it with the correct or wrong user and pass) it just takes me right to the loginFailed.jsf .
When I check for any exceptions (Netbeans 7) there either aren't any, as if nothing even happened, or this exception comes up in Apache Tomcat log:
Moreover, the above exception is thrown by Apache on other occasions as well when running the up. As it stands it is now my main suspect and it looks to me as if there was a problem with connection between the browser and the app.
But I may well be wrong.
I know from my experience that often things that in the end turn out to have been the most obvious or easy to solve usually take days to solve .. but right now I'm just going mad with that and really need someone to shed some light on this.
I'll need to get some things clarified, I think, but here's a start.
You can't use JSF for a login/loginfailed form because JSF requires routing through the FacesServlet and the login forms are not dispatched as normal HTTP requests, they're invoked from the container (Tomcat) directly.
If you're attempting to access the login page via a direct URL, that doesn't work. Container-managed authorization activates the authentication method when a user makes a URL request to a protected URL. Any protected URL, which eliminates one of the most common ways people get around Do-It-Yourself security systems. There is no actual legitimate URL for the login form itself, since Tomcat is the one running the login form, not the user.
JSF container-based authentication/authorization is basically the same as non-JSF, except that since JSF doesn't track URLs to resources as closely as most other web systems, you need to force the URL sometimes by using the "redirect" navigation feature. That's because the container security system triggers on the incoming URL (pattern) itself, not on the resource(s) that the URL connects to.
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: Jun 10, 2010
Thanks for clearing that up Tim, it is much appreciated.
I have actually managed (after four days ) to get it working last night. Now it turns out that for another , yet unexplained , reason the authorization with precisely same settings and setup won't run on my local machine but it runs on the remote server. One thing you ought to know though, and the only one that comes to my mind looking for explanation for all this, is that my local machine runs Windows while the remote setup is Linux. Again, I may be entirely wrong. So what happened over the past few days is that I may have most likely come up, numerous times, with the right setup but since I often didn't bother with testing on remote server, seeing that local doesn't work, it's taken me nearly four days to crack it. How can you not love the joys of this job ..
Getting back to the subject. I have now set up two JSP pages (one for login and the other for failed login) just as you said and all seems to run fine. I have two questions.
I managed two set up MD5 digested password and it also runs fine. But I will soon be getting SSL and was wondering whether there is some additional setup needed apart from the transport CONFIDENTIAL descriptor in web.xml.
Also was wondering about the login page. I assume that linking CSS and styling won't do any harm but not sure about adding ohter elements apart from the form itself e.g. I don't think that putting any means of navigation to other restricted areas of the app would be the best idea. Generally just wondering if there are any best and proven security to go by.
The security system is OS-agnostic. But firewalls may be blocking access to the database.
Helpful hint: The J2EE security system is completely plug-replaceable. If you need to test security in situations where you can't use a database, LDAP server, or whatever, just configure your test Tomcat to use a MemoryRealm and edit TOMCAT_HOME/conf/tomcat-users.xml as needed.
I had some problems with images and stuff like that in older Tomcat systems, whether it was because the login system wasn't keeping out of the way or just bad design on my part I never discovered. These days, as long as I don't attempt to access secured resources on the login page I'm OK.
My login pages are pretty stark. I take security seriously and I give them all the warmth and friendliness of a Gestapo checkpoint/TSA airport security so that no one can claim it was "all just in fun". It's bad practice, I think, to permit any sort of jumping off to other points from a login page. Firstly, since the resources may not be accessible, since security hasn't cleared yet, secondly because if there's even the slightest chance someone could bypass security by jumping off the login page, I don't want it to be possible. It would be a security system bug, but still...
Joined: Jun 10, 2010
Ok ... many thanks for additional info ..
Life would be too perfect however if everything went down smoothly .. turns out SSL now is playing up ... now I'm getting something like "too many redirections" when I'm trying to open up with transport CONFIDENTIAL ... I am running Tomcat behind Apache Http and am using ProxyPass/ProxyReserve in Apache's httpd.conf to redirect to the Tomcat's port ... now I don't know how to go around this .. been trying to redirect https on the tomcat's default SLL port 8443 but still getting same message .. I can't get rid of the feeling that I might have made thing a bit overcomplicated, or mis-configured, and would like to know what do you think about this config and whether there are any other things that I may do doing not quite as they should be done...