tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Tulley" <>
Subject [Patch] Forwards in FormAuthentication
Date Thu, 15 May 2003 00:05:17 GMT
Remy, is the attached patch what you had in mind?

I really like how this works, and it has the plus of preserving your
form parameters into the login page, so that the login form can choose
to use those parameters if it likes.  Still, it would be best to
automatically pick up and use those form parameters (the known ones,
j_username and j_password).  That will be sent as a separate patch.

With regards to this patch and suitability for commit to Tomcat 4
(read: backwards compatibility), I have a question:  Can the user
specify a form-login-page outside of the web application's context?  If
not, then the only potential problem with the patch is if an app
developer was using a static html page for login.  Now Tomcat will be
serving up the static content, instead of the redirect causing the
browser to request another page that might have been served by a web

Mostly this will work, but there may be slightly different rules for
serving static content between the two.  For instance, does Tomcat work
with internationalized files the same as the Apache web server - IE
looking for, or, when a request comes in for
login.html?   Certainly such pages can be rewritten to handle i18n
issues, but it is a potential backwards-compatible issue.

How important is this type of issue?

Notice that I left the redirect to the actual URL after proper
authentication intact.  That seems to be the best way to do it.  Only
the error page and login pages do a forward.

Jeff Tulley  (
Novell, Inc., The Leading Provider of Net Business Solutions

>>> 5/12/03 1:21:14 PM >>>
Jeff Tulley wrote:
> Actually, I forgot to consider the basic authentication case with
> patch.  It seems easy enough with the second half of my fix, I just
> the same old error message if there is no error page defined.  That
> seems to work.  But, my code:
> Session session = getSession(hrequest);
> session.setPrincipal(null);
> seems to hang the basic authentication process.  Does anybody know of
> better way to clear out the user credentials/principal that would
> with both types of authentication?  I'll keep researching it and
> hopefully submit a better patch soon.

I was about to post an objection about the difference in behavior with

If it can be made to be consistent between auth methods, I would be ok

to consider making the change to Tomcat 5.

Other improvements could be considered for FORM auth (and make it
exactly like BASIC from the user perspective, which is the goal, using

forwards instead of redirects).


To unsubscribe, e-mail: 
For additional commands, e-mail: 

View raw message