-----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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
