See below.
On Mon, 11 Nov 2002, Algirdas P. Veitas wrote:
> Date: Mon, 11 Nov 2002 21:56:46 -0700
> From: Algirdas P. Veitas <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Servlet Spec interpretation FORM-based authentication
>
> Folks,
>
> I am running into an issue with FORM-based authentication
> using 4.1.12 (and 4.0.4). It seems as if the implementation
> is not in line with the 2.3 Servlet Specification. Specifically,
> the Servlet Spec states:
>
> SRV.12.5.3 Form Base Authentication
> --snip--
> J2EE.12.5.3.1 Login Form Notes
> --snip--
> "If the form based login is invoked because of an HTTP request, the original
> request parameters must be preserved by the container for use if, on
> successful authentication, it redirects the call to the requested resource."
>
> It seems as if the request parameters are not being preserved by the
> container. After a successful login the container forwards me to the target
> URL (a JSP page). The JSP page executes the following code:
>
> Enumeration params = request.getParameterNames();
> while (params.hasMoreElements())
> {
> String paramKey = (String)params.nextElement();
> String paramVal = request.getParameter(paramKey);
> System.out.println(paramKey + " = " + paramKey);
> }
>
> which I would expect to atleast see printed out:
>
> j_username = <some val>
> j_password = <some val 2>
>
> but in fact these request parameters are not printed out and thus not part of
> the request.
>
You are making an incorrect assumption. It is the *original* request
(i.e. the one to a protected resource when the user wasn't logged in, and
therefore triggered the login) that is saved, and that original request is
"replayed" once the login has been completed successfully.
>From the user viewpoint, and from your application's viewpoint, the flow
of events is *exactly* like BASIC authentication works -- in between
regular requests, the login page (form-based) or popup (BASIC) is
displayed, then the request that triggered the login is executed. After
login has been completed, you'll see that getRequestUser() starts
returning the logged-in username, but from the app you're not able to see
the password.
The actual saving and restoring occurs in
org.apache.catalina.authenticator.FormAuthenticator.
> A bit of digging in the source revealed that in the method
>
> authenticate(HttpRequest,HttpResponse,LoginConfig)
>
> of class org.apache.catalina.authenticator.FormAuthenticator, the code is
> executing HttpResponse.sendRedirect(String url) in order to forward the user
> to the appropriate page. A sendRedirect() will wipe out all of the original
> request parameters.
>
> I think in order to preserve the parameters the sendRedirect() needs to be
> replaced by HttpRequest.getServletDispatcher().forward().
>
> Has anyone else seen this behavior and is my claim valid?
>
Whether a forward or redirect is used is a controversial issue, but
doesn't affect the flow of events that I describe above -- it's a separate
decision.
The reason that Tomcat currently uses a redirect here, and when displaying
welcome pages, is because so many app developers don't understand an
important issue related to RequestDispatcher.forward() -- it would break
any relative URL references in the login page (such as images), because
relative references are resolved, by the browser, against the URL that was
originally submitted to (i.e. the protected page). Using a redirect, the
URL from which relative references are resolved is that of the login page
itself.
> Thanks,
> Al
Craig McClanahan
--
To unsubscribe, e-mail: <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>
