Gutenberg: CloudFlare blocking REST API PUT Request (Draft Doesn't Get Saved) (solved by an update from Cloudflare)

[ahmadawais]

[UPDATE: Cloudflare rolled out a fix for problems with the WP0025B rule 8-Aug-2018, please update.]

I have started to try Gutenberg on a production site and it is not working. The site is new and has no other plugin installed. Looks like the PUT request is not working.

I am using the latest version of Gutenberg 1.1.0 available in the WP Repo.
I have also tried this on two other sites and same error.
I thought I should report it here?

[toddhalfpenny]

I have a sneaking suspicion that this is actually not a Gutenberg fault, but a deeper one with the REST api.
Do you have the basic permalinks set? If so, try swapping to a custom permalink and give it another go.
I wrote up some details (with links to tracs etc) when I ran into this symtom.

[ahmadawais]

Yeah, I have pretty permalinks set up. I even used a front end post submission plugin that's built with REST API and it works.

[westonruter]

This may be a duplicate of #1935.

[ahmadawais]

@westonruter I'm afraid you're right. Looks like there's an issue with the PUT request as it returns a 403.

PUT https://a2podcast.com/wp-json/wp/v2/posts/44 403 ()

for

load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,utils,underscore,backbone,wp-util,wp-backbone,media-models,plupload,wp-plupload,jquery-ui-core,jquery&load[]=-ui-widget,jquery-ui-mouse,jquery-ui-sortable,mediaelement,wp-mediaelement,media-views&ver=4.8.1:4

[ahmadawais]

If I log XMLHttpRequests then this is the message I get.

XHR failed loading: PUT "https://a2podcast.com/wp-json/wp/v2/posts/46".

[rmccue]

What is the request/response data for the API request?

[JustinSainton]

Tried logging the _actual_ API req/res objects via REST API Log plugin, but no dice. Maybe this is insightful in the meantime?

[ahmadawais]

@rmccue I have the similar log as of @JustinSainton

It still doesn't work.

[rmccue]

What is the response payload that accompanies this?

[ahmadawais]

@rmccue Thanks for asking the right question. I haven't looked at the response payload.

Turns out CloudFlare is the reason why this is happening.

The response payload is this

I disabled CloudFlare on one of my domains to check if this works and it did. But this again is a big problem. So many sites are hosted on CloudFlare. I am currently looking into what is causing CloudFlare to ban the IP for adding a draft via Gutenberg. Looks like the Browser Integrity Check where it's banning a headless call. Which shouldn't be banned.

I have no page rules set. Nothing. Looks like default configurations of CloudFlare are banning the API from posting via Gutenberg.

[ahmadawais]

Looks like CloudFlare has a globally enabled rule set in WAF — even for free users — that no one can even disable (AFAIK).

Here are the details https://blog.cloudflare.com/protecting-everyone-from-wordpress-content-injection/

I wonder if @aaroncampbell could help with this — I can see his comments on the post.

Looking forward!

[JustinSainton]

I'm _not_ using Cloudflare, but this is interesting. I suppose something at the server-level with the host (We're on Siteground) could be blocking PUT requests. I'll ask them about this.

[JustinSainton]

@rmccue And my response payload is the CPanel 403 HTML response, fwiw:

[rmccue]

Interesting. Based on this, it seems like it may be a REST API issue with these hosts. We may need to reach out and see about fixing this.

If you switch Gutenberg to use POST instead of PUT, does this still occur? (The API accepts POST everywhere it accepts PUT, but you can also do POST ?_method=PUT to simulate an actual PUT on the backend.)

[ahmadawais]

@rmccue How do you propose would one switch from PUT to POST in Gutenberg?

[BE-Webdesign]

@ahmadawais

Do the same PUT request you are doing as a POST request instead and add the request arg _method=PUT. This will trigger the x-http-method-override header so that the REST API will know you really mean PUT even though the server can't handle PUT and only wants to use POST requests. You can do the same for DELETE. For Gutenberg you can monkey patch the wp.api requests to use the method override. That would be a temporary solution, while this is figured out for the larger context of how the REST API will be used in this project and other areas of core.

[JustinSainton]

@rmccue Found the source. In our case, Siteground had put the following block in our .htaccess file

    # Block Request Method #
    RewriteCond %{REQUEST_METHOD} ^(connect|debug|delete|move|options|put|trace|track) [NC]
    RewriteRule .* - [F]

This was the root cause of the issue. I hadn't had the opportunity to attempt anything to prove the case, but I assume the DELETE and OPTIONS methods would have also failed.

[rmccue]

@JustinSainton Nice digging! DELETE, OPTIONS, and PUT all need to be whitelisted for the API (OPTIONS is used by browsers automatically for cross-origin requests).

Was this specific to your site, or a SiteGround-wide thing? If the latter, I'll try and follow up with them.

[JustinSainton]

@rmccue I'm not certain whether or not this is SiteGround-wide or not - I _vaguely_ recall their support team modifying our htaccess file years ago, for some reason. So it may not be _that_ widespread, but certainly feels like something to account for and educate hosts on.

[m]

This definitely gives pause when you consider what it means for broader use of the REST API.

First-party use of all the API methods in core in wp-admin (with helpful error messages) would expose and get these fixed very quickly.

[rmccue]

This has come up once or twice before (IIRC, GoDaddy and WP Engine), and the hosts are usually pretty responsive. Luckily, blocking methods tends to be a thing that only the big hosts do for "protection". Will definitely follow this up with SG to find out if it's a local or global thing.

(A bigger concern there is authentication, which is much worse, but not relevant to built-in stuff like Gutenberg.)

[ahmadawais]

@rmccue

A bigger concern there is authentication, which is much worse, but not relevant to built-in stuff like Gutenberg.

Couldn't agree more.

But as Matt suggested, having Gutenberg depend on WP REST API will lay the groundwork for better REST API enabled future for WordPress apps.

[lkraav]

This is fairly certainly a duplicate of #2565

[CantonJester]

@JustinSainton - I'm on SiteGround myself and was kicking the tires on Gutenberg earlier this evening on my development site: After an initial publishing of a post, I cannot update the post for the life of me. While I do not think I had my htaccess file edited the way yours was, I'm wondering if something similar is going on.

Looks like I'm off to open a ticket with SiteGround.

[ahmadawais]

Hey, folks! 🙌
I'm closing this issue based on the fact that after working with CloudFlare's support for two months, I've got it fixed and now CloudFlare sites are able to use Gutenberg without any issues.

Feel free to reopen it if there are other similar issues. 🔥

[ahmadawais]

I'd like to reopen this issue as the CloudFlare basic security (with default setup) is blocking Gutenberg! It just doesn't work.

I have an open support ticket at CoudFlare but need more support there to push it to the priority list.

[pento]

@ahmadawais: Would you be able to test if the change in #4396 fixes this problem on your CloudFlare setup?

[pento]

On digging through some of the history for the security issue that CloudFlare's WP0025B rule blocks, I don't think #4396 will work to fix it. I'll look into it some more.

[ahmadawais]

@pento Sure, I can test that if you want?

And you're right that it's a rule called WP0025B by CloudFlare that's doing this — I wrote about it in a comment above. It was fixed after a lot of back and forth between me and the CloudFlare Engineering team. I provided them with the HAR file and all. But it's again like that.

🎯 I think if more people than just me would talk to CloudFlare we'll be able to get it fixed for a millions of sites out there that use CloudFlare with WordPress. Otherwise, WP REST API is potentially broken when we are using CloudFlare.

Let me know how I can help you proceed! 💯

[pento]

@ahmadawais: It's worth testing, just to be sure. We're reaching out to a few people we know at Cloudflare, to see if they can help address it.

[ahmadawais]

@pento Sure thing.

❌ Gutenberg Plugin

So, I went ahead and installed the latest Gutenberg plugin from WP.org repo at one of my blogs.
Then I went the Gutenberg menu in the left-bottom and tried to update the post, by clicking Save Draft and this is what I got.

---

❌ CloudFlare

At CloudFlare this is what got triggered this time

❌ After Applying the Patch

And I tried the same steps after applying the patch in #4396 no luck. It's the same response as above.
This error is prominent when you're updating a prewritten post, earlier (before CloudFlare fixed it) it was much more worse. Though, I can create new posts right now just fine, after that it gets blocked when I try to save the draft. — CloudFlare's trying to test the user with Google reCaptcha in the response of an API call is bad.

Event Details

Here're the exported event details from CloudFlare (minus my domain name).

{
  "id": "3db5cdc34fdc9df7",
  "country": "PK",
  "ip": "182.181.23.252",
  "protocol": "HTTP/2",
  "method": "POST",
  "host": "****.com",
  "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36",
  "uri": "/wp-json/wp/v2/posts/11798",
  "request_duration": 0,
  "triggered_rule_ids": [
    "950001",
    "950901",
    "958011",
    "959073",
    "960024",
    "973300",
    "973304",
    "973306",
    "973308",
    "973333",
    "973334",
    "973335",
    "973338",
    "981133",
    "981136",
    "981176",
    "981231",
    "981243",
    "981245",
    "981246",
    "981248",
    "981256",
    "981257",
    "981301",
    "981310"
  ],
  "action": "challenge",
  "cloudflare_location": "ATH",
  "occurred_at": "2018-01-11T06:26:18.76Z",
  "rule_detail": [
    {
      "id": "960024",
      "description": "OWASP_CRS/WEB_ATTACK/COMMAND_INJECTION-ARGS:JSON_ARG_0002=<!-- "
    },
    {
      "id": "981231",
      "description": "OWASP_CRS/WEB_ATTACK/SQL_INJECTION-ARGS:JSON_ARG_0002=0"
    },
    {
      "id": "950901",
      "description": "OWASP_CRS/WEB_ATTACK/SQL_INJECTION-ARGS:JSON_ARG_0002=h2>Of"
    },
    {
      "id": "",
      "description": "0="
    },
    {
      "id": "",
      "description": "1="
    },
    {
      "id": "",
      "description": "2="
    },
    {
      "id": "",
      "description": "3="
    },
    {
      "id": "",
      "description": "4="
    },
    {
      "id": "",
      "description": "5="
    },
    {
      "id": "",
      "description": "6="
    },
    {
      "id": "",
      "description": "7="
    },
    {
      "id": "",
      "description": "8="
    },
    {
      "id": "",
      "description": "9="
    },
    {
      "id": "",
      "description": "0="
    },
    {
      "id": "",
      "description": "1="
    },
    {
      "id": "",
      "description": "2="
    },
    {
      "id": "",
      "description": "3="
    },
    {
      "id": "",
      "description": "4="
    },
    {
      "id": "",
      "description": "5="
    },
    {
      "id": "",
      "description": "6="
    },
    {
      "id": "",
      "description": "7="
    },
    {
      "id": "",
      "description": "8="
    },
    {
      "id": "",
      "description": "9="
    },
    {
      "id": "",
      "description": "0="
    },
    {
      "id": "",
      "description": "1="
    },
    {
      "id": "",
      "description": "2="
    },
    {
      "id": "",
      "description": "3="
    },
    {
      "id": "950001",
      "description": "OWASP_CRS/WEB_ATTACK/SQL_INJECTION-2000000408_146=insert into"
    },
    {
      "id": "",
      "description": "0="
    },
    {
      "id": "",
      "description": "1="
    },
    {
      "id": "",
      "description": "2="
    },
    {
      "id": "",
      "description": "3="
    },
    {
      "id": "",
      "description": "4="
    },
    {
      "id": "",
      "description": "5="
    },
    {
      "id": "",
      "description": "6="
    },
    {
      "id": "",
      "description": "7="
    },
    {
      "id": "",
      "description": "8="
    },
    {
      "id": "",
      "description": "9="
    },
    {
      "id": "",
      "description": "0="
    },
    {
      "id": "",
      "description": "1="
    },
    {
      "id": "",
      "description": "2="
    },
    {
      "id": "",
      "description": "3="
    },
    {
      "id": "",
      "description": "4="
    },
    {
      "id": "",
      "description": "5="
    },
    {
      "id": "",
      "description": "6="
    },
    {
      "id": "",
      "description": "7="
    },
    {
      "id": "",
      "description": "8="
    },
    {
      "id": "",
      "description": "9="
    },
    {
      "id": "",
      "description": "0="
    },
    {
      "id": "",
      "description": "1="
    },
    {
      "id": "",
      "description": "2="
    },
    {
      "id": "",
      "description": "3="
    },
    {
      "id": "959073",
      "description": "OWASP_CRS/WEB_ATTACK/SQL_INJECTION-2000000408_146=insert into"
    },
    {
      "id": "981257",
      "description": "DETECTS MYSQL COMMENT-/SPACE-OBFUSCATED INJECTIONS AND BACKTICK TERMINATION-OWASP_CRS/WEB_ATTACK/SQLI-2000000408_146=,\"align\":\"wide\"} -->\n<section class="
    },
    {
      "id": "981248",
      "description": "DETECTS CHAINED SQL INJECTION ATTEMPTS 1/2-OWASP_CRS/WEB_ATTACK/SQLI-2000000408_146=div class=\""
    },
    {
      "id": "981256",
      "description": "DETECTS MATCH AGAINST, MERGE, EXECUTE IMMEDIATE AND HAVING INJECTIONS-OWASP_CRS/WEB_ATTACK/SQLI-2000000408_146= having f"
    },
    {
      "id": "981245",
      "description": "DETECTS BASIC SQL AUTHENTICATION BYPASS ATTEMPTS 2/3-OWASP_CRS/WEB_ATTACK/SQLI-2000000408_146=\":\"https://c"
    },
    {
      "id": "981246",
      "description": "DETECTS BASIC SQL AUTHENTICATION BYPASS ATTEMPTS 3/3-OWASP_CRS/WEB_ATTACK/SQLI-2000000408_146=\"url\":\""
    },
    {
      "id": "981243",
      "description": "DETECTS CLASSIC SQL INJECTION PROBINGS 2/2-OWASP_CRS/WEB_ATTACK/SQLI-2000000408_146=\":\"https://cldup.com/Fz-ASbo2s3.jpg\",\"align\":\"wide\"} --"
    },
    {
      "id": "973338",
      "description": "OWASP_CRS/WEB_ATTACK/XSS-2000000412_204= style="
    },
    {
      "id": "958011",
      "description": "OWASP_CRS/WEB_ATTACK/XSS-2000000408_143=background-image:"
    },
    {
      "id": "973300",
      "description": "OWASP_CRS/WEB_ATTACK/XSS-ARGS:JSON_ARG_0002=<p>"
    },
    {
      "id": "973304",
      "description": "OWASP_CRS/WEB_ATTACK/XSS-2000000408_136=src="
    },
    {
      "id": "973306",
      "description": "OWASP_CRS/WEB_ATTACK/XSS-2000000408_136=style="
    },
    {
      "id": "973308",
      "description": "OWASP_CRS/WEB_ATTACK/XSS-ARGS:JSON_ARG_0002=background-image:"
    },
    {
      "id": "973335",
      "description": "OWASP_CRS/WEB_ATTACK/XSS-2000000412_217=\",\"align\":\"wide\"} --> <section class=\"wp-block-cover-image has-background-dim alignwide\" style=\"background-image:url(https://cldup.com/Fz-ASbo2s3.jpg)"
    },
    {
      "id": "973334",
      "description": "OWASP_CRS/WEB_ATTACK/XSS-2000000412_217=\"url\":\"https://cldup.com/Fz-ASbo2s3.jpg\",\"align\":\"wide\"} --> <section class=\"wp-block-cover-image has-background-dim alignwide\" style=\"background-image:url(https://cldup.com/Fz-ASbo2s3.jpg)\"> <h2>Of Mountains & Printing Presses</h2> </section> <!-- /wp:cov"
    },
    {
      "id": "973333",
      "description": "OWASP_CRS/WEB_ATTACK/XSS-2000000412_217=\",\"align\":\"wide\"} --> <section class=\"wp-block-cover-image has-background-dim alignwide\" style=\"background-image:url(https://cldup.com/Fz-ASbo2s3.jpg)\"> <h2>Of Mountains & Printing Presses</h2> </section> <!-- /wp:cover-image --> <!-- wp:paragraph --> <p>T"
    },
    {
      "id": "960024",
      "description": "OWASP_CRS/WEB_ATTACK/COMMAND_INJECTION-ARGS:JSON_ARG_0002"
    }
  ],
  "rule_message": "Inbound Anomaly Score Exceeded (Total Score: 98, SQLi=24, XSS=45): Last Matched Message: IE XSS Filters - Attack Detected.",
  "type": "waf",
  "rule_id": "981176",
  "zone_id": "5ea7ee45ad8481b404d5fb3e3cda83da",
  "cookie": ""
}

[pento]

Cool, thanks for testing that. Having the rule name that was triggered is a useful bit of information.

[ahmadawais]

Event Details

Here're the exported event details from CloudFlare (minus my domain name). (CLICK TO EXPAND!)

{
  "id": "3db5cdc34fdc9df7",
  "country": "PK",
  "ip": "182.181.23.252",
  "protocol": "HTTP/2",
  "method": "POST",
  "host": "****.com",
  "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36",
  "uri": "/wp-json/wp/v2/posts/11798",
  "request_duration": 0,
  "triggered_rule_ids": [
    "950001",
    "950901",
    "958011",
    "959073",
    "960024",
    "973300",
    "973304",
    "973306",
    "973308",
    "973333",
    "973334",
    "973335",
    "973338",
    "981133",
    "981136",
    "981176",
    "981231",
    "981243",
    "981245",
    "981246",
    "981248",
    "981256",
    "981257",
    "981301",
    "981310"
  ],
  "action": "challenge",
  "cloudflare_location": "ATH",
  "occurred_at": "2018-01-11T06:26:18.76Z",
  "rule_detail": [
    {
      "id": "960024",
      "description": "OWASP_CRS/WEB_ATTACK/COMMAND_INJECTION-ARGS:JSON_ARG_0002=<!-- "
    },
    {
      "id": "981231",
      "description": "OWASP_CRS/WEB_ATTACK/SQL_INJECTION-ARGS:JSON_ARG_0002=0"
    },
    {
      "id": "950901",
      "description": "OWASP_CRS/WEB_ATTACK/SQL_INJECTION-ARGS:JSON_ARG_0002=h2>Of"
    },
    {
      "id": "",
      "description": "0="
    },
    {
      "id": "",
      "description": "1="
    },
    {
      "id": "",
      "description": "2="
    },
    {
      "id": "",
      "description": "3="
    },
    {
      "id": "",
      "description": "4="
    },
    {
      "id": "",
      "description": "5="
    },
    {
      "id": "",
      "description": "6="
    },
    {
      "id": "",
      "description": "7="
    },
    {
      "id": "",
      "description": "8="
    },
    {
      "id": "",
      "description": "9="
    },
    {
      "id": "",
      "description": "0="
    },
    {
      "id": "",
      "description": "1="
    },
    {
      "id": "",
      "description": "2="
    },
    {
      "id": "",
      "description": "3="
    },
    {
      "id": "",
      "description": "4="
    },
    {
      "id": "",
      "description": "5="
    },
    {
      "id": "",
      "description": "6="
    },
    {
      "id": "",
      "description": "7="
    },
    {
      "id": "",
      "description": "8="
    },
    {
      "id": "",
      "description": "9="
    },
    {
      "id": "",
      "description": "0="
    },
    {
      "id": "",
      "description": "1="
    },
    {
      "id": "",
      "description": "2="
    },
    {
      "id": "",
      "description": "3="
    },
    {
      "id": "950001",
      "description": "OWASP_CRS/WEB_ATTACK/SQL_INJECTION-2000000408_146=insert into"
    },
    {
      "id": "",
      "description": "0="
    },
    {
      "id": "",
      "description": "1="
    },
    {
      "id": "",
      "description": "2="
    },
    {
      "id": "",
      "description": "3="
    },
    {
      "id": "",
      "description": "4="
    },
    {
      "id": "",
      "description": "5="
    },
    {
      "id": "",
      "description": "6="
    },
    {
      "id": "",
      "description": "7="
    },
    {
      "id": "",
      "description": "8="
    },
    {
      "id": "",
      "description": "9="
    },
    {
      "id": "",
      "description": "0="
    },
    {
      "id": "",
      "description": "1="
    },
    {
      "id": "",
      "description": "2="
    },
    {
      "id": "",
      "description": "3="
    },
    {
      "id": "",
      "description": "4="
    },
    {
      "id": "",
      "description": "5="
    },
    {
      "id": "",
      "description": "6="
    },
    {
      "id": "",
      "description": "7="
    },
    {
      "id": "",
      "description": "8="
    },
    {
      "id": "",
      "description": "9="
    },
    {
      "id": "",
      "description": "0="
    },
    {
      "id": "",
      "description": "1="
    },
    {
      "id": "",
      "description": "2="
    },
    {
      "id": "",
      "description": "3="
    },
    {
      "id": "959073",
      "description": "OWASP_CRS/WEB_ATTACK/SQL_INJECTION-2000000408_146=insert into"
    },
    {
      "id": "981257",
      "description": "DETECTS MYSQL COMMENT-/SPACE-OBFUSCATED INJECTIONS AND BACKTICK TERMINATION-OWASP_CRS/WEB_ATTACK/SQLI-2000000408_146=,\"align\":\"wide\"} -->\n<section class="
    },
    {
      "id": "981248",
      "description": "DETECTS CHAINED SQL INJECTION ATTEMPTS 1/2-OWASP_CRS/WEB_ATTACK/SQLI-2000000408_146=div class=\""
    },
    {
      "id": "981256",
      "description": "DETECTS MATCH AGAINST, MERGE, EXECUTE IMMEDIATE AND HAVING INJECTIONS-OWASP_CRS/WEB_ATTACK/SQLI-2000000408_146= having f"
    },
    {
      "id": "981245",
      "description": "DETECTS BASIC SQL AUTHENTICATION BYPASS ATTEMPTS 2/3-OWASP_CRS/WEB_ATTACK/SQLI-2000000408_146=\":\"https://c"
    },
    {
      "id": "981246",
      "description": "DETECTS BASIC SQL AUTHENTICATION BYPASS ATTEMPTS 3/3-OWASP_CRS/WEB_ATTACK/SQLI-2000000408_146=\"url\":\""
    },
    {
      "id": "981243",
      "description": "DETECTS CLASSIC SQL INJECTION PROBINGS 2/2-OWASP_CRS/WEB_ATTACK/SQLI-2000000408_146=\":\"https://cldup.com/Fz-ASbo2s3.jpg\",\"align\":\"wide\"} --"
    },
    {
      "id": "973338",
      "description": "OWASP_CRS/WEB_ATTACK/XSS-2000000412_204= style="
    },
    {
      "id": "958011",
      "description": "OWASP_CRS/WEB_ATTACK/XSS-2000000408_143=background-image:"
    },
    {
      "id": "973300",
      "description": "OWASP_CRS/WEB_ATTACK/XSS-ARGS:JSON_ARG_0002=<p>"
    },
    {
      "id": "973304",
      "description": "OWASP_CRS/WEB_ATTACK/XSS-2000000408_136=src="
    },
    {
      "id": "973306",
      "description": "OWASP_CRS/WEB_ATTACK/XSS-2000000408_136=style="
    },
    {
      "id": "973308",
      "description": "OWASP_CRS/WEB_ATTACK/XSS-ARGS:JSON_ARG_0002=background-image:"
    },
    {
      "id": "973335",
      "description": "OWASP_CRS/WEB_ATTACK/XSS-2000000412_217=\",\"align\":\"wide\"} --> <section class=\"wp-block-cover-image has-background-dim alignwide\" style=\"background-image:url(https://cldup.com/Fz-ASbo2s3.jpg)"
    },
    {
      "id": "973334",
      "description": "OWASP_CRS/WEB_ATTACK/XSS-2000000412_217=\"url\":\"https://cldup.com/Fz-ASbo2s3.jpg\",\"align\":\"wide\"} --> <section class=\"wp-block-cover-image has-background-dim alignwide\" style=\"background-image:url(https://cldup.com/Fz-ASbo2s3.jpg)\"> <h2>Of Mountains & Printing Presses</h2> </section> <!-- /wp:cov"
    },
    {
      "id": "973333",
      "description": "OWASP_CRS/WEB_ATTACK/XSS-2000000412_217=\",\"align\":\"wide\"} --> <section class=\"wp-block-cover-image has-background-dim alignwide\" style=\"background-image:url(https://cldup.com/Fz-ASbo2s3.jpg)\"> <h2>Of Mountains & Printing Presses</h2> </section> <!-- /wp:cover-image --> <!-- wp:paragraph --> <p>T"
    },
    {
      "id": "960024",
      "description": "OWASP_CRS/WEB_ATTACK/COMMAND_INJECTION-ARGS:JSON_ARG_0002"
    }
  ],
  "rule_message": "Inbound Anomaly Score Exceeded (Total Score: 98, SQLi=24, XSS=45): Last Matched Message: IE XSS Filters - Attack Detected.",
  "type": "waf",
  "rule_id": "981176",
  "zone_id": "5ea7ee45ad8481b404d5fb3e3cda83da",
  "cookie": ""
}

[pento]

Oh, that's glorious. I don’t think this is WP0025B. I think the raw blocks look too much like a combination of SQLi and XSS attacks, and it triggers some threshold.

[ahmadawais]

Exactly! Can also be related to the blocks + PUT request combination.

WP0025B is what I think they fixed when I first reported it. Which is why I can create a simple post with one para and as it grows in complexity CloudFlare blocks it.

[jeffpaul]

_This ticket was mentioned in Slack in #core-editor by jeffpaul. View the logs._

[JustinSainton]

I see this title change and just want to hearken back to my comment: https://github.com/WordPress/gutenberg/issues/2704#issuecomment-329565058

This seems to be common enough on Cloudflare, but it's definitely not exclusive to Cloudflare.

[jeffpaul]

_This ticket was mentioned in Slack in #core-editor by jeffpaul. View the logs._

[robbiet480]

I've escalated this ticket internally at Cloudflare (i'm a customer). They should be getting deeper into it shortly and may be able to provide some generic feedback.

[caraya]

FWIW, I had a ticket opened with Cloudflare since February. I got the following message yesterday

Thanks for your patience here - I just wanted to let you know our WAF has been updated to specify more compliant default WordPress protections that should now allow the newer versions of the WordPress editor to operate without triggering false positives.

It worked for me after I deleted all my firewall rules. when working from an IP address that had exhibited problems.

I'd suggest you try it after purging the cache.

[pento]

Awesome, thanks for the update, @caraya!

[ahmadawais]

Seems to e working for me. I'll keep testing :)

[roylindauer]

I have installed the latest version of Gutenberg (3.4.0) and this issue still exists. Cloudflare is blocking wp-json requests. I am unable to use the Preview functionality.

Specifically getting the following in the firewall activity logs:

"Prevent abuse against wp-json api Type B"

I have submitted a ticket to Cloudflare.

[roylindauer]

Cloudflare has responded.

It looks like I have to apologize because I may have been mistaken. After having a chance to follow up with our Firewall team here, it appears that the this particular rule cannot be bypassed using Page Rules.

The only way it appears that this particular rule can be bypassed is by specifically disabling it after upgrading to a paid Cloudflare Plan either Professional, Business or Enterprise.

Once you have upgraded your account, you would be able to disable the firewall rule by going to your Firewall page >> selecting Web Application Firewall >> under Cloudflare Rule Set >> click on Cloudflare Wordpress >> Select the rule WP0025B >> set to Disable

I was hoping to find a way to help you resolve this issue without needing to upgrade your account, but it appears that that won't be the case.

The only resolution then, with a free Cloudflare account, is to whitelist all of the IP addresses that will be using the JSON api.

[roylindauer]

@pento I believe this is still an issue that should be addressed. Gutenberg breaks out of the box when using a free Cloudflare account.

[pento]

Thank you for the update, @roylindauer. I'll see if we can reach out to CloudFlare, but please mention in your ticket with them that this is about to become a critical issue: we just released WordPress 4.9.8, which encourages millions of sites to install the Gutenberg plugin.

[pento]

Update for anyone visiting this issue: it's been escalated within CloudFlare, I'll hopefully have an update in a few hours.

[roylindauer]

@pento I have informed Cloudflare via my support ticket.

[ahmadawais]

@pento this shouldn't be a closed issue. It's still as real of a problem as it gets. I have done so much for Gutenberg but even I can't use it on my sites without having to disable CloudFlare — which in itself is a scary thought since I use CF to provide me with security and reduction in bandwidth bills.

I think it's high time now to make CloudFlare realize how big of a problem it's going to be. Happy to help anyway here.

P.S. I still can't use Gutenberg.

The irony of the post I am trying to publish with Gutenberg in the image below

The same old story again

Peace! ✌️

[pento]

The issue is closed, as there's nothing we can do about it from the Gutenberg end. This shouldn't be seen as a "we don't care" flag, it's a "we have a lot of issues to manage, and ones that can't be directly actioned in this repo need to be closed" flag. 🙂

CloudFlare have informed me that they plan to deploy a WAF fix on Monday, so hopefully that will take care of it.

[ahmadawais]

@pento thanks for explaining all that. It makes much more sense to keep it closed that way.

For anyone looking for a quick fix to this, just change the REST API base. It was suggested to me by Fritz Walther.

/**
 * Modify URL base from `wp-json` to 'wpjson'.
 *
 * Save the permalinks again, Settings > Permalinks.
 * Access your API at site.tld/wpjson/wp/v2.
 *
 * @param String $slug The Slug.
 * @return String
 * @since 1.0.0
 */
function aa_api_slug( $slug ) {
    return 'wpjson';
}

// Hook.
add_filter( 'rest_url_prefix', 'aa_api_slug' );

Peace! ✌️

[hExPY]

@ahmadawais do you know if this setting result in any security issues?

[ahmadawais]

Your new API URL will not be protected the same way old one is by CloudFlare.

[pento]

CloudFlare have rolled out a "testing fix" for this: it's currently still blocking the requests, but they're gathering logs. Assuming it all looks good on their end, they intend to roll out the fix properly next Monday.

Naturally, that's way too long to wait, so I'm going to investigate workarounds, so at least y'all can see why it's not working, and what your options are. 🙂

[pento]

Cloudflare rolled out a fix for this earlier today.

@ahmadawais, @roylindauer: Are you still seeing this issue after removing any workarounds you have in place?

[hExPY]

@pento i reverted all changes and it works perfectly now. Thx for keeping in touch with Cloudflare! :-)

[kurtschlatzer]

Thanks to Cloudflare's fix, my WAF log filled up with garbage "whitelist" entries for our folks working in the wp-admin. Grrrrr. Gutenturd.

[caraya]

@pento I have no workaround on either my WordPress site or Cloudflare and I'm still experiencing the editing issue.

[pento]

@caraya: Is your Cloudflare WAF log indicating which rule is causing requests to be blocked?

[caraya]

It's blocking on 100030 because it's challenging the request.

It appears that Cloudflare's patch wasn't fully propagated yet. It is working.

Sorry for the noise

[pento]

Thanks @caraya, this seems to be a different problem to the one Cloudflare has fixed. Rule 100030 is meant to block XSS probing attacks, I would guess that Cloudflare is interpreting the block format (particularly is it contains HTML comments, JSON, and string escaping) as XSS risks.

Which site are you seeing this on, @caraya? I'll follow up with Cloudflare and get them to investigate.

[kesenwang]

The issue is still happening as well on our Wordpress site, disabled both rules in cloudflare as per the guideline but doesn’t seem to have an effect. Actually some rules in cloudflares WAF seem to not actually disable I’m not sure but in terms of whitelisting as well I’ve whitelisted all of Taiwan just out of frustration because cloudflare kept blocking my ip despite whitelisting all Taiwanese ips. Anyways hopefully there is a fix for this soon.

[caraya]

@pento the site is https://publishing-project.rivendellweb.net/

I have a ticket open with Cloudflare on this issue. I have not had an ETA for resolution, but more pressure doesn't hurt :)

[kesenwang]

How is this issue closed? I’ve disabled both rules in Cloudflare Pro plan and the rules are still blocking the Rest Api

[pento]

@kesenwang: The firewall log should indicate which rule is blocking requests: could you have a look and see which one it is?

[mikepinto81]

Don't use cloudflare. Use Siteground. Have this issue. Disabled ALL plugins. Use default Wordpress theme.
Console shows this error:
POST https://tcwprintshop.com/wp-json/wp/v2/posts/1326 403 ()

Network shows similar 403 error:
1326 | 403 | fetch | index.js?ver=1536783125:1

[caraya]

@mikepinto81 do you run a firewall? Do your server logs report anything else other the 403 error? This may or may not be a Gutenberg problem so the more information you can add to the report the more it'll help troubleshoot.

[mikepinto81]

I actually had Siteground look into it and they couldn't figure it out (after elevating the issue) and said to contact the plugin author. There are no errors in the server logs and I do not run any type of firewall (that I know of unless siteground does by default?) I forgot to add that Pages update and post JUST FINE. It is ONLY posts that have the problem when Gutenberg is active. They update fine when Gutenberg is disabled.

---

From: Carlos Araya [e-mail]
Sent: Thursday, September 13, 2018 3:43 PM
To: WordPress/gutenberg
Cc: mikepinto81; Mention
Subject: Re: [WordPress/gutenberg] CloudFlare blocking REST API PUT Request (Draft Doesn't Get Saved) (solved by an update from Cloudflare) (#2704)

@mikepinto81https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmikepinto81&data=02%7C01%7C%7C8626e1a0d9294dbfa7c008d619b11e16%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636724645829338048&sdata=0oQZtXXe7Qy1HCFLSq5SmL0KrgeaZMryfEsuSYBcAvw%3D&reserved=0 do you run a firewall? Do your server logs report anything else other the 403 error? This may or may not be a Gutenberg problem so the more information you can add to the report the more it'll help troubleshoot.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FWordPress%2Fgutenberg%2Fissues%2F2704%23issuecomment-421128678&data=02%7C01%7C%7C8626e1a0d9294dbfa7c008d619b11e16%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636724645829338048&sdata=aydSF1xNtuzrLSP0T8ds5TOTNJQMrOLZ37Cox%2FXgDuI%3D&reserved=0, or mute the threadhttps://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAKztPgeSvV4xJKIe3cVR-pTiY7qR37oJks5uarVFgaJpZM4PRCw1&data=02%7C01%7C%7C8626e1a0d9294dbfa7c008d619b11e16%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636724645829338048&sdata=4d%2BgVDPkY7u2sfM78o183gTvJwiOZ%2BPN%2F1loiZ%2Bz9zE%3D&reserved=0.

[JustinSainton]

@mikepinto81 Have you looked at your htaccess file? See my similar issue here: https://github.com/WordPress/gutenberg/issues/2704#issuecomment-329231370

[mikepinto81]

@JustinSainton unfortunately we even tried resetting to default htaccess and no difference. What is really confusing is how this only affects Posts and not Pages.

[Tomplanmytrip]

Hey Guys!

I'm using Cloudflare Pro and Gutenberg

I disabled WP0025A and WP0025B as they recommend but it's still not working

I've the same pb than Caraya

Rule ID | Action Taken | IP Address | Loc. | Host | Date |  
-- | -- | -- | -- | -- | -- | --
100030 | Challenge | www.tomplanmytrip.com | 22 minutes ago | Details

Any updates?

Thx!

[pento]

Thank you for the info, @Tomplanmytrip. Rule 100030 is intended to block XSS probing attacks, it seems like Cloudflare is mistaking the post_content combination of HTML comments and serialised JSON as being an attempt to create an XSS attack.

This is going to be a little trickier to fix, I'll raise it with Cloudflare to get their input on it.

[Tomplanmytrip]

Ok thank you Pento :)

I've got the following mistakes in my developer tool

Failed to load resource: the server responded with a status of 400 ()

autosaves:1 Failed to load resource: the server responded with a status of 405 () -> I get the following message if I click on it: script>var wpgmza_google_api_status = {"message":"Enqueued","code":"ENQUEUED"}

start:1 Failed to load resource: the server responded with a status of 400 () -> I get the following message if I click on it: {"status":400,"error":"BadRequestError: Missing content-type"}

Is my plugin WP-map the problem?

Edit: Yes, Wp-Map is the issue. It works now. Any idea how to fix it?

Also, I have the similar problem If I'm using A getyourguide widget with the following code:

[pento]

I'd be interested to know if disabling a particular plugin makes the problem go away, but either way, we do need to figure out a way for Cloudflare to not be blocking legit requests. 🙂

[Gatewayy]

The only thing that has worked for me so far is to whitelist the IP from the WAF area of the Firewall settings from the CF web admin.

[caraya]

Do your web server error logs give anything related to this? I don't think this is a Cloudflare-related issue. I experienced it too but mine was caused by a mod_security my host did without telling me :(

[mikepinto81]

My issue I found was caused by the fact that I migrated the site from another install. The previous install had Wordfence installed and was using a php.ini var (auto_prepend_file). After uninstalling Wordfence I didn't realize there was still the php.ini file auto_prepend_file still pointing to the old install. This was causing the issue. I use Siteground and it took 3 different support people to help me hunt this down as for some reason the error logs were not giving hints to where the block was coming from.

[Tomplanmytrip]

@Gatewayy Thx :) Do you mean I should Whitelist my IP?

Also, WP-Map wasn't the only problem.

1 hour later, I couldn't update my post, neither use the autosaves. So I lost my post. I uninstalled Gutenberg for now.

@caraya - I dunno. Is it working now for you?

[caraya]

Yes, it did.

That's why I asked about your regular server error logs, it may say something other than Gutenberg or Wordpress related. If you can track the logs or have your host help you with that it might be helpful to troubleshoot the problem.

I would hold off whitelisting your IP (there will be many you'll have to whitelist if you choose to do so) until you test Gutenberg in your installation after the Wordfence fix.

Whitelisting all of the US as @gatewayy did opens your server all kinds of attacks. His issue is also specific to Cloudflare firewall so until you test and are sure it doesn't work, it won't be necessary to whitelist anything.

[moyvera]

@caraya please keep this thread updated if you have any news. I'm facing the same issue trying to use instagram embedded photos or something from a trusted source. It makes sense to block those requests for cloudflare but should be a section where we can add trusted sources.

[Related to XSS attack]

[bartclaeys]

Issue seems not resolved yet, I am experiencing it today with the latest Wordpress version:

• Wordpress: v5.0.1
• Cloudflare plugin: v3.3.2.
• Gutenberg plugin: v4.7.0

Update: Solved! Problem was caused by custom rule in .htaccess

[ensemblebd]

I have read in several places that the fix is to use a paid ssl cert from cloudflare, not their universal free one.
I'm unsure how precisely that correlates.
My site doesn't have an htaccess rule to remove that would resolve this. httpd.conf is standard as well.
And I do not have any firewall rules, page rules, or other non-basic settings in the pro cloudflare account.
Turning off cloudflare's DNS for the site at a whole doesn't even solve the issue.

Am not using the CloudFlare wordpress plugin.

Server response headers still indicate a cloudflare response:

cache-control: no-cache, must-revalidate, max-age=0
cf-ray: 48b2d7269******-DFW
content-encoding: br
content-security-policy: upgrade-insecure-requests;
content-type: text/html; charset=UTF-8
date: Tue, 18 Dec 2018 16:00:09 GMT
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
expires: Wed, 11 Jan 1984 05:00:00 GMT
link: <https://some.website/wp-json/>; rel="https://api.w.org/"
server: cloudflare
status: 404
vary: Accept-Encoding,User-Agent

[ensemblebd]

For the api request:
POST -> /wp-json/wp/v2/pages/1234 (page/post update operation, note: autosave has the same issue)

Problem is here:
/<root>/wp-includes/rest-api.php for rest_api_loaded() on Line 274
It exits immediately due to:
if ( empty( $GLOBALS['wp']->query_vars['rest_route'] ) )

Therefore the request never executes.
Contents are:

["query_vars"]=>
  array(2) {
    ["attachment"]=>
    string(2) "v2"
    ["pages"]=>
    string(4) "1234"
  }
  ["query_string"]=>
  NULL
  ["request"]=>
  string(24) "wp-json/wp/v2/pages/1234"
  ["matched_rule"]=>
  string(30) ".?.+?/([^/]+)/pages(/(.*))?/?$"
  ["matched_query"]=>
  string(24) "attachment=v2&pages=1234"
  ["did_permalink"]=>
  bool(true)

On a working site, it looks like this:

["extra_query_vars"]=>
  array(0) {
  }
  ["query_vars"]=>
  array(1) {
    ["rest_route"]=>
    string(16) "/wp/v2/pages/857"
  }
  ["query_string"]=>
  NULL
  ["request"]=>
  string(23) "wp-json/wp/v2/pages/857"
  ["matched_rule"]=>
  string(14) "^wp-json/(.*)?"
  ["matched_query"]=>
  string(33) "rest_route=/wp%2Fv2%2Fpages%2F857"
  ["did_permalink"]=>
  bool(true)

Am working on digging deeper. Would appreciate any insights from those that know what they're doing.

• Edit:
  Solution was to modify the wp_options database table value for option_name = 'rewrite_rules', simply moved the offending serialized regular expression below the position in the array of the wordpress default api routes.
  I tried flushing, both using this, and this, and by using the frontend permalinks [Save Changes] op. To no avail. Had to manually modify it myself in the database.

[mike-pt]

I'm not sure what changed but I had to whitelist a few rules and yet this still is getting blocked now it the following rules::

And was worst before:

I can't simply go about disabling every of this rules, most are not even listed as possible false positives :/

[mike-pt]

Aslo the draft is autosaved, its only updating that fails now

[caraya]

@mike-pt do the Cloudflare error logs show anything? how about the server logs? Check that before disabling rules as it may not be the reason why it's not working.

Try disabling your plugins and test if it works.

If it does try activating the plugins one by one until it stops working.

If it doesn't then developers will need logs from Cloudflare and your server to see if they can troubleshoot it further.

[mike-pt]

Error logs from cloudflare? I don't think they provide that, however I have pasted the screenshot from cloudflare blocking this, and I do see a 403 on the browser none of this are the WP WAF rules, but OWASP, and a lot of those are not common false positives!

This as to do with how gutenberg uses the JSON API when updating posts, so maybe the problem is on the API side still it hits at least the rules I've pasted above! I don't think plugins have anything to do with this, since its clear that the request is made when using gutenberg, as a workaround the classic editor is in use, no issues there!

[caraya]

It's the Web Application Firewall event log, not error log, my bad.

• Under Firewall scroll down
• Select Web application firewall
• Look at the Firewall Event Log.
• Does it report anything under that tab that doesn't appear in the images you pasted?

If the JSON API is not working that's usually a WAF issue, not IP firewall issue. At least it was for me before the Gutenberg team solved it. It may also be related to PHP Security plugins that are blocking things without you realizing they are (this has also been reported as an issue in this and other threads)

[mike-pt]

Yeah and that's exactly what I've pasted above... I never mentioned IP blocks only WAF rules.

This still happens, I have to disagree on the PHP security plugins cause the screens I posted are from Cloudlfare WAF log and its clearly blocking things, based on a few OWASP rules (note that none are from the Wordpress specific rules in this screenshot)

[mike-pt]

@caraya I feel like you took this too personal, I'm not rejecting any solutions (but so far no solution was really provided, but you did provide useful opinions on possible issues that could be related, and let me thank you for that).

With that sad if I disagree with something and provide an explanation as to why I don't see why that means I'm disagreed in every possible solution, and if it felt like so that was surely not my intention, I do have the right to disagree and I think it would be unfair to not be honest about it, now obviously there needs to be a reasoning for it and I did provide it.

Now still back to the PHP security Plugins, the screens I posted are from cloudflare, NOT wordpress, cloudflare is blocking the request based on the rules I've posted as a screenshot, the request doens't even get to the host, so how could a php security plugin do it?

I'm happy to share more examples / more details on what cloudflare is blocking to try to understand the problem.
Cause really my question is only about WHY this requests are blocked and match this many WAF rules, is many cloudflare being nuts and the plugin is not really "doing anything wrong" or are this actually legit and the way gutenberg does the update (via the API should be more safe) ?
That's the real question here, we are still in the phase where I'm just want to clarify why cloudflare blocks it (which again might even be a cloudflare issue not gutenberg) .

P.S. If you felt offended at any point it was honestly never my intention, I simply was replying directly and honestly to you're comments, I hope this helps clarify things!

[caraya]

@mike-pt

If you follow these and other issues with the plugin not updating you'll see that there are multiple reasons why this happens. Your screen is not what I expect to see when I troubleshoot this type of issues and I don't think I mentioned you're disagreeing, it's your right :).

Since you've confirmed that this is the web application firewall then, to me, it's a new error but, like the others, I'm guessing it doesn't like the way Gutenberg is mixing comments and JSON and considers it an attempt at SQL injection. So yes, it's likely that new modsecurity rules are making it not work but I'm surprised other people are not having the same issue... it still may be something being injected between your client and the firewall (ads, malware, long etc)

@pento

This is a new type of WAF error in Cloudflare, It's reporting a different type of error for protection against SQL injection but it's none of the previously reported errors. It is triggering OWASP core rules, specifically something in the APPLICATION-ATTACK-SQLI group of rules (Github link),

Don't know why it would be triggering now, but Cloudflare uses OWASP as their default module

[mike-pt]

To clarify that screen is form:

Firewall Event Log

Requests affected by both IP Firewall and Web Application Firewall (WAF) rules.

[From Cloudflare] After selecting the corresponding block.... I did crop it to filter out the IP etc... and simply show the "triggered/matched" rules.

But yeah what surprised me is that cloudflare lists APPLICATION-ATTACK-SQL (and this didn't not happen in past releases, unfortunately I can't say precisely when, I test gutenberg when it was beta and it trigger some cloudflare WordPress specific waf rules, which back then was their own issue and they fixed ) and after updating this WP install, changing form classic editor to Gutenberg this start happening, but with the rules that are posted, and as you say are core OWASP rules!
So it seems to be a bit more serious (or maybe cloudflare bug!?!), so I defiantly appreciate if someone can look into it and make sure all is good. And I'm also surprised no one else commented with the same results yet.

Also I haven't tried gutenberg again after the day I posted this, it was disabled in the prod but I should probably check again if this is still happening to clear out the possibility of a cloudflare bug analyzing this.

[jordif]

Hi,

I'm facing the same issue with Cloudflare and the OWASP ruleset. If i turn the OWASP rule set off (while keeping the Cloudflare rule set on), everything works fine.

I've done some tests adjusting the OWASP sensitivity (high/medium/low): the longer the post content, the greater the chances of the request being blocked.

I haven't really tested this super thoroughly, but I also think that having a lot of markup increases the chances. I had a page with a table and many links in it. I could not update it (OWASP rule was triggered). After cleaning it up a little bit (removing target="_blank" an rel="noopener" from the links) it did get saved.

Cheers,

[jordif]

I have noticed something else: autosaves do work (and the json is almost the same), it's the publish/update request that gets blocked...

[mike-pt]

@jordif out of curiosity which rules does it it for you?

[jordif]

@mike-pt Mainly "SQL Injection" and "XSS attack" rules.

It seems the OWASP team are already aware of this and working on a solution.

https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/1232

So I'm afraid we'll have to wait (and whitelist IPs in the meantime)

[ausworkshop]

Hi Guys, any news on this?
I haven't been able to edit or preview since Guttenberg came along and really messed up my life.
I'm with Cloudflare and WpEngine, was chatting to them for about an hour last night then today found this post. In the meantime I still have no idea how to fix or if it will one day fix itself. So after 15 years with my website I now can no longer edit it or update it but hey at least it's still working for now!

I have a business to run, it relies entirely on my website working and don't have time for all this tech stuff slowing me down all the time. I've almost lost hope in WordPress altogether after the trouble I'm having now and I really can't afford to have my site totally re-built on another platform. It's times like these I wish I was still using a simple Godaddy builder or something. I can't afford the amount of time I'm spending on WordPress just to keep it working. I don't ask too much, just a simple site that I can edit and update. What year are we living in?

Any advice or direction on what I need to do or who I need to reach out to for help would be appreciated. Or should I just go back to classic and forget about Guttenberg until it works one day with my existing setup? If Cloudflare are still working on it then how much longer will it take?

[ensemblebd]

All this banter about the politics of problem solving and who is to blame is ridiculous.
This is GitHub, not youtube.
People writing drivel on here does nothing but hurt people like @ausworkshop

The problem is that Gutenberg has an absolutely useless generic error message, offering a wide array of solutions.

Identification of issue

1.) Identify the network request in Chrome developer console (big red line).
2.) Copy the url it requested into your web browser.
3.) 500? 403? 401?
4.) Is it wordpress derived, or external (cloudflare)?
4.1.) Look at Step 1's network response headers. Do you see Apache, PHP, or IIS headers from your server? How about the CF ray?
--> If no: Turn off cloudflare (DNS level or global switch on dash, and disable firewall). Recheck 1-5.
--> If yes: Problem _very likely_ has nothing to do with cloudflare (as was my case).
Why not edit your index.php and throw out a header() call followed by a die() temporarily to verify (against same previously failed url)?
That by itself verifies your entire host apparatus (web.conf / htaccess rewrite, cloudflare dns + firewall + routing, php)
For POST op requests, use Postman. Same process.

Recap

To clarify, this is a closed issue, and you likely will not find help on here.
Plus the original issue was resolved long ago.

But the above generic self-help debugging steps are a first step to identifying the actual problem for Gutenberg's useless error message.
Good luck

[ausworkshop]

Thanks ensemblebd, I've passed your debugging steps on to WPEngine who were looking into it further for me and have opened a support ticket. I'll get back on here and let you know if I find out what they did to solve it.

[scottishstoater]

@ausworkshop Did you ever get this sorted? I've been working with WPEngine for over a month on the exact same problem.

[ausworkshop]

I'm not sure if it was ever fixed sorry, don't think so, I've been struggling along with the classic editor, stopped using Gutenberg months ago but I am planning to build a whole new site using Beaver Builder, even that I'm struggling with. Sick of trying to get my head around all this crap. Here I am at midnight trying to work out how to import and display custom post types in a new theme. I had to hire someone in the end. I'm hopeless with all this and it never seems to get easier, just more confusion and more expenses. Was quoted $6k to fix my site, I refused so am doing it all myself. Wish me luck! :) Have fun people.