On 07/22/09 06:01 AM, Sam Crawford wrote:
> 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.
Great work, Sam!
Thanks for pointing out that "%attribute.<name>%" is not documented as a
supported access-log format element. Neither is "%cookie.<name>%", as I
just found out. "%header.<name>%" is documented, though.
I'll file a bug against docs.
I like your solution, but you would probably want to prevent user code
from setting this particular attribute in the request. You would
probably want to initialize this attribute at the time when you create
your request wrapper, and have your wrapper override setAttribute to
check for the attribute name and throw an exception if it matches "uid".
Thanks,
Jan
>
> Thanks,
>
> Sam
>
>
> 2009/7/21 Sam Crawford <samcrawford_at_gmail.com
> <mailto:samcrawford_at_gmail.com>>
>
> Thanks Jan, much appreciated.
>
> Sam
>
>
> 2009/7/21 Jan Luehe <Jan.Luehe_at_sun.com <mailto: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
>> <mailto: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
>>> <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
>>>
>>>
>>>
>>
>>
>
>
>