I'm still having some trouble. I added the Spring filter and then in my web app I called:
getRequest().getRemoteUser() and getRequest().getUserPrincipal().getName() Both methods returned the logged in user name. (getRequest() returns the HttpServletRequest) However, in the logs %u is still returning '-'. Is there anything else Tomcat needs to have before whatever part of the API gets called for %u will return the remoteUser? Thanks, Rich On Thu, Sep 29, 2011 at 3:32 PM, Richard Sayre <richardsa...@gmail.com> wrote: > Ahh yes I just discovered it when you replied: > > http://static.springsource.org/spring-security/site/docs/3.0.x/apidocs/org/springframework/security/web/servletapi/SecurityContextHolderAwareRequestFilter.html > > Thanks > > Rich > > On Thu, Sep 29, 2011 at 3:19 PM, Christopher Schultz > <ch...@christopherschultz.net> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Rich, >> >> On 9/29/2011 12:18 PM, Richard Sayre wrote: >>> Thanks, I'm trying to log the user name. I am not using Tomcat >>> for authentication and I need that info in my access logs. >> >> So, that means that %u isn't an option, then? :( >> >>> Perhaps I will create a new attribute to hold that value rather >>> than accessing the object I have in session and calling toString. >> >> You have a couple of options, here: >> >> 1. Write a Filter that wraps HttpServletRequest and overrides >> the getRemoteUser to return userObject.getUserId. Then, use >> "%u" in your access log pattern. >> 2. Write a Filter that checks the session for "userObject" and no >> "userId", and sets "userId" as appropriate. >> 3. Modify your login process to set both "userObject" and, say, >> "userId" in the session. >> >> I would say those are in order of easiest-to-hardest. >> >>> On that note if I know the username, is it possible to somehow >>> inject it so that Tomcat logs it using the %u pattern. >> >> Yup, see above. >> >>> Previously we used Tomcats built in authentication but we recently >>> switched to Spring Security. If I could still use %u, then I >>> could use the 'common' pattern and in turn use >>> FastCommonAccessLogValve. If not I will use the HTTP Session. >> >> Hmm.... I'm surprised that Spring Security doesn't better integrate >> with the container in order to provide ServletRequest.getPrincipal and >> ServletRequest.getRemoteUser. I wonder if there is a Filter that >> already exists in Spring Security that would do what I suggested in #1. >> >> - -chris >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.10 (MingW32) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iEYEARECAAYFAk6Er6AACgkQ9CaO5/Lv0PB+FACgqb6s6BSBcoiMf4Ka1+awxArC >> UHoAnR0LSUHNGRnuyHSpvW7vEYONDJuK >> =NFZ/ >> -----END PGP SIGNATURE----- >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
