Solved!
I was going to look at modifying GlassFish's access logging mechanism so
that it would support logging custom HttpServletRequest request attributes
(and these can be set without having to wrap the request). When hitting the
source, it seems it already supported it, but just isn't documented.
So now I just set the username as a request attribute (which I was already
doing actually), and then log %attribute.uid% in the access log format.
Thanks,
Sam
2009/7/21 Sam Crawford <samcrawford_at_gmail.com>
> Thanks Jan, much appreciated.
>
> Sam
>
>
> 2009/7/21 Jan Luehe <Jan.Luehe_at_sun.com>
>
> Hi Sam,
>>
>> On 07/20/09 02:30 PM, Sam Crawford wrote:
>>
>> Thanks Jan, much appreciated.
>>
>> The filter runs as a part of a J2EE web application (the first filter in
>> the chain). As you suggest, I imagine that the logging valve is operating on
>> the original unwrapped request.
>>
>>
>> Right! The access logging valve is invoked much earlier than any
>> application filters "downstream",
>> meaning any application-generated request/response wrappers will no longer
>> be in scope when the access logging
>> valve is invoked "upstream" at its "post-processing" logic (which is
>> responsible for writing to the log).
>>
>>
>> Do you know of any other way to achieve what I'm looking to do?
>>
>>
>> Not off the top of my head, but let me think about this some more ...
>>
>> Thanks,
>>
>> Jan
>>
>>
>> I've tried creating a custom JAAS authentication module (which looks
>> promising), but it seems an awful lot of code to achieve something
>> fundamentally very simple. Furthermore, some simple benchmarking after
>> enabling the JAAS module shows a ~20% decrease in requests/sec.
>>
>> Any other suggestions would be very welcome!
>>
>> Thanks,
>>
>> Sam
>>
>>
>> 2009/7/20 Jan Luehe <Jan.Luehe_at_sun.com>
>>
>>> 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>
>>>
>>>> Anyone have any suggestions?
>>>>
>>>> Thanks,
>>>>
>>>> Sam
>>>>
>>>>
>>>> 2009/7/16 Sam Crawford <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
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>