I'd like to verify something I think I'm seeing in Tomcat 7.x.
Back in Tomcat 6.x and previous, to get around an IE bug with the Pragma
header, we would set up an Authenticator valve with securePagesWithPragma set
to false. It didn't really matter which Authenticator valve, just having it
there would do the job.
This was necessary because the SSL connector would set the headers as
Pragma: No-cache
Cache-Control: no-cache
but adding the valve would drop the Pragma header and change the Cache-Control
to "private".
(Not sure it matters, but all this is using native libs on Windows.)
Empirical testing seems to show that at 7.x (7.0.42 at least), the default mode
for SSL is to only set the Cache-Control to "private". It does not add the
Pragma header, and therefore there should be no need for the Authenticator
valve. (note that all authentication is internal to the application and
everything is run over SSL)
Am I interpreting all that correctly?
If I wanted to add a section that did use Tomcat Auth, would I need/want to add
the appropriate Authenticator valve back to the context.xml?
For example: Adding javamelody but limited to users from the users.xml file.
I would add the following to the web.xml:
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>Monitoring</realm-name>
</login-config>
<security-role>
<role-name>monitoring</role-name>
</security-role>
<security-constraint>
<web-resource-collection>
<web-resource-name>Monitoring</web-resource-name>
<url-pattern>/monitoring</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>monitoring</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
Is the BasicAuthenticator valve necessary, and what would it do for me?
Further notes on why I'm testing this:
Our old pre-7 setup used SSLAuthenticator, even though we didn't use client
certs just to get the Pragma header dropped. But adding the above config for
javamelody had Tomcat refusing the connection to /monitoring because we didn't
have client certs. We would get a SSL error page.
Jeffrey Janner
Sr. Network Administrator
jeffrey.jan...@polydyne.com<mailto:first.l...@polydyne.com>
PolyDyne Software Inc.
Main: 512.343.9100
Direct: 512.583.8930
[cid:image002.png@01CC0FB7.4FF43CE0]
Speed, Intelligence & Savings in Sourcing
