Checkout Spurious Warnings Making me nervous going Live.

sw!tch wrote: ↑

Sun May 17, 2020 4:54 pm

It's typically due to lack of proper headers being returned from the server.

If there is a lack of cache control headers being return from the server some browsers will basically guess the type of caching behavior to be given to the content.. Check with your web host and ensure your Apache config is setup proper per your requirements.

sw!tch wrote: ↑

Sun May 17, 2020 4:54 pm

It's typically due to lack of proper headers being returned from the server.

If there is a lack of cache control headers being return from the server some browsers will basically guess the type of caching behavior to be given to the content.. Check with your web host and ensure your Apache config is setup proper per your requirements.

PHP scripts often generate dynamic content that must not be cached by the client browser or any proxy caches between the server and the client browser. Many proxies and clients can be forced to disable caching with:

Additionally, session_cache_limiter() and the session.cache_limiter configuration setting can be used to automatically generate the correct caching-related headers when sessions are being used.

header("Expires: Fri, 01 Jan 2010 05:00:00 GMT");
if(strstr($_SERVER["HTTP_USER_AGENT"],"MSIE")==false) {
  header("Cache-Control: no-cache");
  header("Pragma: no-cache");
}

ADD Creative wrote: ↑

Mon May 18, 2020 2:58 am

Thanks for looking at this again. You are correct. OpenCart 3 does not use the session.cache_limiter setting because it does not the use built in PHP session_start() anymore (version 2 and 1.5 did). That's is why you need to to set the cache control headers manually in ecch PHP generated response. This is what I originally posted in the GitHub issue 18 months ago. https://github.com/opencart/opencart/issues/7008

One thing to point out with your example. You don't need to test for "MSIE". I see you have taken that example from a post form 9 years ago. That was a workaround for Internet Explorer 6 to 8 and only when serving files for download. See https://support.microsoft.com/en-gb/hel ... he-cache-c

Also OpenCart already handels that if serving a download. See (and note that PHP header() will replace the previously set headers so there would be no duplicates).
https://github.com/opencart/opencart/bl ... #L123-L128

Since Internet Explorer 6 to 8 are no longer supported by OpenCart or Microsoft. Best to stick with the following and ensure compatibility with the current supported versions of Internet Explorer and other browsers.

Code: Select all

$response->addHeader('Expires: Thu, 19 Nov 1981 08:52:00 GMT');
$response->addHeader('Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0');
$response->addHeader('Pragma: no-cache');

ADD Creative wrote: ↑

Mon May 18, 2020 3:15 am

The Example 2 is just that, an example. My solution is based on the default setting for session.cache_limiter. Which is the headers PHP actually would set if native sessions were used (i.e. these are the headers that OpenCart 2 and 1.5 set).

https://www.php.net/manual/en/function. ... imiter.php

Additionally, session_cache_limiter() and the session.cache_limiter configuration setting can be used to automatically generate the correct caching-related headers when sessions are being used.

ADD Creative wrote: ↑

Mon May 18, 2020 3:26 am

Yes it does.

Additionally, session_cache_limiter() and the session.cache_limiter configuration setting can be used to automatically generate the correct caching-related headers when sessions are being used.

It's basically saying set your own cache control header if not using native PHP sessions.

ADD Creative wrote: ↑

Sun May 17, 2020 10:26 pm

The web server will never know if a particular output from a PHP script is cacheable or not.

There is an explanation in the PHP manual in the Example #2 Caching directives section here.
https://www.php.net/manual/en/function. ... ample-5705

Probably the best permanent solution is here.
viewtopic.php?f=202&t=206449#p786660

Note: Pragma is not specified for HTTP responses and is therefore not a reliable replacement for the general HTTP/1.1 Cache-Control header, although it does behave the same as Cache-Control: no-cache, if the Cache-Control header field is omitted in a request. Use Pragma only for backwards compatibility with HTTP/1.0 clients.

sw!tch wrote: ↑

Mon May 18, 2020 3:34 am

I agree with @ADD Creative on this. The application should be responsible for providing some default cache headers, as not everyone has access to mod headers or defaults in place via the server.

I would suggest a look into the OWASP recommendations.

Even after the session has been closed, it might be possible to access the private or sensitive data exchanged within the session through the web browser cache. Therefore, web applications must use restrictive cache directives for all the web traffic exchanged through HTTP and HTTPS, such as the Cache-Control and Pragma HTTP headers, and/or equivalent META tags on all or (at least) sensitive web pages.