How to debug DataSourceRealm when attempted login always goes to form-error-page

[marten koomen]

Hi

I'm hoping to get some help on how to debug failing to login using the DataSourceRealm, my context.xml and web.xml are below.

I've tested the database connection, that's working, and I can return usernames and passwords through that connection

I've tried turning the form-error-page off, but tomcat doesn't provide any futher details on why it's failing

I've tried to look in the log file, but the catalina log is telling me WARNING [http-nio-8080-exec-440] org.apache.tomcat.util.digester.SetPropertiesRule.begin Match [Context/Realm] failed to set property [debug] to [99]

I've been poking around all day, but haven't be able to make any progress, and tips would be welcomed.

Thanks

Marten

note the userTable and userRoleTable are the same because a user can only be in one role in this application.

<?xml version="1.0" encoding="UTF-8"?>
<Context path="/tulip_test">
    <Resource auth="Container" driverClassName="org.postgresql.Driver" logAbandoned="true" 
              maxActive="100" maxIdle="30" maxWait="10000" name="jdbc/tulip_test" password="sesame" removeAbandoned="true" 
              removeAbandonedTimeout="60" type="javax.sql.DataSource" url="jdbc:postgresql://localhost:5432/tulip_test?autoReconnect=true" 
              username="postgres"/>
 
    <Realm className="org.apache.catalina.realm.DataSourceRealm" debug="99"
                     dataSourceName="jdbc/tulip_test"
                     userTable="users" 
                     userNameCol="username" 
                     userCredCol="password"
                     userRoleTable="users" roleNameCol="role"/>
</Context>

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="3.1" xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd">

    <servlet>
        <servlet-name>Controller</servlet-name>
        <servlet-class>com.tuliptest.controller.Controller</servlet-class>
    </servlet>
    <servlet>
        <servlet-name>Login</servlet-name>
        <servlet-class>com.tuliptest.controller.Login</servlet-class>
    </servlet>
    <servlet>
        <servlet-name>LoginError</servlet-name>
        <servlet-class>com.tuliptest.controller.LoginError</servlet-class>
    </servlet>
    <servlet-mapping>
        <servlet-name>Controller</servlet-name>
        <url-pattern>/Controller</url-pattern>
    </servlet-mapping>
    <servlet-mapping>
        <servlet-name>Login</servlet-name>
        <url-pattern>/login</url-pattern>
    </servlet-mapping>
    <servlet-mapping>
        <servlet-name>LoginError</servlet-name>
        <url-pattern>/error</url-pattern>
    </servlet-mapping>
    <session-config>
        <session-timeout>
            30
        </session-timeout>
    </session-config>
    <welcome-file-list>
        <welcome-file>Controller</welcome-file>
    </welcome-file-list>
    <login-config>
        <auth-method>FORM</auth-method>
        <form-login-config>
            <form-login-page>/login</form-login-page>
            <form-error-page>/error</form-error-page>
        </form-login-config>
    </login-config>
    <security-role>
        <description>teacher or admin</description>
        <role-name>teacher</role-name>
    </security-role>
    <security-role>
        <description>student</description>
        <role-name>student</role-name>
    </security-role>
    <security-constraint>
        <web-resource-collection>
            <web-resource-name>Controller</web-resource-name>
            <url-pattern>/Controller</url-pattern>
        </web-resource-collection>
        <auth-constraint>
            <role-name>student</role-name>
            <role-name>teacher</role-name> 
        </auth-constraint>   
    </security-constraint>
</web-app>

[Tim Holloway]

I had to go back and check my docs, because I tend to think of the form-error-page as the "login fail page".

The standard Tomcat Realms all have debug logging available, so the short answer is that you simply bump the log level to "debug" or "trace" for the Tomcat logger. The exact logger name you need you can pull from its Tomcat source code, but it probably starts with something like "org.catalina.realm".

However, you don't get the form error page because there was literally an error in the Realm, which is why I forgot that that's its official name. You get it when you attempt to login and you fail. Because the userid/password was not authenticated by the Realm.

If memory serves, the stock JDBCRealm is case sensitive to both userid and password.  Also, padding spaces in the database columns containing those items will throw off the process. A lot of systemss NOT Unix/Linux!) are case-insensitive for userid, but case-sensitive for password. To get that you have to subclass the Realm with a custom Realm of your own.

[marten koomen]

Thanks Tim

I did a bit of deep dive into the logging functionality, and while not much of what I did made sense, login is now working, with the only thing effectively change I made was to add the localDateSource value in the Realm, as per below.

        <Realm className="org.apache.catalina.realm.DataSourceRealm" debug="9"
                     dataSourceName="jdbc/tulip_test"         
                     localDataSource="true"
                     userTable="users" 
                     userNameCol="username" 
                     userCredCol="password"
                     userRoleTable="users" roleNameCol="role"/>

on well, all fixed, thanks

[Tim Holloway]

Ouch!

I'm not sure what that's even supposed to mean. It sounds like this particular Realm allows using a JNDI server other than the one built into Tomcat. And even then, the built-in JNDI server should be the default!

Congratulations on solving this. Have a cow!

[marten koomen]

Thanks Tim, very generous with an undeserved cow, as I'm not sure what solved it, but as you suggest I think it had something to do with JINDI, and I suspect it's a Netbeans  things.

I found the following line in the localhost log in Tomcat's log folder
SEVERE: Exception performing authentication
javax.naming.NameNotFoundException: Name [jdbc/...] is not bound in this Context. Unable to find [jdbc].

which I thought strange because a servlet in the same context was able to access the database with the same details. So I added antiJARLocking in the Context tag in the context xml as per below. I found it somewhere, it's bit mysterious but it makes sense.  I'm not sure what the solution was - the antilocking or the localDataSource

<Context antiJARLocking="true" path="/....">
</Context>

[Tim Holloway]

I can't really say. a JNDI URL itself has the form java:/comp/env/foo/bar, where "foo" is a "directory" and "bar" is a resource. JNDI not only provides the database for JDBC Connection Pools, but also for anything else your app defines as a "Resource".

The "foo" part for a database connection pool is typically "jdbc", but it can be anything. The "bar" would be the resource name. You don't eevn need "foo/bar" if you're onlly going to define one connection resource, but it's good practice.

Possible the "localDatasource" allows omitting the "java:/comp/env", but there's insufficient documentation to tell. Unless NetBeans is messing around in tomcat's insides, it shouldn't make any difference that you're using NetBeans.

[marten koomen]

I use " java:/comp/env/foo/bar"  in the java code, as in

InitialContext ic = new InitialContext();
dataSource = (DataSource) ic.lookup("java:/comp/env/foo/bar");

but not in in my context.xml in the Realm descriptor for the dataSourceName where I just use foo/bar, when I do use java:/comp/env/foo/bar it doesn't work according to my trial and error method.

However I'm not sure that Netbeans isn't the culprit (apols for double negative). In Netbeans the database connection and authentication realm work well when I Run my app, but when I try Debug it hangs then finishes with the message below.

------------------------------------------------------------------------
BUILD SUCCESS
------------------------------------------------------------------------
Total time:  2.000 s
Finished at: 2024-09-22T19:51:43+10:00
------------------------------------------------------------------------
Deploying on Apache Tomcat or TomEE
   profile mode: false
   debug mode: true
   force redeploy: true
Checking data source definitions for missing JDBC drivers...
Stopping Tomcat process...
Waiting for Tomcat...
Stopping of Tomcat failed.

It seems to be having trouble picking up the drivers. Not having Debug is not a totally bad thing, as it forces me to code without mistakes.

[Tim Holloway]

Yes, the resource declaration doesn't use "java:comp/env".

You seem to be missing a lot of startup messages. I don't know how NetBeans is launching Tomcat, but in my preferred Eclipse environment, the Tomcat plugin (NOT the built-in SWT abomination) is using a live Tomcat installation and the database drivers are required to be in TOMCAT_HOME/lib, just as they would be in production.

If NetBeans is mucking around with things, you might have to manually include the jdbc JAR file as part of the run/test configuation classpath.

[marten koomen]

Thanks Tim -  another case of a novice blaming the tools.

I checked the TOMCAT_HOME\lib folder and it had a newer version of the postgres driver than declared in the pom.xml and in the development lib folder. Once I updated my pom.xml to reflect the newer driver, as well as delete older drivers from my system, things started to work as expected.

Having said that, it took a bit to expunge the outdated driver as it kept popping up in places, that Netbeans deploys tomcat apps from an \.m2 folder in my windows/users folder is annoying, and I had to restart my machine to ensure everything was good after some search and destroy missions.

Debug is now working fine, and from trial and error I can report that my set up does not work if  the localDataSource="true" element is not in the Realm element, but the antiJARLocking element is redundant.

[Tim Holloway]

Urk.

Yous database driver (postgresql) should NOT be declared in your POM. Your POM only defines the WAR that will be created and deployed. The Database Connection Pool is created and owned by Tomcat, and Tomcat has a different classpath than the WAR. Putting the database JAR in your WAR itself can lead to unpredictable results.

[marten koomen]

Thanks! a huge conceptual error fixed, my environment is now working swimmingly. I wasn't getting System.out.println output in my console before, and now that's functioning.  Onwards and upwards.