You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Michael Jennings <so...@home.com> on 2001/06/21 01:01:02 UTC
FORM-based authentication idea
Hi everyone,
I just wanted to bounce an idea off of everyone. In tomcat, when one
specifies form-based
authentication you have to tell tomcat which page is the login page. This is
done
via the context's web.xml file by setting the <form-login-page> property
under the <login-config>
section. When a user hits a protected URL in a context, if they are not
already authenticated, the original
request page is saved in their session, then they are redirected to the
login page, if the login
succeeds, they are redirected to their original request page.
A problem happens however, when a user requests JUST the login page. After
logging in,
there is nowhere to redirect the user to since their is no original request
saved in the session.
What if there was a concept of a "default login target"? so that when a user
requests just the
designated login page, if they are already authenticated, they get
redirected to the "default login target"
page. Similarly, if a user requests the login page but they are not
authenticated, upon logging in they
would get redirected to the "default login target".
I realize that this is probably not in the JSP spec, but something like this
seems to be necessary.
The alternative is to look for the presence of a session variable called
"tomcat.auth.originalLocation"
and set up a default from within the login page if that session variable
isn't there.
Any thoughts?
-Mike
______________________
Mike Jennings
Southgate Software Ltd.
250-382-6851 (ph)
250-382-6800 (fax)
southgate.software@home.com
Re: FORM-based authentication idea
Posted by Christopher Cain <cc...@mhsoftware.com>.
Christopher Cain wrote:
>
> My main objection would be that it is adding
> non-spec features, which means that any apps
> written under Tomcat would not cleanly port
> to other spec-compliant servlet containers.
This, of course, should read: Any apps written under Tomcat "to levarage
this feature" would not port cleanly. Basically, it encourages
developers to code outside of the spec. If they relied on their own
custom tags to do the job, then they just transplant their custom
web.xml.
Re: FORM-based authentication idea
Posted by Michael Jennings <so...@home.com>.
> I would simply be a little bit leary of extending the web.xml file
> format beyond what the spec states, given that Tomcat is the official
> reference implementation. My feeling would be to change the internal
> behavior of the problem you point out to be handled a bit more
> elegantly, rather than open up a "web application format specification"
> can of worms. Adding internal behavior to an engine, above and beyond
> the spec, is one thing. Changing/adding functionality at the webapp
> level is quite another.
>
> In any case, I actually liked your idea :-) You've sparked a few good
> ideas for my own applications.
Thanks! What about adding a tomcat-specific <context-param>
for handling this case?
Right now I just have a snippet in my login.jsp file that looks like the
following:
<%
if (session.getAttribute("tomcat.auth.originalLocation")==null)
session.setAttribute("tomcat.auth.originalLocation","user/welcome.jsp");
%>
A special <context-param> that does the above automatically would mean that
my JSP pages wouldn't have the above tomcat-specific hack and I wouldn't
need to repeat the above hack for every secure context I set up.
I've got to take off now, so I won't send any more messages until tommorow.
Thanks for your input!
-Mike
>
> I just disagree with the specific implementation which would extend
> web.xml beyond what the specification allows for.
Re: FORM-based authentication idea
Posted by Christopher Cain <cc...@mhsoftware.com>.
Michael Jennings wrote:
>
> If this proposed feature (default login target) was added to tomcat, then
> any JSP pages
> developed would just behave a bit nicer in this special case, they would
> still continue
> to work correctly in any spec-compliant jsp container.
I would simply be a little bit leary of extending the web.xml file
format beyond what the spec states, given that Tomcat is the official
reference implementation. My feeling would be to change the internal
behavior of the problem you point out to be handled a bit more
elegantly, rather than open up a "web application format specification"
can of worms. Adding internal behavior to an engine, above and beyond
the spec, is one thing. Changing/adding functionality at the webapp
level is quite another.
In any case, I actually liked your idea :-) You've sparked a few good
ideas for my own applications.
I just disagree with the specific implementation which would extend
web.xml beyond what the specification allows for.
Re: FORM-based authentication idea
Posted by Michael Jennings <so...@home.com>.
> FWIW, I guess I could see some small convenience in a target-fail and
> target-succeed context parameter. I guess I if I had multiple entry
> points into my application, such as a more complex manual authentication
> routine within a different application or something, I could also grab
> these values for all successful or failed attempts to access the system.
> I guess it would let me standardize my authentication result pages and
> have them listed in one single place, which means I would probably name
> them "auth-fail-target" and "auth-succeed-target" rather than making
> them login-specific. Then again, I could probably implement this same
> thing in a dozen other ways or using my own custom context param tags. I
> guess my personal feeling is that it probably wouldn't be an obtrusive
> feature, and many users may in fact find it convenient. My main
> objection would be that it is adding non-spec features, which means that
> any apps written under Tomcat would not cleanly port to other
> spec-compliant servlet containers.
If someone uses a spec-compliant servlet container to set up a context
called "/abc/" with the form-login-page set to "/abc/login.jsp"
and the form-error-page set to "/abc/loginerror.jsp"
and all pages in "/abc/admin/*" needing a user with "administrator" role for
access
and all pages in "/abc/webuser/*" needing a user with the "webuser" role for
access.
What happens when an un-authenticated user simply requests
"/abc/login.jsp" ? I suspect that what happens depends on your JSP
container, since
the spec doesn't seem to handle this case.
If this proposed feature (default login target) was added to tomcat, then
any JSP pages
developed would just behave a bit nicer in this special case, they would
still continue
to work correctly in any spec-compliant jsp container.
That's my $.02 anyhow.
-Mike
>
> Just my $.02.
>
> - Christopher
Re: FORM-based authentication idea
Posted by Christopher Cain <cc...@mhsoftware.com>.
Andy Armstrong wrote:
>
> Michael Jennings wrote:
>
> > Hi everyone,
> >
> > I just wanted to bounce an idea off of everyone. In tomcat, when one
> > specifies form-based
> > authentication you have to tell tomcat which page is the login page. This is
> > done
> > via the context's web.xml file by setting the <form-login-page> property
> > under the <login-config>
> > section. When a user hits a protected URL in a context, if they are not
> > already authenticated, the original
> > request page is saved in their session, then they are redirected to the
> > login page, if the login
> > succeeds, they are redirected to their original request page.
> > A problem happens however, when a user requests JUST the login page. After
> > logging in,
> > there is nowhere to redirect the user to since their is no original request
> > saved in the session.
> >
> > What if there was a concept of a "default login target"? so that when a user
> > requests just the
> > designated login page, if they are already authenticated, they get
> > redirected to the "default login target"
> > page. Similarly, if a user requests the login page but they are not
> > authenticated, upon logging in they
> > would get redirected to the "default login target".
> >
> > I realize that this is probably not in the JSP spec, but something like this
> > seems to be necessary.
> > The alternative is to look for the presence of a session variable called
> > "tomcat.auth.originalLocation"
> > and set up a default from within the login page if that session variable
> > isn't there.
> >
> > Any thoughts?
>
> Why not supply the default in a hidden field on the login page?
>
> --
> Andy Armstrong, Tagish
FWIW, I guess I could see some small convenience in a target-fail and
target-succeed context parameter. I guess I if I had multiple entry
points into my application, such as a more complex manual authentication
routine within a different application or something, I could also grab
these values for all successful or failed attempts to access the system.
I guess it would let me standardize my authentication result pages and
have them listed in one single place, which means I would probably name
them "auth-fail-target" and "auth-succeed-target" rather than making
them login-specific. Then again, I could probably implement this same
thing in a dozen other ways or using my own custom context param tags. I
guess my personal feeling is that it probably wouldn't be an obtrusive
feature, and many users may in fact find it convenient. My main
objection would be that it is adding non-spec features, which means that
any apps written under Tomcat would not cleanly port to other
spec-compliant servlet containers.
Just my $.02.
- Christopher
Re: FORM-based authentication idea
Posted by Andy Armstrong <an...@tagish.com>.
Michael Jennings wrote:
>>>The alternative is to look for the presence of a session variable called
>>>"tomcat.auth.originalLocation"
>>>and set up a default from within the login page if that session variable
>>>isn't there.
>>>
>>>Any thoughts?
>>>
>>
>>Why not supply the default in a hidden field on the login page?
>>
>
> wouldn't that just overwrite the session variable
> "tomcat.auth.originalLocation" even
> if there was stuff in it?
Sorry. Stupid head engaged. I've just re-read your post. Please carry on
without me ;-)
--
Andy Armstrong, Tagish
Re: FORM-based authentication idea
Posted by Michael Jennings <so...@home.com>.
> > The alternative is to look for the presence of a session variable called
> > "tomcat.auth.originalLocation"
> > and set up a default from within the login page if that session variable
> > isn't there.
> >
> > Any thoughts?
>
>
> Why not supply the default in a hidden field on the login page?
wouldn't that just overwrite the session variable
"tomcat.auth.originalLocation" even
if there was stuff in it?
Maybe I'm not understanding your suggestion.
-Mike
>
>
> --
> Andy Armstrong, Tagish
>
>
Re: FORM-based authentication idea
Posted by Andy Armstrong <an...@tagish.com>.
Michael Jennings wrote:
> Hi everyone,
>
> I just wanted to bounce an idea off of everyone. In tomcat, when one
> specifies form-based
> authentication you have to tell tomcat which page is the login page. This is
> done
> via the context's web.xml file by setting the <form-login-page> property
> under the <login-config>
> section. When a user hits a protected URL in a context, if they are not
> already authenticated, the original
> request page is saved in their session, then they are redirected to the
> login page, if the login
> succeeds, they are redirected to their original request page.
> A problem happens however, when a user requests JUST the login page. After
> logging in,
> there is nowhere to redirect the user to since their is no original request
> saved in the session.
>
> What if there was a concept of a "default login target"? so that when a user
> requests just the
> designated login page, if they are already authenticated, they get
> redirected to the "default login target"
> page. Similarly, if a user requests the login page but they are not
> authenticated, upon logging in they
> would get redirected to the "default login target".
>
> I realize that this is probably not in the JSP spec, but something like this
> seems to be necessary.
> The alternative is to look for the presence of a session variable called
> "tomcat.auth.originalLocation"
> and set up a default from within the login page if that session variable
> isn't there.
>
> Any thoughts?
Why not supply the default in a hidden field on the login page?
--
Andy Armstrong, Tagish
Re: FORM-based authentication idea
Posted by Jeff Kilbride <je...@kilbride.com>.
FWIW, I ran into this problem with users bookmarking the login page and
returning to it without trying to access a protected resource. In the
current implementation in 3.2.2, I don't think you can prevent that, can
you?
After being authenticated, the user was being dropped into the directory
that contained my login.jsp. I found the easiest solution was to have my
login.jsp in it's own directory with an index.jsp that simply redirects to
the appropriate page inside my protected resource. Took me about a minute to
implement and it works well.
Craig, from your previous posts I am under the impression that the current
implementation for form-based logins uses a sendRedirect() -- which is why
you can see and bookmark the URL for your login.jsp page (3.2.2). Is this
correct? Is that going to change to use RequestDispatcher.forward() in the
future? If so, that should solve the bookmarking problem.
Thanks,
--jeff
P.S. -- I always use server-relative links, but I'm a programmer! :o) My
designers using Dreamweaver always send me files with relative links...
----- Original Message -----
From: <cm...@yahoo.com>
To: <to...@jakarta.apache.org>
Sent: Thursday, June 21, 2001 4:48 PM
Subject: Re: FORM-based authentication idea
> On Thu, 21 Jun 2001, Craig R. McClanahan wrote:
>
> > > If the login page would be displayed all the <a href="" /> or <img> in
the
> > > login page will be treated by the browser as relative to
> > > /mywebapp/private, while the login page can be somewhere else.
> > >
> >
> > The form login page should use server-relative URLs, or a <base> tag
> > in the <head> section. That way, the initial display of the login page
> > will work correctly even on a container that does (what amounts to) a
> > RequestDispatcher.forward() to the login page.
>
> Should != must.
>
> AFAIK there is no restriction on what is allowed in a login page - except
> the use of special name for the action and variables.
>
> That mean a page using relative URLs is legal, and the container must deal
> with it. ( I don't know too many pages using the <base> tag anyway, and
> relative URLs are prefered in many cases - I would say they are far more
> frequent than server-relative URLs ).
>
>
> Costin
>
Re: FORM-based authentication idea
Posted by cm...@yahoo.com.
On Thu, 21 Jun 2001, Craig R. McClanahan wrote:
> > If the login page would be displayed all the <a href="" /> or <img> in the
> > login page will be treated by the browser as relative to
> > /mywebapp/private, while the login page can be somewhere else.
> >
>
> The form login page should use server-relative URLs, or a <base> tag
> in the <head> section. That way, the initial display of the login page
> will work correctly even on a container that does (what amounts to) a
> RequestDispatcher.forward() to the login page.
Should != must.
AFAIK there is no restriction on what is allowed in a login page - except
the use of special name for the action and variables.
That mean a page using relative URLs is legal, and the container must deal
with it. ( I don't know too many pages using the <base> tag anyway, and
relative URLs are prefered in many cases - I would say they are far more
frequent than server-relative URLs ).
Costin
Re: FORM-based authentication idea
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 21 Jun 2001 cmanolache@yahoo.com wrote:
> On Thu, 21 Jun 2001, Michael Jennings wrote:
>
> > Okay,
> >
> > I was being stupid. I understand now, with form-based authentication when
> > you
> > request /mywebapp/private/somefile.jsp what you get back should just be
> > generated from the login page, then when you submit your credentials,
> > it returns whatever is generated from /mywebapp/private/somefile.jsp
>
> That would be nice - if possible. I spent quite a bit of time finding
> workarounds that would allow such a behavior.
>
> If the login page would be displayed all the <a href="" /> or <img> in the
> login page will be treated by the browser as relative to
> /mywebapp/private, while the login page can be somewhere else.
>
The form login page should use server-relative URLs, or a <base> tag
in the <head> section. That way, the initial display of the login page
will work correctly even on a container that does (what amounts to) a
RequestDispatcher.forward() to the login page.
> > So the redirection thing is just how it is implemented right now.
> >
> > Stupid me.
>
> Probably it's me the one - since everyone seems to know how to implement
> such a thing except me.
>
> Costin
>
>
Craig
Re: FORM-based authentication idea
Posted by cm...@yahoo.com.
On Thu, 21 Jun 2001, Michael Jennings wrote:
> Okay,
>
> I was being stupid. I understand now, with form-based authentication when
> you
> request /mywebapp/private/somefile.jsp what you get back should just be
> generated from the login page, then when you submit your credentials,
> it returns whatever is generated from /mywebapp/private/somefile.jsp
That would be nice - if possible. I spent quite a bit of time finding
workarounds that would allow such a behavior.
If the login page would be displayed all the <a href="" /> or <img> in the
login page will be treated by the browser as relative to
/mywebapp/private, while the login page can be somewhere else.
> So the redirection thing is just how it is implemented right now.
>
> Stupid me.
Probably it's me the one - since everyone seems to know how to implement
such a thing except me.
Costin
Re: FORM-based authentication idea
Posted by Michael Jennings <so...@home.com>.
Okay,
I was being stupid. I understand now, with form-based authentication when
you
request /mywebapp/private/somefile.jsp what you get back should just be
generated from the login page, then when you submit your credentials,
it returns whatever is generated from /mywebapp/private/somefile.jsp
So the redirection thing is just how it is implemented right now.
Stupid me.
-Mike
----- Original Message -----
From: "Michael Jennings" <so...@home.com>
To: <to...@jakarta.apache.org>
Sent: Thursday, June 21, 2001 2:21 PM
Subject: Re: FORM-based authentication idea
> > It's kinda hard for them to bookmark the login page when they don't know
> > the URL.
> >
> > Keep in mind that, as far as the browser is concerned, the URL in the
> > location is still the page that was originally requested. Therefore, a
> > bookmark for the login form will actually be to the real page (which
might
> > again trigger authentication if they have exited and restarted before
> > following the bookmark).
>
> Right now I've got a web app set up with tomcat 3.2.2 using form-based
> authentication,
> when I request /WWAT2/user/welcome.jsp I get redirected to
> /WWAT2/login.jsp which I see in my address bar. Just for fun I bookmarked
> it,
> logged in, then I was redirected to /WWAT2/user/welcome.jsp (which was my
> original request)
> I logged out, then went to my bookmarked /WWAT2/login.jsp
>
> So it looks like I do see the login URL. (I have absolutely no links to
the
> /WWAT2/login.jsp anywhere)
>
> So what you are saying is that if a user doesn't see the login URL, there
> are no links to it in the web-app,
> the chances of them requesting JUST the login page of a web-app are so few
> and far between
> that handling that special case should just be ignored?
>
> Is there something wrong with my tomcat configuration? The form-based
> authentication
> works like a dream except for showing me the URL of the login page. The
> behaviour
> is fine.
>
> -Mike
>
> > And (at least for servlet 2.3, but Tomcat 4 doesn't do it right yet),
the
> > container is supposed to redirect to the originally requested page after
> > authentication is completed. The net effect of this is that the URL of
> > the login page is never visible to the user, unless you have
deliberately
> > linked to it in your user interface. That's one of the reasons such
links
> > should not exist.
> >
> > > > NOTE: If you don't like the philosophy of form-based login, the
> > > > appropriate forum is the feedback address for the servlet spec
> > > > (servletapi-feedback@eng.sun.com), because that is where the
> requirements
> > > > for how Tomcat works are defined.
> > > >
> > > > Craig
> > >
> > > Thanks! I'll forward my suggestion on to them.
> > > -Mike
> > >
> > >
> >
> > Craig
> >
> >
>
Re: FORM-based authentication idea
Posted by Michael Jennings <so...@home.com>.
> It's kinda hard for them to bookmark the login page when they don't know
> the URL.
>
> Keep in mind that, as far as the browser is concerned, the URL in the
> location is still the page that was originally requested. Therefore, a
> bookmark for the login form will actually be to the real page (which might
> again trigger authentication if they have exited and restarted before
> following the bookmark).
Right now I've got a web app set up with tomcat 3.2.2 using form-based
authentication,
when I request /WWAT2/user/welcome.jsp I get redirected to
/WWAT2/login.jsp which I see in my address bar. Just for fun I bookmarked
it,
logged in, then I was redirected to /WWAT2/user/welcome.jsp (which was my
original request)
I logged out, then went to my bookmarked /WWAT2/login.jsp
So it looks like I do see the login URL. (I have absolutely no links to the
/WWAT2/login.jsp anywhere)
So what you are saying is that if a user doesn't see the login URL, there
are no links to it in the web-app,
the chances of them requesting JUST the login page of a web-app are so few
and far between
that handling that special case should just be ignored?
Is there something wrong with my tomcat configuration? The form-based
authentication
works like a dream except for showing me the URL of the login page. The
behaviour
is fine.
-Mike
> And (at least for servlet 2.3, but Tomcat 4 doesn't do it right yet), the
> container is supposed to redirect to the originally requested page after
> authentication is completed. The net effect of this is that the URL of
> the login page is never visible to the user, unless you have deliberately
> linked to it in your user interface. That's one of the reasons such links
> should not exist.
>
> > > NOTE: If you don't like the philosophy of form-based login, the
> > > appropriate forum is the feedback address for the servlet spec
> > > (servletapi-feedback@eng.sun.com), because that is where the
requirements
> > > for how Tomcat works are defined.
> > >
> > > Craig
> >
> > Thanks! I'll forward my suggestion on to them.
> > -Mike
> >
> >
>
> Craig
>
>
Re: FORM-based authentication idea
Posted by cm...@yahoo.com.
> On Thu, 21 Jun 2001, Michael Jennings wrote:
>
> > That's true. The point I was trying to make is that there is nothing to
> > stop an end-user from bookmarking a login page or typing it in
> > directly, even if you have no linkages to the login page in your
> > user interface.
> >
>
> It's kinda hard for them to bookmark the login page when they don't know
> the URL.
>
> Keep in mind that, as far as the browser is concerned, the URL in the
> location is still the page that was originally requested.
> Therefore,
> a bookmark for the login form will actually be to the real page (which
> might again trigger authentication if they have exited and restarted
> before following the bookmark).
Not quite true.
In most cases the login page will not be in the same directory with the
page that needs authentication. If the container does not send a redirect,
but internally displays the login page, all the relative URLs will be
treated by the browser as relatvie to the authenticated page, not the
login page.
Since the spec doesn't mention that the login pages are not allowed to
have relative URLs - I'm not sure it's that easy to implement the form
login without a redirection.
> And (at least for servlet 2.3, but Tomcat 4 doesn't do it right yet), the
> container is supposed to redirect to the originally requested page after
> authentication is completed. The net effect of this is that the URL of
> the login page is never visible to the user, unless you have deliberately
> linked to it in your user interface. That's one of the reasons such links
> should not exist.
Costin
Re: FORM-based authentication idea
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 21 Jun 2001, Michael Jennings wrote:
> > Why is the button there at all? There should be zero linkages to the
> > login page from *anywhere* in your user interface.
>
> That's true. The point I was trying to make is that there is nothing to
> stop an end-user from bookmarking a login page or typing it in
> directly, even if you have no linkages to the login page in your
> user interface.
>
It's kinda hard for them to bookmark the login page when they don't know
the URL.
Keep in mind that, as far as the browser is concerned, the URL in the
location is still the page that was originally requested. Therefore, a
bookmark for the login form will actually be to the real page (which might
again trigger authentication if they have exited and restarted before
following the bookmark).
And (at least for servlet 2.3, but Tomcat 4 doesn't do it right yet), the
container is supposed to redirect to the originally requested page after
authentication is completed. The net effect of this is that the URL of
the login page is never visible to the user, unless you have deliberately
linked to it in your user interface. That's one of the reasons such links
should not exist.
> > NOTE: If you don't like the philosophy of form-based login, the
> > appropriate forum is the feedback address for the servlet spec
> > (servletapi-feedback@eng.sun.com), because that is where the requirements
> > for how Tomcat works are defined.
> >
> > Craig
>
> Thanks! I'll forward my suggestion on to them.
> -Mike
>
>
Craig
Re: FORM-based authentication idea
Posted by Michael Jennings <so...@home.com>.
> Why is the button there at all? There should be zero linkages to the
> login page from *anywhere* in your user interface.
That's true. The point I was trying to make is that there is nothing to
stop an end-user from bookmarking a login page or typing it in
directly, even if you have no linkages to the login page in your
user interface.
> NOTE: If you don't like the philosophy of form-based login, the
> appropriate forum is the feedback address for the servlet spec
> (servletapi-feedback@eng.sun.com), because that is where the requirements
> for how Tomcat works are defined.
>
> Craig
Thanks! I'll forward my suggestion on to them.
-Mike
Re: FORM-based authentication idea
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 21 Jun 2001, Michael Jennings wrote:
> > The best way to think about form-based login is like this:
> >
> > * The login page is (in essence) part of the container,
> > not the application. Therefore, ...
> >
> > * The login page should *never* be referenced directly by any
> > other application page, and ...
> >
> > * The login page should *never* be requested directly by the
> > user.
>
> How do you enforce that a particular URL should never be asked for by a
> user?
> Shouldn't the responsibility to handle that case rest with the JSP container
> and not the user?
Nope ... it's up to the application developer.
> Isn't that kind of like designing a user interface where a button shouldn't
> be clicked
> when the program is in a certain state and instead of making the button
> invisible
> or disabled when in that state, you simply say "well, the user shouldn't
> click that
> button when the program is in that state"
>
>
Why is the button there at all? There should be zero linkages to the
login page from *anywhere* in your user interface.
Think of the login page as part of the container, not part of the
application.
NOTE: If you don't like the philosophy of form-based login, the
appropriate forum is the feedback address for the servlet spec
(servletapi-feedback@eng.sun.com), because that is where the requirements
for how Tomcat works are defined.
Craig
Re: FORM-based authentication idea
Posted by Michael Jennings <so...@home.com>.
> The best way to think about form-based login is like this:
>
> * The login page is (in essence) part of the container,
> not the application. Therefore, ...
>
> * The login page should *never* be referenced directly by any
> other application page, and ...
>
> * The login page should *never* be requested directly by the
> user.
How do you enforce that a particular URL should never be asked for by a
user?
Shouldn't the responsibility to handle that case rest with the JSP container
and not the user?
Isn't that kind of like designing a user interface where a button shouldn't
be clicked
when the program is in a certain state and instead of making the button
invisible
or disabled when in that state, you simply say "well, the user shouldn't
click that
button when the program is in that state"
>
> Using form-based login pages in any other manner is just going to cause
> you grief, unless and until the servlet spec were changed to mandate a
> behavior like what you propose.
>
> NOTE: A primary reason that form-based login was designed the way it is
> was to emulate the user experience of how BASIC login works. With BASIC,
> you never reference the login page directly, right? It just pops up
> whenever you try to access a protected resource for the first time --
> then, you are transparently returned to the resource you originally
> requested. Using form-based login lets you manage the look-and-feel of
> the login page, but it should *not* be part of your application's normal
> flow.
>
> > Any thoughts?
> >
> > -Mike
>
> Craig McClanahan
>
Re: FORM-based authentication idea
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 20 Jun 2001, Michael Jennings wrote:
> Hi everyone,
>
> I just wanted to bounce an idea off of everyone. In tomcat, when one
> specifies form-based
> authentication you have to tell tomcat which page is the login page. This is
> done
> via the context's web.xml file by setting the <form-login-page> property
> under the <login-config>
> section. When a user hits a protected URL in a context, if they are not
> already authenticated, the original
> request page is saved in their session, then they are redirected to the
> login page, if the login
> succeeds, they are redirected to their original request page.
> A problem happens however, when a user requests JUST the login page. After
> logging in,
> there is nowhere to redirect the user to since their is no original request
> saved in the session.
>
> What if there was a concept of a "default login target"? so that when a user
> requests just the
> designated login page, if they are already authenticated, they get
> redirected to the "default login target"
> page. Similarly, if a user requests the login page but they are not
> authenticated, upon logging in they
> would get redirected to the "default login target".
>
> I realize that this is probably not in the JSP spec, but something like this
> seems to be necessary.
> The alternative is to look for the presence of a session variable called
> "tomcat.auth.originalLocation"
> and set up a default from within the login page if that session variable
> isn't there.
>
The best way to think about form-based login is like this:
* The login page is (in essence) part of the container,
not the application. Therefore, ...
* The login page should *never* be referenced directly by any
other application page, and ...
* The login page should *never* be requested directly by the
user.
Using form-based login pages in any other manner is just going to cause
you grief, unless and until the servlet spec were changed to mandate a
behavior like what you propose.
NOTE: A primary reason that form-based login was designed the way it is
was to emulate the user experience of how BASIC login works. With BASIC,
you never reference the login page directly, right? It just pops up
whenever you try to access a protected resource for the first time --
then, you are transparently returned to the resource you originally
requested. Using form-based login lets you manage the look-and-feel of
the login page, but it should *not* be part of your application's normal
flow.
> Any thoughts?
>
> -Mike
Craig McClanahan