tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject DO NOT REPLY [Bug 12428] request.getUserPrincipal(): Misinterpretation of specification?
Date Fri, 17 Dec 2010 09:05:17 GMT

--- Comment #26 from Werner Donn <> 2010-12-17 04:05:00 EST ---
There are two issues here. The first is pre-emptive authentication. RFC 2617
section 1.2 is very clear on this:

" A user agent that wishes to authenticate itself with an origin
   server--usually, but not necessarily, after receiving a 401
   (Unauthorized)--MAY do so by including an Authorization header field
   with the request."

And further:

"If the origin server does not wish to accept the credentials sent
   with a request, it SHOULD return a 401 (Unauthorized) response. The
   response MUST include a WWW-Authenticate header field containing at
   least one (possibly new) challenge applicable to the requested

This means the origin server must always deal with this, no matter the
technology being used. The fact that a method is not declared as being
protected doesn't play any role.

The second issue is that according to you the application should not be able to
trigger the challenge-reponse mechanism by setting the status code to 401. Can
you give one piece of evidence in the servlet spec for this? Are there
restrictions in the HttpServletRequest.setStatus() method that say the
application can't use certain status codes? Here is what the servlet spec says
about programmatic security:

"Programmatic security is used by security aware applications when declarative
security alone is not sufficient to express the security model of the

Declarative security is fine, but doesn't prohibit programmatic security and
programmatic security doesn't require declarative security to be present. They
are simply not related. According to you they are. Can you tell me why?

The patch shows how trivial it is to implement this correctly. Would harm be
done if it were implemented? Which spec would be violated in that case?

Your stance makes it impossible to implement WebDAV ACLs (RFC 3744). A user can
change access control for a resource from protected to public. The former
requires authentication prior to access control, while the latter doesn't.

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message