DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22617>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22617 BASIC authentication fails if Realm supports default user Summary: BASIC authentication fails if Realm supports default user Product: Tomcat 4 Version: 4.1.24 Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] If I use BASIC authentication, tomcat obviously tries to authenticate an initial request against the security provider although the request does not include the "Authorization: ..." header yet! I have not tracked what credentials are used but the assumption in the tomcat implementation seems to be that trying authorization with the used "default credentials" should fail anyway, causing tomcat to then send the 401 reply and the browser to display the login dialog. Although I have to admit that I could not find something specific in the specifications, I think this behaviour is a bug. Tomcat should query the security provider only if it has received the "Authorization: ..." header as part of the request. Any request of a resource secured with BASIC authentication that lacks this header should result in an immediate 401 response, i.e. without consulting the security provider. Why is this important? Well, especially in a J2EE environment a security realm may support something like an "unauthenticated identity" used for anonymous access of certain resources (but not the servlet in question). The current behaviour of tomcat has the effect that there is an authorization request without credentials and the user is (without ever being prompted by the browser) identified as the anonymous user. As tomcat thinks identification has been successfully performed, it does not repond with a 401 but rather continues processing with the unauthenticated identity. This identity may (usually does) lack a lot of the rights that an authenticated user has and thus the user receives a 403. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
