"Updating Failed" message for autosaves when editing post (plugin conflict: Wordfence)

[xpconversions]

Describe the bug
While editing a post, I keep receiving a "updating failed" message.

NOTE: The post saves properly if I click "SAVE DRAFT".

To Reproduce
Steps to reproduce the behavior:

1. Edit any post
2. Notice that you will receive the message shown in the image above every couple of minutes.

Expected behavior
The post should update properly.

Desktop (please complete the following information):

• OS: Windows 7 (64 bit)
• Browser Chrome
• Version 68.0.3440.84 (Official Build) (64-bit)

Additional context

• Gutenberg version: 3.4.0

[abwdvm]

This is a issue I had. My fix was to edit my Cloudflare Firewall.

[youknowriad]

If it's a cloudflare issue, please let's close and consolidate in #8441

[Footprint-Addons]

I have the same problem but no cloudflare is activated. I'm using gutenberg 3.4 on WP 4.9.8.
Nothing to be found in the error logs, in the Chrome console every 10 seconds or so a 403 error.
Tried disabling several firewall rules of WP security, to no avail.
Tried on Chrome and Firefox using Windows 8.1.

[youknowriad]

@Footprint-Addons Can you paste the response of the 403 error. MAybe it's a security plugin disabling API endpoints or so?

[Footprint-Addons]

Hi @designsimply, you are right, it is the security plugin :
403 Forbidden
A potentially unsafe operation has been detected in your request to this site.
Generated by Wordfence at Mon, 6 Aug 2018

[youknowriad]

I'm closing this issue as there's nothing we can do in Gutenberg

• REST API shouldn't be disabled/altered. Security plugins should probably avoid doing that.
• Cloudflare issue is tracked in Preview opens and says "generating preview" forever (solved by an update form Cloudflare) #8441

Thanks for the reports

[Footprint-Addons]

OK, goodbye gutenberg then. I prefer safety.

[youknowriad]

@Footprint-Addons The issue is that the security plugins are too aggressive, it doesn't mean that Gutenberg is unsafe. And in the future I expect other Core Features than Gutenberg will rely on the REST API, so it's not a Gutenberg only issue. To be clear, these plugins shouldn't block the REST API in the first place.

Of course, it's your choice to use Gutenberg or not.

[Footprint-Addons]

@youknowriad, there are tons of articles out there warning about possible exploits of REST API. Are they exaggerating then?

[youknowriad]

@Footprint-Addons Yes they are. All websites nowadays use REST APIs. It's possible that in a previous version, there were an exploit somewhere but in general any raised security issues in WordPress in REST API or anything else is fixed ASAP.

[Footprint-Addons]

OK, I'll contact wordfence then. Thanks.

[Footprint-Addons]

Not only update , also autosafe and Publish, it is impossible to safe a new post.

[edemir206]

@Footprint-Addons did manage to solve this problem with wordfence ? I'm having exact same issue.

Edit: Solved by myself, the blocking config was in wordfence > Advanced Firewall Options > Show All Rules > Disable: auth-bypass WordPress 4.7.0-4.7.1 - Authentication Bypass: Page/Post Content Modification via REST API

 

[Footprint-Addons]

Nope, I tried another server and there it works. But I'll try your solution.

[Footprint-Addons]

OK, I disabled auth-bypass WordPress 4.7.0-4.7.1 - Authentication Bypass: Page/Post Content Modification via REST API but it doesn't do anything for me. Just when I wanted to install another plugin, I've got the answer from WordFence support. Setting WordFence to Learning mode, then testing saving solved the issue. Once the post is successfully saved, you can set it to Enabled and protected again.

[designsimply]

Copying another solution related to Wordfence that was posted in a different thread because it looks relevant and may be helpful for others:

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

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.

— h/t @mikepinto81 at #2704 (comment)

[daniellepinto81]

@designsimply thanks for the cross post. To clarify even more, check the php.ini is not using an auto_prepend from a previous install that is pointing to an old directory.