There was a copy-paste artifact on my first mail that made no sense at the end of 2). Otherwise this is identical to my previous mail.
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 the remote user can be retrieved from the servlet. 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. Alex --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
