tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Landsnes Keül <>
Subject RE: Tomcat filter behaviour
Date Tue, 29 May 2012 14:58:58 GMT
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.


-----Original Message-----
From: Konstantin Kolinko [] 
Sent: 29. mai 2012 16:10
To: Tomcat Users List
Subject: Re: Tomcat filter behaviour

2012/5/29 Alexander Landsnes Keül <>:
> 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:

You may also want to look at

Best regards,
Konstantin Kolinko

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message