Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
litespeed_wiki:cache:common:logged-in-cookie-conflicts [2017/06/01 14:02] Lisa Clarke |
litespeed_wiki:cache:common:logged-in-cookie-conflicts [2017/10/18 19:57] Lisa Clarke [The Problem] |
||
---|---|---|---|
Line 5: | Line 5: | ||
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. | ||
- | **Example**: Wordpress at ''<nowiki>www.example.com/</nowiki>'' and xenForo at ''<nowiki>www.example.com/forum/</nowiki>''. | + | **Example**: Wordpress at ''<nowiki>www.example.com/</nowiki>'' and XenForo at ''<nowiki>www.example.com/forum/</nowiki>''. |
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 ===== | ||
- | 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, 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. | + | 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 ==== | ==== Modifying .htaccess Manually ==== |