Possible Conflict with Ajax when Protecting WP-Admin? Web site forms/etc affected

Zero Trust
1

What is the name of the domain?

Related to

Settings

What is the error message?

Multiple

What is the issue you’re encountering

Conflict

What steps have you taken to resolve the issue?

This issue has been infuriating me for WEEKS and taking up way too much of my time. Since I migrated my site and forums to WP and WPForo, Ive encountered very wonky behavior that was hit or miss at times. Things that would stop working properly include:

  1. Contact Us form using WPForms. When not working the SUBMIT butt would just flash very quickly. Nothing would happen. No execution and no form sent/received. No error message.
    Link here: Contact Us – UD Pride

  2. Lost Password request link. When not working it would kick you to a very simple page with a line of text saying “The link you followed has expired. Please try again” in the upper left corner of the screen.
    Link here: Lost Password – UD Pride

  3. MemberPress signup pages with a SIGN ME UP button would no longer work. When clicking the button, the page would render an “An error has occurred please try again” and “Please fix the errors above” message even though there were no errors, missing required fields, failed Turnstile etc. See attached screenshot of error.
    Link example here: Pride+ Silver – UD Pride

  4. Notification bell pop-up box on WPForo that shows latest replies to posts, messages etc would not work. Just the spinning balls in perpetuity.
    Link here: UDPride Community – UD Pride (you’d need to be logged in to get notifications)

  5. Other issues I might not know about.

What are the steps to reproduce the issue?

  1. My initial troubleshooting thought it was a CF caching issue. Before I turned off CF Caching (dev mode) I turned off all localized caching (disabled WP-Rocket and WPForo cache). Then I put CF Cache into Dev Mode. Problems seems to go away and functionality returned – for a while. Maybe a week or two. Then exact same problems returned. Then Id mess with turning CF Cache back on and off and diddle with trying to work my way through a possible Page cache rule etc. Nothing seemed completely permanent in a fix. What was ABSOLUTELY TRUE was the problems all came at the same time and went away at the same time so they are all related to the same fault. If one of these items started failing or working again, they all failed or worked again.

  2. I cleared browser cache, cookies, tried different computers, used different origination IPs. The results were all hit or miss at best. Nothing seemed to jump out.

  3. What makes it more maddening is I have a buddy who did the exact same conversion and launch of WP and WPForo at the same time using much the same CF setup and he has no issues.

So what’s this got to do with Zero Trust???

  1. In the middle of all of this web launch on 8/1 and issues starting some time thereafter, I began configuring Zero Trust to block access to my wp-admin page for security. After about a week of hand-wringing I got it working and its working 100% fine. Because I had some third parties and other authors helping out my site, I didnt want them dealing with Zero Trust so I periodically turned it off and on over the last month whlie all these web site issues were still ongoing. I also varied the URL to block in Zero Trust from “wp-admin” to “wp-admin/” to “wp-admin*” etc just to see what difference it made to Zero Trust only.

  2. All my site issues came back 2-3 days ago after working for about 2 weeks. Now I was mad again. I looked into it further with CF Community searches and Googling and my revised thoughts were this seems less like caching and more like javascript or ajax or some specific FUNCTIONALITY problem rather than caching – because caching everywhere else seems to be working. Im not getting stale pages or 404s or 403s or 401s or anything. Every other part of the website was running fine. It seemed to related to the interactive function of a form or script pop-up (notification bell). I finally found a thread here:

…and in the thread a person mentioned Zero Trust causing some issues with /wp-admin/admin-ajax.php when the wp-admin was being guarded by Zero Trust. HMMMM. So on a whim I decided to disable Zero Trust on the wp-admin* page and immediately the problems went away. Right now I have CF caching on (non-dev mode). Since I disabled ZT early yesterday I have had no issues. Its quite possible every time I was having earlier issues I had ZT enabled on the wp-admin because I was not tracking each feature concurrently as I didnt think they were related in any way (ZT and caching or some other reason).

QUESTION:
Is it possible all my issues were related to Zero Trust on the wp-admin? Every time I think I have things solved, they are solved for about a week and then come back – but this time I know I wont be enabling/disabling ZT so I can at least now rule it in or our as the culprit if the problems stay away or come back.

Has anyone ever experienced this kind of issue with ZT or am I breaking new ground? Im hoping someone on here chimes in with “oh yeah that pulled my hair out too for several weeks until I figured out it was ZT on the wp-admin”. Im hopeful, but still skeptical.

The next question is, lets assume ZT is the one boogering up /wp-admin/admin-ajax.php from working properly, I still need to get ZT to work on the wp-admin and it not affect my web site. How to go about doing it?

The last time I enabled ZT, I was using the /wp-admin*" path with the asterisk. Is the asterisk the problem of the entire path itself? Or does it not really matter whether to use:

wp-admin
wp-admin"
wp-admin/
wp-admin*

…and the resolution is some other fix such as rule or exception somewhere else in CF to get this to work full-time?

I’m going to need 3rd grade dumbed guidance on this one because Ive lost all my hair from trying to troubleshoot this. Hopefully I provided enough intel that people can chime in and lead me down a path to permanent fix and salvation because its costing me boatload of unearned income with a non-functioning site (that for now…knock on wood…is back to working).

THANKS

Screenshot of the error

subscription error.jpg
subscription error.jpg990×1261 153 KB

2

Quite possibly. Why are you trying to protect wp-admin against users who aren’t logged in?

3

Im just attempting to block the wp-admin page from being publicly accessible for security so bots and other hackers can’t connect to it, but I and all of my authors and third parties can when I assign their email address in Zero Trust.

Its working fine when I enable it, get the email, input the code, get to wp-admin etc.

But Im concerned this could be my issue with all my other outlined site issues. Not sure if its a generic Zero Trust thing on any partial or specific wp-admin URL string, or my asterisk in the string was wildcarding it to become a problem, or I need to make some Cloudflare exception somewhere to ensture that ajax path works properly…or if Im barking up the wrong tree entirely and Im making unrelated things into coincidences and ZT and my site issues are totally unrelated.

I can say 100% though the minute I disabled ZT on the wp-admin, they went away. Whether they stay away? Thats the litmus test.

4

Unless the user is authenticated through wp-login, they won’t be able to connect to the wp-admin page. They’ll be redirected to wp-login. It’s best to just put Access in front of wp-login, and leave it at that.

5

Okay I will try that.

Should I made the syntax
/wp-login*
/wp-login/
/wp-login/*
/wp-login

or will it make any difference?

6

For my Access app, I use example.com/wp-login.php

7

OK let me try this and see if it works and doesnt “break” my site. I will report back.

1 Like
8

Using /wp-login.php did not “break” my site for blocking wp-admin access. Going to domain.com/wp-admin kicks over to wp-login.php fine and I get the CF ZT screen.

But its generating the CF ZT screen for all users attempting to log into the front of the web site too which is not what I want. I will need a different solution.

9

Sorry about that.

Going back to your original setup, if the issue is admin-ajax, you can add another Access App for that specific URL that allows everybody through.

1 Like
10

What specifically do you mean by access app? Another ZT App? Even if I allow all users to /wp-admin/admin-ajax.php isnt it still going to prompt with the ZT Cloudflare access screen for authentication of any user? Or do I do it by country/IP?

Is there a way this can be done in WAF or some page rule exception? Obviously ZT setup is working for my wp-admin admins and authors when the app points to wp-login.php, but my front-end users are burdened by the same protection when they dont need it as they are using wp-login.php from the “front end”.

11

Yes. Zero Trust is the name for a group of Cloudflare products. The one you are mentioning here is Access.

In your new Access app, you need to create a BYPASS policy for the URLs that you wish to exclude.
https://developers.cloudflare.com/cloudflare-one/policies/access/#bypass

1 Like
12

Not sure how this is going to work.

Whether you make an allowable ZT app/access rule based on email or bypass (i.e. anyone or by country) to wp-admin.php or wp-login/php its basically taking you to the same place? I want to block the default WP login access page to only my admins/authors in ZT without breaking the /wp-admin/admin-ajax.php path.

Seems like somewhere in CF I can make a firewall cloud rule that always allows access to admin-ajax.php even when I have ZT set to wp-admin.php. Of course this causes all my web site issues when I set it to wp-admin.php, but when I set up ZT to wp-login.php it fixes my web site issues but then asks everybody on the front end for ZT email verification which I dont want and these 3,000 users are not set up for ZT email authentication anyway.

If I have two ZT app/accesses – one for wp-admin for email verification, and one for wp-login for bypass and “anyone” or by country, both accesses would still allow browsable access to the default WP login page which would not really solve my page access lockdown needs to lock down this back end default WP login from brute force and other hacks.

Maybe Im overthinking it, but I can’t envision the solution in my mind.

Isnt there some way and somewhere to just create a simple cloud firewall rule or exception that overrides all other CF settings and allows for full access to wp-admin/ajax.php? If so I could then go back to just using my default CF ZT app/access that used wp-admin as the path.

13

I believe you should create 2 Access applications noo for the following paths, wp-admin/ and wp-admin/admin-ajax.php

The first is your normal Allow policy, the second is with the bypass policy.

You can see how it works here:
https://test.laudian.de/test
https://test.laudian.de/test/test.html

The first asks for a sign-in, the second is available.

1 Like