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: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
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
>
