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. Regards, Sreyan Chakravarty On Mon, Sep 7, 2015 at 10:51 PM, Sreyan Chakravarty < sreyan.mail...@gmail.com> 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) <a...@ice-sa.com> > 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: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >
