tomcat-users mailing list archives

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

Jan,

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

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJRyvXoAAoJEBzwKT+lPKRYzUQP/i6zg6UOJbnTUujxHGMGAQSQ
2iQTUMwtBi9mBgmA68EidFFvH48hbD18sZ2GB0A9+JrySy3R2nPC5VphTe2oQ9f8
KY3mVeKeElxTJD03MsufpqcAJQMaffcs9bOEWjzeKmYccZ/ww0UkbIN64oVOcMn5
VJOcm4sqWkLxV4EDAfV3G1DaSkpkhqH3rM3F0FRM1T8eu/TIrVtMdww+BEqzFDr/
wc5qxdjGzWfpctw2J50pk5HV6CmmgFKC1CDe4KS69vQRx6rcQ7HYiERc0NrS2Q2d
8G2KIssa6f210LeVIi5Brp6BK69hkgIPX5OP2ymplCrXLPAIJYgtmiy1RdjP2O3o
JCibXKw9VEl+GuvnPR52/6DOTLrzzaSaC1dBqNUADYocywwmwfNQHSJvInlSRqef
77vWTkSs0q+tNCHlg+abfjkh9SsKyyzPxa1hyU7G24bInWWqpNEauM66VUPBdIfq
yijA1BovLBgbD0vp4Vw9KmtQwkXys5kCQkwjzChCzWdsCDA5NqTCIz65/Ma1i3K8
pWaBC9l8xHvAMT1G/x0iOqHed2uOJi0Vg1NWmPbnL2aze8BTTMBipQgQAVt9w8/D
38oqEvMwStcbEvH16M0TfzrRB3poAUOlFv3F3Phmb/ERgxPrH156fGa2lOir/8hU
epBzsQzMy59rHrcVZe1a
=PwLe
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message