I would tend to agree with Jeppe here.
Thanks,
Aaron
On 1/9/06, Jeppe Sommer (Trifork) <[EMAIL PROTECTED]> wrote:
> 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
> >
> >
> >
> >
>
