tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Form Authentication and Cache-Control
Date Wed, 26 Jun 2013 14:08:41 GMT
Hash: SHA256


On 6/26/13 7:36 AM, Jan Vávra wrote:
> If I use auth-method FORM, all requests return with headers
> denying caching on the browser side although I have excluded some
> part of my app from authentication.
> The headers for a png image are:
> HTTP/1.1 304 Not Modified Server: Apache-Coyote/1.1 Cache-Control:
> private

Note that Cache-Control:private does not disable caching. Instead, it
disables public-caching for proxies. The browser is still free to
cache the document in certain ways.

True disabling of the cache would be to set Cache-Control to
"no-cache" or "no-store" (though no-store is usually more appropriate
for controlling proxies and not browsers).

> If I add disableProxyCaching="false" to <Valve 
> className="org.apache.catalina.authenticator.FormAuthenticator" 
> characterEncoding="utf-8"/> at my context.xml the response headers 
> change to:
> HTTP/1.1 304 Not Modified Server: Apache-Coyote/1.1 ETag:
> W/"3907-1372233712661" Date: Wed, 26 Jun 2013 11:25:23 GMT and
> browser in the next request doesn't asks for this image.
> Is it safe to override default bahaviour via disableProxyCaching? 
> Or I am something missing? Or there is a best practice to place
> images, css styles into another application?

What happens with dynamic resources?

The reason that cache-disabling is on by default is that having
proxies and/or browsers caching resources that were protected by
authentication is a potential security or privacy problem. From the
documentation for "disableProxyCaching":

Controls the caching of pages that are protected by security
constraints. Setting this to false may help work around caching issues
in some browsers but will also cause secured pages to be cached by
proxies which will almost certainly be a security issue.
securePagesWithPragma offers an alternative, secure, workaround for
browser caching issues. If not set, the default value of true will be

Tomcat can't tell which resources are "okay" to allow the browser to
cache and which aren't. IMO, you might want to think about using a
fronting web server to serve your static content (which will not
include any headers that would otherwise be sent by Tomcat) and map
all dynamic requests to Tomcat. There are certainly other ways to get
this done as well, but you may find that configuring your way around
this "problem" is more difficult than you imagined.

Is there actually a /problem/ with having Cache-Control:private set on
your resources? Have you tried playing with the
"securePagesWithPragma" setting?

> =========== My aps has these part /*          - common
> authenticated content /user/* - content for user /admin/* - content
> for admin /common/* - common unauthenticated static content like
> images, css, etc
> My web.xml
> <security-constraint> <web-resource-collection> 
> <web-resource-name>MyApp</web-resource-name> 
> <url-pattern>/*</url-pattern> </web-resource-collection> 
> <auth-constraint> <role-name>myapp-admin-role</role-name> 
> <role-name>myapp-user-role</role-name> </auth-constraint> 
> </security-constraint>

Technically, the above web-resource-collection is protected, which
includes everything on your site.

Instead of blanketing the whole site with what amounts to a black-list
and then white-listing other resources, why not do the reverse and
only use a white-list? That will avoid "protecting" resources that
need not be protected.

> <security-constraint> <web-resource-collection> 
> <web-resource-name>MyApp</web-resource-name> 
> <url-pattern>/admin/*</url-pattern> </web-resource-collection> 
> <auth-constraint> <role-name>myapp-admin-role</role-name> 
> </auth-constraint> </security-constraint>
> <security-constraint> <web-resource-collection> 
> <web-resource-name>MyApp</web-resource-name> 
> <url-pattern>/user/*</url-pattern>

Umm... you have the same url-pattern (/*) in two separate
web-resource-collections. Is that intentional?

- -chris
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


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

View raw message