tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Vávra <>
Subject Re: Form Authentication and Cache-Control
Date Thu, 27 Jun 2013 14:37:43 GMT

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).

Ok. I thought it controls browser caching.
>> 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
> used.
> "
> Tomcat can't tell which resources are "okay" to allow the browser to
> cache and which aren't.
Why we cannot tell tomcat what resources are okay?
I was playing with Expiration Filter for /common/* but with no effect.

> 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.

One way that I have in mind is to make second tomcat application 
/myapp-static that contains static images etc. And link all images to 
this context. But this is ugly.

> Is there actually a /problem/ with having Cache-Control:private set on
> your resources? Have you tried playing with the
> "securePagesWithPragma" setting?
The problem is only the effectivity of network traffic. For one page 
load the browser asks for each image, ccs all the time ( after click, 
not Ctrl+R for refresh).
Why Tomcat is also responding header Expires: Thu, 01 Jan 1970 00:00:00 

I think all this behaviour is somehow connected to form based auth. I 
must prove it by more tests.

>> =========== 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?

I have /* allowed for admin and user roles. There are only login, 
logout, j_sercurity_check pages. And after succ. login user is 
redirected to his context (/user or /admin).
/admin/* is only for admin and /user/* only for user role.
And also I do not want to allow for admin accessing the /user/* pages 
and vice versa.

I do not have /* twice or I don't fully understand  you.


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

View raw message