Larry Isaacs wrote:
> 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.
+1
> Hopefully they would have the sense not to enter a *real*
> password in clear text, but who knows.
I think that might be hoping too much, which is why I agree with your
assessment.
> 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
>>
>>
--
- Christopher
/**
* Pleurez, pleurez, mes yeux, et fondez vous en eau!
* La moitié de ma vie a mis l'autre au tombeau.
* ---Corneille
*/
