SOME patreon backers can't access locked site?

Wordpress Plugin
1

Hello you wonderful people!

I just moved my site from an old host (Bluehost) to a new one (Cloudways). Migration worked great, everything’s functioning normally. However, a number of my patrons are having issues accessing our “rewards vault” page. I tried deleting the connection in the plugin and using the wizard to re-establish a connection, which seemed to work just fine. I’ve instructed my users to clear their cache or try an incognito window. Sometimes they can get in, but sometimes they get caught in an “endless loop” of trying to log in and getting kicked back out. These were users who previously accessed the site with zero issue.

I’ve looked at my connection errors, and haven’t gotten any since I reset the connection with the V2 API. Could this be a cache issue? Any troubleshooting steps? I’ve removed all the rest of my old API keys via Patreon, and now only have one (the new, V2 API)

WP 5.9 with PHP 7.4.27
Patreon WordPress 1.8.1 with API v2

2

Some more data - seems like users in the UK and Canada can access with no issues, but it’s hit-and-miss for US users. The page in specific is: Patreon Rewards Page | Lords of the Trident

and our patreon is: patreon.com/LordsOfTheTrident

3

If these users were accessing gated content easily while at Bluehost, changing infra may have affected some things. Do you have a CDN or other caching mechanism at Cloudways?

4

There is a CDN, but I don’t have it engaged. And it’s been a few days since moving over, so everything should be propagated now, I’d assume?

5

Cloudways has Varnish cache I believe. If its active, it may affect such things, depending.

6

Hi, I know this is an old issue, and there are multiple issues where you’ve addressed caching problems, but is there a way to configure Varnish not to cause problems with the flow?

We’ve isolated Varnish as a definite cause of the login problems, but we cannot disable Varnish yet.

Is there a way around this?

Cheers!

7

No, I wasn’t able to figure it out. I ended up having to shut off all caching plugins on my site to get it to function.

8

After a few interesting days, here’s a solution to the problem.
Varnish was configured to clear all the cookies except those of wp-admin/wp-login URLs. This is part of a standard WordPress Varnish configuration I found on the internet somewhere.
Now that’s not a problem when you’re logging in the standard way through the form. But, the plugin logs you in from the patreon-authorization/ path. That’s a problem because Varnish clears the wordpress_logged_in_{hash} cookie which is essential for any further operations.
The user appears to be logged in when you check, but they aren’t, and then it seems like you need to log in again.
My solution was to add the patreon-authorization URL to the exceptions like this:

if (!(bereq.url ~ "patreon-authorization")  && !(bereq.url ~ "wp-(login|admin)") && !bereq.http.cookie ~ "wordpress_logged_in|resetpass" ) {
    unset beresp.http.set-cookie;
    set beresp.ttl = 1w;
    set beresp.grace =3d;
  }

Hope this helps.
@codebard Thanks for the great plugin, hope you’ll continue to improve it.

1 Like
9

Hi Ana1 -

Thanks so much for posting your findings. Can I ask - did you add this exception in a specific file, or is this somewhere in the varnish options on Wordpress’ admin pages?
(I’m using Breeze by cloudways, which includes the varnish cache, and I can’t seem to find any areas to add code like this)

Sorry for the basic question!

10

Good catch - yes, if any caching system is interfering, you may end up with issues like this.

11

No worries, that’s not a basic question whatsoever. Rarely does someone go into Varnish configuration unless they have to.

The file is default.vcl, which is the main configuration file Varnish uses. You can configure any rule in that file. Hope this helps, let me know if you need more info.

@codebard, yes, that’s the first suspect and there may be other problems with caching, but at least we have a solution for one of those problems now. It’s hard to pinpoint these types of problems because you need a live website to debug them.

1 Like