My preferred behavior would be to return the login Principal of the
user even for unauthenticated pages (unless they've logged out or
timed out, of course). As a side effect, I think this would let us
drop the required defualt principal from the security mapping, which
would be great. Unfortunately, I can't justify this by spec
references. :)
Thanks,
Aaron
On 1/8/06, Greg Wilkins <[EMAIL PROTECTED]> wrote:
>
> David,
>
> I do not believe that the servlet spec well defines the behaviour of the
> getUserPrincipal() method for un-secured resources.
>
> I raised this with the EG during the 2.4 process and pointed out that
> several containers implemented this differently. Specifically I wanted
> to know that if getUserPrincipal() is called for a un-securied resource
> would the return be:
>
> 1) Null
>
> 2) The principal associated with the request (by session or otherwise)
> that was authenticated by a previous request, but not reauthenticated
> for this
> request. The actual authentication of the principal may have expired or
> been revoked.
>
> 3) The principal associated with the request (by session or otherwise)
> that is re-authenticated with the realm for this request.
>
>
> I don't believe anything in SRV 12 or the javadoc makes it clear which of
> these
> is the correct choice (not even 12.7 as Jeppe suggests, as it is not defined
> what the "security identity of a web user" is for a non secured resource.
>
> Note that as some authentication mechanism (eg BASIC) have paths associated
> with them by the browser, it is possible to have different credentials for
> different paths within the same web application. For example, if a user
> first authenticates at /context/auth/something, then the browser will only
> present credentials for /context/auth/* and the user will not be known for
> /context/other/something or in fact, different credentials may be request
> and provided by the browser! So for some mechanisms, there is not
> even a concept of context wide authentication.
>
> At the time I raised the issue with the EG I was not able to get a clear
> resolution (wonders of the JCP). I think I suggested having an explicit
> lazy authentication ie specify that a request should be authenticated
> with the realm IFF credentials are available in the session or request
> and additional user interaction is not required. I'll have to dig
> up my mail archives to see the reasons against this.
>
> For now, I beleive that most containers implement lazy authentication
> for non-secured requests at the time that getUserPrincipal is called.
> So any credentials present in the session and/or request will be
> rechecked with the realm. Thus option 3) above is the defacto status.
> But what credentials are available depends greatly on the auth
> mechanism used.
>
> It also does mean that you must be careful with any filters or
> interceptors that call getUserPrincipal, as that call may have
> the side affect of triggering a possible expensive and remote
> call to an authentication mechanism. Don't call it unless
> you really need it!
>
> cheers
>
>
>
>
>
>
>
>
>
>
