This is an old revision of the document!


Managing Logged-In Cookie Conflicts

Login Vary Cookie conflicts can pop up when you have multiple web applications with LSCache plugins enabled on the same document root, with one app being served from a subdirectory of another (as in www.example.com/ and www.example.com/app2/). This can happen with distinct web applications, or multiple installations of the same app (e.g. two copies of WordPress).

Of particular concern is the _lscache_vary cookie, which is the default in every LSCache plugin, and indicates the logged-in status of a user. As such, it is in control of what version of a page (logged in or not logged in) is served.

Example: Wordpress at www.example.com/ and XenForo at www.example.com/forum/.

As far as the browser is concerned, both the blog and the forum are the same website because the forum is actually a subdirectory of the blog. When the browser visits either one of those addresses, it will use the cookies for www.example.com/. Even though the forum is an entirely separate application, to the browser it looks simply like a part of the blog.

Here's how this situation presents itself: A user logs into WordPress, and the _lscache_vary cookie is set to indicate that they are logged in. This same user then visits XenForo as a non-logged-in user and hits the backend. LSCache caches the non-logged-in request, but the logged-in _lscache_vary cookie is still set. This causes 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.

In our example, to differentiate users logged into WordPress from users logged into XenForo, you need to change the names of the login vary cookies. Each application under the same root needs a uniquely-named cookie. You can manually modify .htaccess to address this issue, or you can go through the plugin interfaces.

Modifying .htaccess Manually

For each application, 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.

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]

Modifying within a plugin

For each application, visit the LiteSpeed Cache admin area and modify the Login Cookie.

In WordPress

The login cookie can be modified in the WP-Admin panel. Navigate to LiteSpeed Cache → Settings → Advanced, as depicted below:

Changing the cookie name here will also change it in the rewrite rules.

In XenForo

The XenForo plugin will not modify the rewrite rules directly. In the XenForo admin panel, navigate to Home → LiteSpeed Cache → Settings, as depicted below:

After saving, a notification will appear. The notification will instruct you further on what to add to the rewrite rules, like so:

After adding the rules, it can be verified in the LiteSpeed Cache Management screen:

If the changes are correct, it will output the following:

  • Admin
  • Last modified: 2017/10/18 19:57
  • by Lisa Clarke