Greg,
I agree that there is an amount of implementation freedom wrt. when
getUserPrincipal can be expected to return non-null depending on the
caching strategy of the container, at least when using basic login.
However, with form based login (which, in my experience, is by far the
most commonly used J2EE username/password authentification mechanism),
it is reasonable to assume that the user principal is cached in session
state. For the record, the Trifork server caches user credentials with
both basic and form based login.
And although it is a valid implementation choice to reauthenticate
repeatedly, I don't think that it is commonly expected that a user is
immediatly kicked out of live login sessions if the sysadm changes the
password (talking IT systems in general).
Cheers, Jeppe
Greg Wilkins wrote:
Jeppe Sommer wrote:
I think that it is possible to read from the servlet spec that
getUserPrincipal should return the current principal for an unprotected
resource. Take the following quote (servlet 2.4, section 12.10):
Jeppe,
The problem is that "current" is just not defined and it is totally
implementation dependant. For FORM authentication, the current user is
defined by the session. For BASIC authentication, the current user is
defined by the browser invocation and and path. For CERT the current
user is defined by connection and authentication credentials can be
available before a protected resource has been accessed.
To answer the original question - getUserPrincipal MAY return
a principal for unprotected resource, but it is undefined when
that is.
So any application that expects unprotected resources to have a
non-null principal is going to have problems if the authentication
mechanism is changed. The boundaries simply cannot be defined
as "user previously accessed a protected resource".
If the credentials are available in the request, session or connection,
then they really should be checked before a principal is returned.
The reason for this is that credit expires, permissions are
revoked and bad users can have their accounts cancelled. Also it is
possible that the credentials are present, but have never been checked
within the current "session".
So credentials must be (re)checked at some point, again the spec does not
tell us when and the natural boundaries are very much implementation
dependant (request, connection, session, etc.). Thus Jetty checks the
credentials whenever a request passes a declaritive authentication point
or whenever a programatic authentication API is called.
cheers
