On 07/22/09 10:41 AM, Sam Crawford wrote:
> No problem Jan. In our scenario our application is the only thing that
> would ever run on this container, so we've not got any concerns about
> doing it this way.
Great!
BTW, I filed this issue about the missing access-log format element you
discovered:
https://glassfish.dev.java.net/issues/show_bug.cgi?id=8811
Thanks,
Jan
>
> Regards,
>
> Sam
>
>
> 2009/7/22 Jan Luehe <Jan.Luehe_at_sun.com <mailto:Jan.Luehe_at_sun.com>>
>
> 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
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
>