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:[EMAIL PROTECTED]]
> Sent: Wednesday, September 12, 2001 11:54 AM
> To: '[EMAIL PROTECTED]'
> 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
>
