I have problems with an application in a Tomcat6. The problems are related to safety (security_constrain). For user authentication I am using a jdbcRealm by auth-method FORM.
In my local machine no problem. Everything works fine. But when the application is the production server and try to access a protected resource, I am always redirected to the error page.
I tried to change the pattern in security_constrain, and the result is the same. I can access everything but what they protect. I've also changed the password and I've removed the "digest = MD5" context.xml file, but with the same result.
The only difference is that I have (in production) Apache + Tomcat. Can this be the reason?
The web.xml security statement is this:
Reaml's statement is this:
It not is the first time that I use JDBCRealm, but is the first that I have this problem. Any idea?
Usually the first thing to look for when something works in test and fails in production and is is getting resources via a network connection is that a firewall may be in the way. I realize that this is unlikely when the database server is on localhost, but it's still possible. While you're at it, confirm that localhost is, in fact mapped properly to 127.0.0.1 (in the hosts file) and that mysql is configured to accept local tcp/ip requests (using netstat to display listeners).
Other than that, things look OK, but I recommend that you remove the userid/password from your JDBC URL, since you're supplying them as Realm attributes and that could be confusing. I use "login.jsp" and "loginFail.jsp" as the 2 page names myself; "login" and "logon" may look enough alike to casual troubleshooters to confuse them, although Tomcat doesn't care.
Customer surveys are for companies who didn't pay proper attention to begin with.
Yes... is me first post, but I read this (great) forum from many years ago
Entire application is working properly, except for the resources under authentication / authorization. I think this rules out communication problems or issues of proxy (as you have seen in the configuration, the database is on the same server).
I really don't know what is happening... This is something simple... but not for this time, apparently. I'm forgetting something, sure.
I think we can forget about it being an Apache problem, then.
I'm not sure what you have on your "logon.jsp" page, but the equivalent one I use (loginFail) normally is just like the login.jsp except that it includes the message "Login failed, please try again" or some similar message. The loginfail page is usable as a login form, but if you try to use a loginfail page containing a login form as a regular error page, that won't work, since the login form handler isn't a standard URL process. To avoid confusion, however, I recommend you make a completely different error page so you won't get any confusion between regular login failure and general web application errors.
As far as not using HTTPS, though, you should ALWAYS use HTTPS on login pages. Otherwise a network traffic sniffer can steal userid/password combinations at will.
Actually what happens is that the server was not finding the library of drivers dd.bb.
In this version of Tomcat you can not put the "jar" in TOMCAT_HOME / common / lib (among other things, because does not exist and if is created, has no effect). To give effect to the driver must be placed in CATALINA_HOME (which has established a value of /etc/default/tomcat6).
Thus, Tomcat can find the drivers and validate the user.
I wrote a post on my blog about this ... although in Spanish...