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
