Sam,
On 07/20/09 02:29 AM, Sam Crawford wrote:
> If this is the wrong mailing list, please can someone point me in the
> right direction?
>
> Thanks,
>
> Sam
>
>
> 2009/7/17 Sam Crawford <samcrawford_at_gmail.com
> <mailto:samcrawford_at_gmail.com>>
>
> Anyone have any suggestions?
>
> Thanks,
>
> Sam
>
>
> 2009/7/16 Sam Crawford <samcrawford_at_gmail.com
> <mailto:samcrawford_at_gmail.com>>
>
> Morning all,
>
> Probably a fairly silly question, but I've googled and can't
> find the answer, so I'll ask here.
>
> We've written a custom authentication server filter that
> interacts with an SSO server. Now, we want to log the
> authenticated username as a part of the log line in the
> GlassFish access log. I had imagined this would be simply a
> case of wrapping the request in an HttpServletRequestWrapper
> and overriding getRemoteUser and getUserPrincipal. However,
> after doing this, the username recorded in the access log is
> still NULL-AUTH-USER.
>
> Does anyone know how to properly assert an identity such that
> it is logged properly by GlassFish into the access log?
>
Where in the request processing do you inject your "custom
authentication server filter"?
Note that access logging is implemented as a valve at the virtual-server
level. The
access logging valve logs the result of
HttpServletRequest#getRemoteUser, which in turn
returns the name of the principal (if any) returned by
HttpServletRequest#getUserPrincipal.
It looks like the access-logging valve is still operating on the
original, "unwrapped"
request/response objects, which would explain why NULL-AUTH-USER is
being logged.
Jan
>
> Thanks,
>
> Sam
>
>
>