So my expectations contain the only bugs in this instance :) Thanks. I suspected it might be something like that, but I hadn't seen anything about it. Now to work around the issue, we've been rather dependent on how it worked in the past but I believe I understand why it had to change.
Alex -----Original Message----- From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Sent: 29. mai 2012 16:10 To: Tomcat Users List Subject: Re: Tomcat filter behaviour 2012/5/29 Alexander Landsnes Keül <alexander.landsnes.k...@visma.no>: > I'm seeing some behaviour from Tomcat 7 that I'd classify as "funky" when it > comes to servlet filters. First off the technical setup > > JDK 1.7.0_03 (64-bit) > Tomcat 7.0.26 (64-bit) binaries > 4 instances of Tomcat share those binaries, each installed as a pretty > standard windows service using service.bat. Their bin folder contains the > required files, tomcat-juli.jar and a setenv.bat as well as a renamed > tomcat7w.exe for convenience. > > The setup itself works like a charm, I can run webapps on all the above > servers and they all have their own ports for the connector, shutdown and > ajp. I also double checked that no application references catalina.home for > config, they all check catalina.base. > The problem appears when I try to use the Waffle servlet filter to > authenticate a remote user on one of the above instances. I ran it in a few > different scenarios, and the behavior leaves me puzzled. All the scenarios > run with the filter logging turned on, so it appears to behave correctly. > > 1) > I defined the <filter> and <filter-mapping> elements in the (shared) web.xml > for a tomcat instance, with <url-pattern>/*</url-pattern>. I tried having it > both at the very start, and the very end of the file with the exact same > behaviour. The filter would only work correctly on the very root of the > tomcat server, so http://localhost:8180/. Attempting to navigate to any other > context would appear to trigger the Kerberos auth (HTTP headers contained > Authorization: Negotiate & what I believe is a Base64 encoded Kerberos > ticket), but the the remote user retrieved from the servlet would be null. > > 2) > I moved the config from the shared web.xml and over to a specific webapp that > needs the remote user. This works like a charm, more or less as expected. > without SSO. > > 3) > Moving the filter definition, but not the filter-mapping, to the shared > web.xml, and then mapping it in a context specific web.xml also works as > expected. The remote user can be retrieved from the servlet. > > The second setup, having Waffle defined in the context specific web.xml, > won't be an option for us in a production environment. Ideally the same war > file should be deployable to an environment with SSO and also without SSO. It > could be solved by two versions of the web.xml, but it's more of a last > resort. > We've got a similar setup, on an old Tomcat 6.0.26 test instance, where > waffle runs like a charm from the shared web.xml. A major difference here > being that catalina.base & catalina.home refer to the exact same folder. > > Is this behaviour intended? That a filter-mapping in the shared web.xml is > disregarded in the contexts? Or am I seeing a bug of sorts here? I'll admit > to my knowledge of the servlet spec is cursory at best, but this strikes me > as wrong. I've got a virtual server I can fiddle with if anyone has > suggestions as to how I can "fix" this behaviour. > Yes, it is intended behaviour and Tomcat 7 here differs from earlier versions. See explanation here: https://issues.apache.org/bugzilla/show_bug.cgi?id=51754#c1 You may also want to look at https://issues.apache.org/bugzilla/show_bug.cgi?id=52138#c4 Best regards, Konstantin Kolinko --------------------------------------------------------------------- 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
