Bug 4104 - Null savedrequest at FormAuthenticator.authenticate()
Summary: Null savedrequest at FormAuthenticator.authenticate()
Alias: None
Product: Tomcat 4
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 4.0 Final
Hardware: Other other
: P3 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2001-10-11 06:06 UTC by Vicente Salvador
Modified: 2004-11-16 19:05 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Vicente Salvador 2001-10-11 06:06:19 UTC
At the end of the method we have:

requestURI = savedRequestURL(session);
if (debug >= 1)
   log("Redirecting to original '" + requestURI + "'");
return (false);

But the savedRequestURL can return null.
Steps to reproduce:
1. open the browser and type the UTL when the login form page resides:

2.Authenticate correctly and then the servers redirects you to:
I know that this is not usual but we need a method to detect this, and redirect
to a proper URL. Maybe this URL can be setted by a property param. If not
possible, a 4.0.1 timeframe patch could be:

requestURI = savedRequestURL(session);
if (debug >= 1)
   log("Redirecting to original '" + requestURI + "'");
if (requestURL == null)
    requestURL = "";
return (false);

I've not tested this patch but it should work;
Comment 1 Remy Maucherat 2001-10-11 09:06:16 UTC
Same issue as 3839.

*** This bug has been marked as a duplicate of 3839 ***
Comment 2 Craig McClanahan 2001-10-11 09:33:21 UTC
It is not valid for an application to directly reference the form login page. 
I'm going to be changing the authenticator to return a BAD_REQUEST error status
instead of a meaningless 404 for the "/null" page to make this more clear to
application users.
Comment 3 Craig McClanahan 2001-10-11 15:58:43 UTC
Changed (as I described earlier) in nightly build 20011012.  Will be changed in
4.0.1 final release also (after confirming it was OK with Remy).
Comment 4 T 2001-10-12 01:56:12 UTC
I think it is very useful, in some cases, to have the login page referenced 
directly. For example if a web application needs a to show login form on a main 
page (is not a login page itself). The login form has text inputs j_username 
and j_password and will be submitted directly to j_security_check. In this case 
the /null page is returned to the user, as in case if login page were 
referenced directly.

I think that the best solution for this would be to have another parameter in 
web.xml "form-login-config" section. The parameter specifies the page, which 
will be returned if the login page were referenced directly and the login 
succeeded. But beacuse the servlet 2.3 specification doesn't say anything about 
it, then it does break the compatibility.

Another solution would be to redirected the user to the default page. If the 
requestURI is null then the Tomcat checks if the catalog of the login page has 
a default page. If the default page is present, then redirects the user to that 
page, else returns the BAD_REQUEST response. This solution raises the question: 
how to find the URI of the default page of the resource? I searched for this in 
the Servlet API and didn't find a clear answer. Maybe the RequestDispather 
could be used for this?

I know this bug is also present in Tomcat 3.2.2 (#4048). And at the moment I 
solved this by defining a /null mapping in web.xml. The servlet behind this 
mapping redirects the users to a default page.
For example:

Of course this is a bad solution, but I didn't find any better. But if in the 
future the BAD_REQUEST response will be returned, then I can't see any solution 
to have the this functionality? 

I also read Craig's comment (bug #3839) that swiching to BASIC authentication 
would break the application functionality if the login form is hyperlinked by 
apps pages. But in my case it is nessesary to have a login form on the main 
page of my application. 

Of course another solution would be to build the authentication/authorization 
login into web application, so the problem could be solved, but in this way I 
can't use many features of the Web container, for example: have the username 
returned by calling the request.getRemoteUser(), have the username logged in 
log file, etc...
Comment 5 Craig McClanahan 2001-10-12 08:50:36 UTC
It doesn't matter how useful or non-useful the proposed solution would be when
it violates the Servlet Spec, and applications that depended on it would not be
portable to any other servlet container.

If you don't like the way form based login works, the proper avenue is through
modifying the next version of the spec (which will translate into changes in the
behavior of Tomcat, and all other implementations).

Otherwise, you have the alternative to build authentication and access control
into your application.  Using the new Filter APIs, you have the opportunity to
do this without giving up the use of request.getRemoteUser() and
request.isUserInRole(), because you can wrap the incoming request before passing
it on to the servlet.
Comment 6 T 2001-10-13 04:48:38 UTC
They say that Weblogic server returns the default page in this case. Returning 
the default page doesn't violate the Servlet spec either, because the spec 
doesn't state how to handle this situation? See bug #1861 comments.