At the end of the method we have: requestURI = savedRequestURL(session); if (debug >= 1) log("Redirecting to original '" + requestURI + "'"); hres.sendRedirect(hres.encodeRedirectURL(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: http://myserver:8080/login/login.jsp 2.Authenticate correctly and then the servers redirects you to: http://myserver:8080/null 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 = ""; hres.sendRedirect(hres.encodeRedirectURL(requestURI)); return (false); I've not tested this patch but it should work;
Same issue as 3839. *** This bug has been marked as a duplicate of 3839 ***
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.
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).
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: <servlet> <servlet-name> NullRedirector </servlet-name> <servlet-class> package.NullRedirector </servlet-class> </servlet> <servlet-mapping> <servlet-name> NullRedirector </servlet-name> <url-pattern> /login/null </url-pattern> </servlet-mapping> 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...
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.
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.