[Patch] Forwards in FormAuthentication

[Jeff Tulley <JT...@novell.com>]

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
server.  

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 login.html.de, or login.html.es, 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  (jtulley@novell.com)
(801)861-5322
Novell, Inc., The Leading Provider of Net Business Solutions
http://www.novell.com

>>> remm@apache.org 5/12/03 1:21:14 PM >>>
Jeff Tulley wrote:
> Actually, I forgot to consider the basic authentication case with
that
> patch.  It seems easy enough with the second half of my fix, I just
send
> 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
a
> better way to clear out the user credentials/principal that would
work
> 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

BASIC.
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
behave 
exactly like BASIC from the user perspective, which is the goal, using

forwards instead of redirects).

Remy


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org 
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org 

Re: [Patch] Forwards in FormAuthentication

[Remy Maucherat <re...@apache.org>]

Jeff Tulley wrote:
> 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

No, you have to specify an "aboslute" URI relative to the context root 
(ie, you can use it directly in the RD call).

> 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
> server.  

I supposed it *could* happen. It's way outside the spec, though.

> 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 login.html.de, or login.html.es, 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.

I won't commit this to TC 4.1.x at this time; I'll give it a try in TC 
5, and see how it works.

Remy


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org