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 > >
