Differences

This shows you the differences between two versions of the page.

--- litespeed_wiki:cache:common:logged-in-cookie-conflicts [2017/02/22 16:25]
Kevin Fwu
+++ litespeed_wiki:cache:common:logged-in-cookie-conflicts [2017/11/17 20:26]
Lisa Clarke [Managing Logged-In Cookie Conflicts]
@@ Line 1: / Line 1: @@
-====== Managing Multiple LSCache Plugins in a single Virtual Host ======
+====== Managing Logged-In Cookie Conflicts ======
+Login Vary Cookie conflicts can pop up when you have multiple web applications with [[litespeed_wiki:cache#litespeed_cache_plugins_by_application|LSCache plugins]] enabled on the same document root, with one app being served from a subdirectory of another (as in ''<nowiki>www.example.com/</nowiki>'' and ''<nowiki>www.example.com/app2/</nowiki>''). This can happen with distinct web applications, or multiple installations of the same app (e.g. two copies of WordPress).
-===== Do I need to do anything? =====
+[[https://blog.litespeedtech.com/2017/06/07/wpw-conflict-free-cookies-and-tags-on-multi-app-sites/|To learn more about this, see our blog post.]]
-This wiki entry is intended for people who have multiple [[litespeed_wiki:cache#litespeed_cache_plugins_by_application|LSCache plugins]] in the same document root. This includes two of the same web application (e.g. two WordPress installs in the same document root). For these situations, some extra steps may be required to correctly cache the web applications. If this does not describe the situation, then there is likely no extra steps involved.
+===== The Problem =====
+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.
-===== Modifying .htaccess Manually =====
+**Example**: Wordpress at ''<nowiki>www.example.com/</nowiki>'' and XenForo at ''<nowiki>www.example.com/forum/</nowiki>''.
-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.
+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 ''<nowiki>www.example.com/</nowiki>''.  Even though the forum is an entirely separate application, to the browser it looks simply like a part of the blog.
-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.
+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.
-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.
+===== The Solution =====
+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.
 <code>
@@ Line 16: / Line 23: @@
 </code>
-“_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.
+''_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:
+For example, in the above scenario, the WordPress ''.htaccess'' file may have something like:
 <code>
@@ Line 29: / Line 36: @@
 </code>
-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.
+==== Modifying within a plugin ====
-===== Modifying within a plugin =====
+For each application, visit the LiteSpeed Cache admin area and modify the **Login Cookie**.
-It is possible to have multiple cache plugins in a single virtual host. However, to avoid any conflicts between them, it is recommended to set a few configuration options available in the plugins.
-==== Tweaking the Login Cookies ====
-By default, the cache will use ''_lscache_vary'' as the login cookie in all the web applications. This causes an issue, because a user could be logged in to one web application and not the other. Once the user visits the non-logged in application, a cache entry will be created for the page with the login cookie. Since both applications recognize the same cookie, logged in users visiting that page will be served from cache. This issue can be resolved by modifying at least one of the web applications.
 === In WordPress ===
-The login cookie can be modified in the WP-Admin panel. The relevant option is in LiteSpeed Cache ->  Settings -> Advanced, as depicted below:
+The login cookie can be modified in the WP-Admin panel. Navigate to **LiteSpeed Cache ->  Settings -> Advanced**, as depicted below:
 {{ :litespeed_wiki:cache:wordpress_login_cookie.png?direct&700 |}}
+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. The setting in XenForo is in the admin panel under Home -> LiteSpeed Cache -> Settings, as depicted below:
+The XenForo plugin will not modify the rewrite rules directly. In the XenForo admin panel, navigate to **Home -> LiteSpeed Cache -> Settings**, as depicted below:
 {{ :litespeed_wiki:cache:xenforo_login_cookie.png?direct&700 |}}
@@ Line 51: / Line 55: @@
 {{ :litespeed_wiki:cache:xenforo_rules.png?direct&700 |}}
-After adding the rules, it can be verified in the LiteSpeed Cache Management screen:
+After adding the rules, it can be verified in the **LiteSpeed Cache Management** screen:
 {{ :litespeed_wiki:cache:xenforo_verify.png?direct&700 |}}
@@ Line 59: / Line 63: @@
 {{ :litespeed_wiki:cache:xenforo_verified.png?direct&700 |}}
-==== Cache Tag Prefix ====
-The Cache Tag Prefix should be used in situations where multiple of the same web application is installed in the same virtual host (e.g. a WordPress in /public_html/shop/ and another WordPress in /public_html/). Using different cache tag prefixes will prevent possibly purging too many pages.
-=== In WordPress ===
-The cache tag prefix can be modified in the WP-Admin panel. The relevant option is in LiteSpeed Cache ->  Settings -> Advanced, as depicted below:
-{{ :litespeed_wiki:cache:wordpress_cache_tag.png?direct&700 |}}
-=== In XenForo ===
-The cache tag prefix can be modified in the Xenforo Admin. The setting in XenForo is in the admin panel under Home -> LiteSpeed Cache -> Settings, as depicted below:
-{{ :litespeed_wiki:cache:xenforo_cache_tag.png?direct&700 |}}