XF 1.5 Exclude XenForo cookies from cache

[LPH]

I'm trying to get WP and XF caching to cooperate. It's perfect when using Chrome. Safari and Firefox, on the other hand, are not cooperating and showing other members login links, etc.

WP-Rocket support states:

One of your plugins could be using some custom cookies, rather than the normal WordPress ones, to detect login/logout status, and those would have to be excluded as well.

This is very true, XenWord uses the XF cookies to authenticate a WP login. I get that support is suggesting to exclude the cookies, but how is that done? Do I pull from the config.php information or somewhere else?

 

[Jake Bunce]

The problem and proposed solution aren't clear to me.

XenForo cookies have a name which includes the "xf_" prefix, and a scope which is based on the path and domain. See this post for help configuring these things:

https://xenforo.com/community/threads/xenforos-handing-of-cookie-domains.15260/#post-200173

Naming conflicts are unlikely given the default "xf_" prefix in all XenForo cookies. But scope can be a consideration if you need another application like Wordpress to be able to see XenForo's cookies.

Note that changing any of these cookie settings can potentially invalidate existing cookies (users must login again).

 

[LPH]

The problem and proposed solution aren't clear to me.

The problem
When WP-Rocket (WP caching plugin) is enabled then a visitor can go to the WordPress side of the site and see the page as if logged in as someone else (who browsed that page first). For example, Gracie goes to a page, logs in, goes off to another page. LPH goes to the same page using Safari or Firefox and the page renders as if the user is Gracie. Obviously Gracie information shouldn't be shown to LPH, etc.

More details
Currently a WordPress pluggable function in WordPress identifies the user as logged in.

function wp_validate_auth_cookie( $cookie = '', $scheme = '' ) {

    $visitor = XenWord::getVisitor();
    $user_id = $visitor['user_id'];

    if ( $user_id !== 0 ) {
        return $user_id;
    }

    return false;
}

If caching is not enabled then the above problem does not exist; that is, members see the site as expected and don't see someone else logged into the site.

In other words, a cached page is being served to everyone instead of a logged in user not having the page cached.

 

[Jake Bunce]

I am not familiar with WP-Rocket.

If the custom auth is the problem then maybe you can use an "if" condition in that function to target only the desired pages thereby excluding all other WP pages for which you don't want custom authentication.

Just spitballing...

 

[Jake Bunce]

Or modify your custom auth to write to WP's default cookies on which WP-Rocket depends.

 

[alexD]

Have you tried to change the 'Logged In User Cache' setting?

I can think of two possible solutions: Either disable caching for logged in users (e.g. detect the 'xf_' cookie and do something like this) or fix the per user caching system some other way.

Nice job with XenWord BTW!

 

[LPH]

modify your custom auth to write to WP's default cookies on which WP-Rocket depends.

This would be a nice idea. Not sure how to do it but it's something to look into.

Have you tried to change the 'Logged In User Cache' setting?

I've tried many options. WP-Rocket support is going to look into things a bit tomorrow. They looked today and couldn't report back a fix.

do something like this) or fix the per user caching system some other way.

It's the caching that I'm after, otherwise, there are dozens of other plugins that can work to minify, CDN, etc.

Nice job with XenWord BTW!

Thank you. I've spent the day worrying about one file and found several errors that have my head is spinning. The easy ones are fixed but it lead to another bug covered up. I have so much to learn.