Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Last revision Both sides next revision | ||
|
litespeed_wiki:cache:common:logged-in-cookie-conflicts [2017/06/01 18:23] Lisa Clarke [The Solution] |
litespeed_wiki:cache:common:logged-in-cookie-conflicts [2017/11/17 20:26] Lisa Clarke [Managing Logged-In Cookie Conflicts] |
||
|---|---|---|---|
| Line 2: | Line 2: | ||
| 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). | 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). | ||
| + | [[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.]] | ||
| ===== The Problem ===== | ===== 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. | 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. | ||
| Line 9: | Line 10: | ||
| 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. | 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. | ||
| - | 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. Since the user is not logged in, LSCache caches the 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. | + | 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. |
| ===== The Solution ===== | ===== The Solution ===== | ||