You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2005/09/21 23:49:45 UTC
DO NOT REPLY [Bug 12428] -
request.getUserPrincipal(): Misinterpretation of specification?
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=12428>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=12428
markt@apache.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution| |INVALID
------- Additional Comments From markt@apache.org 2005-09-21 23:49 -------
The underlying issue here is how BASIC authentication works. With BASIC
authentication, the user is required to authenticate with every request and the
browser helpfully caches the user name and password and re-uses them with
subsequent requests.
The spec requires that authentication only takes place if a resource is
protected. Therefore, for an unprotected resource no BASIC authentication takes
place even if the browser sends the credentials. In turn, this means that
getUserPrincipal() will return null since the user has not been authenticated.
One work-around is to use FORM authentication. In this scheme, the user is
authenticated once and the Principal added to the session. This authenticated
Principal remains available whilst the session is valid regardless of whether an
individual request requires authentication.
I have considered modifying the BASIC authentication implementation so a user is
always authenticated if the present credentials but:
- this would violate the spec
- the behaviour if the authentication fails is undefined (because the spec
obviously doesn't define behaviour that violates the spec)
Therefore I am going to resolve this as INVALID since any other behaviour is a
spec violation.
As a final comment I do not like that this means that application behaviour
varies with the authentication scheme specified in web.xml but this is a direct
side-effect of the differences in per-request and per-session authentication.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org