The changes from the Spring security filter can't be seen by the access log valve.
p On 30 Sep 2011, at 12:40, Richard Sayre <richardsa...@gmail.com> wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
