Thanks Dimitris,

Really helped to know where the issue had changed.

Zoran


On 27/8/2025 10:12 pm, Dimitris Soumis wrote:
On Wed, Aug 27, 2025 at 2:56 AM Zoran Avtarovski <[email protected]>
wrote:

Hi Guys,

We are seeing a strange issue with user logins. If a user includes extra
spaces in their username the login process is successful, but the
request username from request.getRemoteUser() still has the extra space
which is causing issues with our internal processes.

Ideally we'd like to change the setup to fail the login if extra spaces
are included. I've included our current config, and appreciate any help
in addressing this.

This is all using Tomcat 9 with Java 11 and I have included our config
below.

Thanks

Zoran

/META-INF/context.xml

<Resource
          name="jdbc/appDB"
          type="javax.sql.DataSource"
          auth="Container"
          driverClassName="org.mariadb.jdbc.Driver"

url="jdbc:mariadb://localhost:3306/app_db?useEncoding=true&amp;characterEncoding=UTF-8&amp;zeroDateTimeBehavior=convertToNull"
          username="user"
          password="password"
          maxActive="100"
          maxIdle="30"
          maxWait="10000"
          removeAbandoned="true"
          removeAbandonedTimeout="60"
          logAbandoned="true"
          testOnBorrow="true"
          validationQuery="select count(*) from tableXX"
      />

<Realm className="org.apache.catalina.realm.LockOutRealm">
          <Realm className="org.apache.catalina.realm.DataSourceRealm"
                 dataSourceName="jdbc/appDB"
                 localDataSource="true"
                 roleNameCol="status"
                 userCredCol="password"
                 userNameCol="user_name"
                 userRoleTable="users"
                 userTable="users"
          >
              <CredentialHandler
className="org.apache.catalina.realm.MessageDigestCredentialHandler"
                  algorithm="SHA"
                  iterations="1"
                  saltLength="0"
              />
          </Realm>
      </Realm>

/WEB-INF/web.xml

      <security-constraint>
          <display-name>Admin Console</display-name>
          <web-resource-collection>
              <web-resource-name>Restricted Access</web-resource-name>
              <!-- Define the context-relative URL(s) to be protected -->
              <description/>
              <url-pattern>/protected/*</url-pattern>
          </web-resource-collection>
          <auth-constraint>
              <!-- Anyone with one of the listed roles may access this
area -->
              <role-name>1</role-name>
          </auth-constraint>
      </security-constraint>

<login-config>
          <auth-method>FORM</auth-method>
          <realm-name>App</realm-name>
          <form-login-config>
<form-login-page>/login.jsp</form-login-page>
<form-error-page>/login-error.jsp</form-error-page>
          </form-login-config>
      </login-config>



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]


Hi Zoran,

The issue arises from the semantics of the MariaDB database and is not a
defect in Tomcat. By default MariaDB uses PAD collations, which means that
trailing whitespace will be ignored. When the call to
request.getRemoteUser() is being made, the container correctly returns the
name associated with the current session, which is the username with the
trailing space.

Possible solutions for this would be:
1) Changing the default MariaDB Collation to NO PAD or binary. See Changing
Default Collation
<https://mariadb.com/docs/server/reference/data-types/string-data-types/character-sets/setting-character-sets-and-collations#changing-default-collation>
.
2) On Tomcat's side, implementing a custom Realm extending DataSourceRealm
and enforcing that username doesn't contain leading or trailing whitespace.

Kind regards,
Dimitris Soumis


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to