tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sreyan Chakravarty <>
Subject Re: HTTP 400 with Form based authentication
Date Mon, 07 Sep 2015 18:17:26 GMT
I have found the cause of the problem. It seems that there is no null
checking in the DataSourceRealm in Tomcat. What I mean is that if a
particular user does not exist in the database and is credentials are
returned as a null string then no null checking is specified.

I would like to open this as a bug.

The easiest solution is to write a custom Realm that provides the null
checking. The only problem is that now why am I not being redirected to the
error page if I provide a valid user with a wrong password.

Please if anyone can tell me how to write a custom Realm then it would be
really appreciated.

Sreyan Chakravarty

On Mon, Sep 7, 2015 at 10:51 PM, Sreyan Chakravarty <> wrote:

> Yes but what happens when the user passes a user-id that is not present in
> the DB. Or a password that is incorrect. How would the server handle that ?
> If I pass an incorrect user I am getting a NPE. And if I pass an invalid
> password but a valid user a am not being redirected to the form-login-error
> page.
> That was my question. How do I do that ?
> On Mon, Sep 7, 2015 at 9:52 PM, André Warnier (tomcat) <>
> wrote:
>> Hi.
>> I have notv really followed this thread from the beginning, but maybe I
>> can contribute something here..
>> On 07.09.2015 15:56, Sreyan Chakravarty wrote:
>> ..
>>> Also can I webapp have different realms ? If so how do you distinguish
>>> them
>>> ? I was looking at the RealmBase source and I haven't noticed a place for
>>> realmName. If not then what is the use of the <realmName> element in
>>> web.xml ?
>> One webapp can only have one realm, but several webapps (or let's say
>> more generically several areas in "URL space" on the server) can share the
>> same realm.
>> The "realm" is something that the server sends back to the browser in the
>> "401 Authorization required response".  It is just a "label", which in
>> terms of AAA, identifies a certain collection of resources on the server,
>> covered by the same authentication/authorization requirements.
>> In the server configuration, you can choose yourself which resources are
>> covered by the same realm (label).
>> It is easier to explain this by example, in the general context of the
>> HTTP protocol.
>> The basic way in which AAA works in a webserver is this :
>> 1) the client/browser sends a request to the server, with a specific URL,
>> which resolves on the server to some resource
>> 2) the server evaluates the request, and resolves the resource to which
>> it applies (e.g. a static html page, a servlet, ..).  The server then
>> checks in its configuration, if this resource is protected.  If not, it
>> returns the requested resouerces to the client, and that's it.
>> 3) if the request is protected, the server checks if the request contains
>> some form of authentication. If yes, the server checks if this
>> authentication is valid, and applicable to this resource. If yes, the
>> server returns the requested resource, and that's it.
>> If not, the server returns a "forbidden" response.
>> 4) If the request did not contain an authentication, the server returns a
>> response to the client : "401 Authorization required", along with a realm
>> (the "label" applicable to this resource, as per the server configuration),
>> *and* the required authentication method (e.g. "Basic" or "Digest").
>> 5) the client sees this response, and interacts with the user to obtain
>> the required user-id/password.  Once obtained, the client/browser repeats
>> the same request to the server, but this time with some additional HTTP
>> header(s) containing the requested authentication.  At the same time, the
>> client/browser "remembers" this authentication, and remembers to which
>> "realm" it applies.
>> Then go back to (1) above.
>> If the client/browser (within the same browser session), later accesses
>> the same or another resource, and it receives from the server another 401
>> "auth required" response with a realm in it, and the browser knows that
>> *for this same realm* it already had a remembered authentication, then it
>> can send the same one again to the server, without needing to ask the user
>> again to fill-in a login dialog.
>> This is a pure HTTP-level mechanism, which works independently of any
>> "session" that one may have on the server (as long as the authentication
>> method is "Basic" or "Digest").
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message