Allow Nonce caching

[raamdev]

As of v160706, Comet Cache does not cache Nonce values (see What are WordPress nonces and why are they not cache-compatible?). However, after further discussion it was decided that Nonces could be cached safely, with a few caveats (see Caching Nonce values safely below). The decision to put in the work necessary to make caching Nonces possible came after lots of feedback from users frustrated that Comet Cache was not caching their pages due to a plugin/theme adding Nonce values to every page.

To improve the way Comet Cache handles WordPress Nonces, we need to do the following:

• Allow caching of Nonce values by default for Logged-In Users when Logged-In Users caching is enabled; a new option should be added to the Logged-In Users option panel to enable/disable this functionality if desired. Caching will remain disabled for users who are not logged in (as it is now).
• When Nonces are cached, the cache files that contain Nonces get an expiration time of 12 hours (other cache files get whatever expiration date is set in the Options). A new filter should not be added that allows a site owner to override this 12-hour cache file expiration, because as Jason put it, "anyone changing this will be going down the wrong path, without question [...] Exposing the filter suggests it's OK to do it, when it's not."
• A note should be added to the Comet Cache notes for that cache file indicating that a Nonce value was detected and hence the cache expiration time has been set to 12 hours (or whatever overridden value was set using the filter). A note is not necessary if the global expiration time was manually set to 12 hours or less.

---

Caching Nonce values safely

From what I've gathered, the only real way to cache Nonce values safely is to do the following:

1. Ensure that the cache file is being served to a user for whom the Nonce value was created (which means only Logged-In User caching in the context of Comet Cache). The only way Comet Cache can know that the cache file being served belongs to the visitor it's being served to is via Logged-In User caching.
2. Ensure that the user-specific cache files that contain Nonce values are not publicly accessible, otherwise attackers could find Nonce values in the cache files and attempt to exploit them. We need to take into consideration sites running Nginx (where .htaccess rules are not possible) and sites where we may be unable to write an .htaccess file to protect files in the cache from being publicly accessible. We may not need to worry about this; see more on this below.
3. Ensure the cache file that contains a Nonce value does not stay around for longer than the minimum lifetime of a WordPress Nonce, which is 12 hours. If it stays around for longer than 12 hours, then the user who loads the cache file will find themselves clicking buttons and submitting forms that result in an error due to the expired Nonce value.

Points 1 and 3 we can control: We can only Nonce caching only for Logged-In Users and we can set an expiration date on cache files that contain Nonce values to 12 hours. Point 2 is somewhat out of our control, however that may not be a problem.

@jaswsinc writes...

if we do decide to take this approach, we should be more and more careful about how secure the cache directory is. That's already something we consider, but when we knowingly cache a user-specific security token (e.g., Nonce) we must also assume responsibility for protecting it every way that we can; i.e., take some additional precautions.

The WordPress Codex says to "always assume Nonces can be compromised" and that "Nonces should never be relied on for authentication or authorization, access control." If we go by that, then we don't need to worry about making sure that cache files are not publicly accessible just because they may contain a Nonce value. (I agree, however, that we should still try to make sure user-specific cache files are not publicly accessible, as those will probably contain user-specific information that a site owner would not want to expose.)

[uhlhosting]

So are there any concrete steps I can follow to try to test this? And when would this be implemented in a Beta release or a stable version.

[raamdev]

@Highacid Yes, you can implement this by following the steps outlined in What are WordPress nonces and why are they not cache-compatible? in the section for Allowing Nonce Caching and Logged-In Users (safer), and by setting Comet Cache → Plugin Options → Directory / Expiration Time to 12 hours.

[jaswrks]

Next Release Changelog:

• Nonce Support: In the pro version, when logged-in user caching is enabled, Comet Cache is now capable of intelligently caching pages that contain Nonce values (numbers used once). This allows for pages containing the WordPress Admin Bar to be cached without issue. It also improves compatibility with plugins like bbPress and BuddyPress, resulting in better performance and faster speeds for logged-in users. See also: issue #793 if you'd like additional details.

[uhlhosting]

When will this be available to public?

[raamdev]

@Highacid We should have a Release Candidate available this weekend that will include these changes. Our target date for a General Availability release is Friday, November 18th.

If you're interested in testing a beta release of Comet Cache before the next version comes out, please sign-up to be a beta tester here or see Comet Cache → Plugin Updater → Beta Testers to automatically receive Release Candidate updates.

[uhlhosting]

@raamdev Thanks, I am already subscribed.

[renzms]

@raamdev

Confirmed Working

Comet Cache now intelligently caches pages/posts with Nonce Values present.

[raamdev]

Comet Cache v161119 has been released and includes changes from this GitHub Issue. See the v161119 announcement for further details.

---

This issue will now be locked to further updates. If you have something to add related to this GitHub Issue, please open a new GitHub Issue and reference this one (#793).