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 17:21:48 GMT
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

That was my question. How do I do that ?

On Mon, Sep 7, 2015 at 9:52 PM, André Warnier (tomcat) <>

> 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