Handling Logged-in Cookie Conflicts

When using multiple web applications in a single domain (two of the same application counts as two), there may be some issues where a page is served from cache when it shouldn't be. This is by multiple LSCache plugins all using the same default _lscache_vary cookie to check logged-in status.

A good example of this is a domain with WordPress serving www.example.com/ and XenForo serving www.example.com/forums/. If a user logs into WordPress, the _lscache_vary cookie will be set to indicate that they are logged in. This same user then visits XenForo as a non-logged in user and hits the backend. Since we are a non-logged in user, LSCache caches the request with the logged in _lscache_vary cookie still set. This can then cause future users logged in to XenForo to get a “cache hit” on this page and be served the non-logged in version of the page.

To prevent this, add the following rewrite rule to the .htaccess file under the application’s root directory, after RewriteBase and before all rules using the [L] flag.

RewriteRule .? - [E=Cache-Vary:_my_custom_vary]

“_my_custom_vary” is the cookie name that will now be used by that application. A unique name should be used for each application under the same domain.

For example, in the above scenario, the WordPress .htaccess file may have something like:

RewriteRule .? - [E=Cache-Vary:_my_vary_EXAMPLE_wordpress]

And the XenForo .htaccess file might have:

RewriteRule .? - [E=Cache-Vary:_my_vary_EXAMPLE_xenforo]

This is used to differentiate users logged into WordPress and users logged into XenForo, so the pages that should be served from cache will be correctly served from cache.