Andre, Excellent reply given the context.
I would add the following: Given a webapp paradigm why would you need two different login pages to different resources? Usually what is done is change what the logged user sees/is able to see. For example: Scenario 1: WHEN a administrator logs in to the app XYZ /login URL THEN the basic option menu is displayed AND the "Manage users" option is displayed. WHEN a administrator goes to app XYZ /manage-users URL THEN "Manage users" page is dislayed Scenario 2: WHEN a regular user logs in to the app XYZ /login URL WHEN the basic option menu is displayed AND the "Manage users" option is hidden. WHEN a regular user goes to app XYZ /manage-users URL THEN "Access not allowed" page is displayed Of course there is a bit of servlet and security under hood, but I just wanted to show how the "ACL" would change based on the user-role, not the URL in question. On Wed, Apr 8, 2015 at 11:17 AM, André Warnier <a...@ice-sa.com> wrote: > Olayemi Olatunji wrote: > >> Hello Guys, >> >> >> >> I’m sort of a newbie to this but I need to know if its achievable. >> >> >> >> I want to create multiple login pages within a single web app e.g >> www.tomcat.org/login1, /login2 >> >> >> >> How can I achieve this? >> >> >> >> Hi. > Since you claim to be a newbie at this, I'll try to provide a "learning > answer". > > 1) the simple answer to your question would be : no (or at least not when > using the standard built-in authentication mechanisms). > But do not be too disappointed, because a more complete answer might be > "perhaps, but it depends on the circumstances and on what you want to > achieve exactly". > > 2) a basic and generic explanation of how WWW authentication works : > > a) the browser sends a request to the server, for some server resource > (e.g. a specific HTML page) > b) the server receives this request, and checks in its configuration, if > this resource is "protected" and requires some form of > authentication/permission. > If not, the server returns the requested page and things stop here. > So the rest below, is in the case where the requested resource is > protected. > c) the server then checks if the browser request already contained some > form of user authentication. (This can be various things, and i will not > elaborate at this stage). > If the request contained such an authentication, the server verifies it, > and if it is ok, the server returns the requested resource (e.g. the > desired HTML page), and things again stop here. > d) if the request did not contain ditto valid authentication, instead of > returning the requested resource, the server sends back something, to let > the browser/user know that an authentication is required. This can also be > various things, and I will again not elaborate, but let's suppose that in > your case what is returned is a login page. > e) the user/browser gets and sees the login page. The user fills it in, > with user-id and password, and sends this info back to the server. > f) the server verifies the submitted user-id/password, and if it is ok, > returns the desired resource to the browser/user. At the same time as > sending that requested page, the server also sends some "token" to the > browser (for example a cookie), containing the proof that this browser/user > is now authenticated. > g) for subsequent requests to the same server, the browser now always > sends this token along with the next requests. This will fulfill the check > that happens at (c) above, so that for these following requests, the server > will be happy and will return the requested pages, without asking again for > authentication. > > There are many variations possible in the details, but in rough terms, all > forms of WWW authentication follow more or less the above scheme. > > Your question relates to step (d) above. > The server has to return a login page, but you say that it should return a > specific one among several possible login pages. > The question thus becomes : how does the server know /which/ login page to > return ? > (The user is not yet known/authenticated, so the server cannot use the > user-id or any other user-related information in order to choose.) > So what other criteria can the server use then ? > > Possibilities would be : > - the login page changes depending on the time of day (that's kind of > unusual, but it is just to illustrate the point) > - the login page changes depending on the user's IP address > - the login page changes depending on something else which the browser > sends along with the initial request > > So, what is your use case precisely, and what are you trying to achieve ? > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
