tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Larry Isaacs <Larry.Isa...@sas.com>
Subject RE: Remaining Tomcat 3.3 Issues
Date Wed, 12 Sep 2001 17:19:40 GMT
I would like to have the "tomcatAuthentication" hack
available in Ajp13 so this behavior is fully controllable.

Also, I'm also leaning toward having a default of "true".
To get the "security" example working when using Apache,
or other web server, users would have to discover the user
names and passwords provided by default.  I prefer this
over requiring they add their own user name(s) and roles.
Hopefully they would have the sense not to enter a *real*
password in clear text, but who knows.

Larry


> -----Original Message-----
> From: Ignacio J. Ortega [mailto:nacho@siapi.es]
> Sent: Wednesday, September 12, 2001 11:54 AM
> To: 'tomcat-dev@jakarta.apache.org'
> Subject: RE: Remaining Tomcat 3.3 Issues
> 
> 
> > 4. Address user authentication via Ajp12 and Ajp13.  Ajp12 
> > has a test for
> > isTomcatAuthentication() to see if req.setRemoteUser() should 
> > be called.
> > I think Ajp13 doesn't have this yet and probably should.  
> Also, if the
> > user is anonymous, i.e. user = "", should we call 
> req.setRemoteUser()
> > with this value?  This prevents Tomcat's normal 
> > authentication from being
> > triggered.
> > 
> 
> 
> I have this code prepared for commit, implementing the
> tomcatAuthentication hack in ajp13.
> 
> But i've planned to change the hack only testing the received 
> string for
> emptyness and not calling setRemoteUser in the case, i think this will
> render the tomcatAuthentication hack useless... 
> 
> But perhaps the better is as you say, honor IsTomcatAuthentication and
> not calling setRemoteUser for the empty string case.. 
> 
> But i cannot think of a usecase in which were needed to 
> obviate an auth
> done in HTTP Server and honor another done in the Servlet container..
> 
> 
> Saludos ,
> Ignacio J. Ortega
> 

Mime
View raw message