RE: cvs commit: jakarta-tomcat/proposals/catalina/src/share/org/a pache/tomcat/session StandardSession.java

[Paul Lamb <pa...@oil-law.com>]

>   Provide a place for an Authenticator to stash the 
> authenticated Principal
>   (returned from the corresponding Realm) that is associated with this
>   request.  Authenticators that take advantage of this can 
> optimize their
>   performance by avoiding potentially expensive 
> Realm.authenticate() calls
>   on every single request.
>   

Should getUserPrincipal() also first check for the Principal in the session
first before returning null or creating the SimplePrincipal?


Paul Lamb

Re: cvs commit: jakarta-tomcat/proposals/catalina/src/share/org/apache/tomcat/session StandardSession.java

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Paul Lamb wrote:

> >   Provide a place for an Authenticator to stash the
> > authenticated Principal
> >   (returned from the corresponding Realm) that is associated with this
> >   request.  Authenticators that take advantage of this can
> > optimize their
> >   performance by avoiding potentially expensive
> > Realm.authenticate() calls
> >   on every single request.
> >
>
> Should getUserPrincipal() also first check for the Principal in the session
> first before returning null or creating the SimplePrincipal?
>

The way I actually implemented it was that the authenticator itself makes this
decision (before the request ever gets to the servlet where it can call
getUserPrincipal()).  The request object itself has no clue that any of this
magic is going on behind the scenes -- all it knows is that some Tomcat
component either did, or did not, call setUserPrincipal() to provide a value to
be returned by getUserPrincipal().

This update was implemented on a subsequent check-in last night for the BASIC
and DIGEST authenticators.

>
> Paul Lamb
>

Craig McClanahan