Automattic / wp-calypso

The JavaScript and API powered WordPress.com
https://developer.wordpress.com
GNU General Public License v2.0
12.42k stars 1.99k forks source link

Editor: Permission Errors when trying to Update/Publish Post/Pages #45881

Closed KristinaKay closed 3 years ago

KristinaKay commented 4 years ago

We are receiving several reports of customers getting errors when trying to update or publish posts/page. Initial P2 #p2EDhh-19p-p2

HEs Warning P2: p7DVsv-9vm-p2

Systems P2: pMz3w-c2B-p2

Demographics: https://docs.google.com/spreadsheets/d/1dcsU96Q7ChdQGnest975BLG5HBXmysSPkQ6dEN0d-iU/edit?usp=sharing

Logging added here: D50847-code and D50934-code Logs: in kibana for feature : update_item_permissions_check_failure If a cookie is not set, it will not appear. If wp_api_sec is set and valid it will have the user id as value. If not valid it will have false as value. The rest cookies false values are a side effect only.

Screen Shot on 2020-11-09 at 16:06:11

Steps to reproduce

It's hard to say as all cases are different and not necessarily corrected in the same way. I am adding the comments from the original P2 here to have it all in one place.

https://wordpress.com/forums/topic/red-line-says-updating-failed-sorry-you-are-not-allowed-to-edit-this-post/

Action: since they’re having issues with “liking” posts, too, I’m wondering if it’s a login issue. I’m having them log out, clear cache, and log back in to see if that will help.

Otherwise, is this related to samesite browser cookie changes?

They also report this happening more widely with people they know:

This is not a solitary issue with just my blog. I run a group that attempts to post daily in November and the current problems makes it almost impossible to think about attempting this on the WordPress platform. A blogger in that group who is open to their blog being examined over this recurring error is behindthewillows.com.

@davemart-in @cathymcbride

cathymcbride commented 4 years ago

Thank you @KristinaKay ! 🎉

pablinos commented 4 years ago

I had a brief look at this earlier as it seems to have come up since the editor deprecation, so I wanted to see if it was something directly related to that. I can't rule it out, but my feeling is with more use of the block editor by people that have been using the Calypso editor, we're hitting a particular state more frequently, rather than it being related to the deprecation process itself.

Some things that came up as I looked at it were:

davemart-in commented 4 years ago

@kwight I just moved this to the urgent bugs list. Can we time box investigation into this bug to 2-4 hours to start and see where that gets us before proceeding?

kwight commented 4 years ago

@blackjackkent can you take a look at this please? 👍

KristinaKay commented 4 years ago

24378843-hc : Permissions error when trying to alter home menu. On Chrome; Business Plan, Clearing browser cache worked.

blackjackkent commented 4 years ago

I wasn't able to make much headway on this today, unfortunately. I have not seen the bug reproduce for me at all. Digging into the code definitely shows what @pablinos already said -- that it's specifically related to the edit_post permission being verified by current_user_can -- although there's also one other scenario where that message crops up:

/wp-admin/includes/post.php

function post_preview() {

    $post_ID     = (int) $_POST['post_ID'];
    $_POST['ID'] = $post_ID;

    $post = get_post( $post_ID );
    if ( ! $post ) {
        wp_die( __( 'Sorry, you are not allowed to edit this post.' ) );
    }

However this doesn't seem applicable to all the cases mentioned above.

The person mentioned in the original post with issue #3340559-zen says this is happening pretty regularly to them; would it be possible to get a screen recording of their usage so we can get a stronger sense of the context it's happening in (re: iframe vs not iframe, etc)?

KristinaKay commented 4 years ago

I did a quick search and found the following cases too:

mmtr commented 4 years ago

I took a look at this today but couldn't find anything that explains why users are getting this error.

Looks like we need to focus on the check_update_permission function of the WP_REST_Posts_Controller class, which I think is aligned with what's been said above:

I audited all the user_has_cap and map_meta_cap filters we have in WP.com that could change the behavior of the has_cap check done in current_user_can, but everything looked fine.

Without reliable steps to reproduce this issue, I don't know what are the next steps we should take. A screen recording as @blackjackkent suggested may be helpful.

We could also launch a support session for one of the affected users and see if that helps identifying the issue. But given the issue only happens when saving a post we should let them know beforehand, otherwise they can get confused if they see the post updates done during the support session.

dcoleonline commented 4 years ago

24409314-hc: "Updating failed. Sorry, you are not allowed to edit this post."

I couldn't replicate the issue. I made a small change to the page to test it as the user. They were able to undo my change without issue. Then they tried changing a different page and they got the error again.

They're using Chrome on Windows. 85.0.4183.102 (Official Build) (64-bit) (cohort: Stable)

image

Update: They said that using Incognito in Chrome they could not reproduce the error after trying a few pages.

mmtr commented 4 years ago

Since the issue seems to point there is a cookies problem, I analyzed the cookies we use when making a request to the API, and found out that when the wp_api_sec cookie is missing / has expired / contains an invalid value, the API returns a "Sorry, you are not allowed to edit this post." error.

Screen Shot 2020-09-28 at 13 19 37

I confirmed it by manually deleting the cookie using the Chrome dev tools. Reloading the editor always brings the cookie back for me. Would it be possible to ask users to provide an screenshot of the browser dev tool showing the wp_api_sec cookie stored for the API? In Chrome this can be done by opening the menu and then going to More tools > Developer Tools > Application > Storage > Cookies > public-api.wordpress.com.

pablinos commented 4 years ago

when the wp_api_sec cookie is missing / has expired / contains an invalid value, the API returns a "Sorry, you are not allowed to edit this post." error.

Yes, this is the case, but the thing I can't understand is why? How has someone got a valid auth cookie for wp-admin (and so can load the editor) but not for the API?

My latest hunch is that changes to how the cookie is set for the SameSite/Secure third party cookie change, means that an old cookie is seen as valid by our code (it exists etc.), but isn't being passed to the API for some reason - perhaps related to the editor loading in an iframe. This would be strange as they're all on the .wordpress.com domain, but might be worth testing - it's conspicuous that these problems with cookies have occurred during the rollout of that change to browsers.

Would it be possible to ask users to provide an screenshot of the browser dev tool showing the wp_api_sec cookie stored for the API?

Good idea, but be careful with this, we don't want to expose those cookie values!

mmtr commented 4 years ago

How has someone got a valid auth cookie for wp-admin (and so can load the editor) but not for the API?

My latest hunch is that changes to how the cookie is set for the SameSite/Secure third party cookie change, means that an old cookie is seen as valid by our code (it exists etc.), but isn't being passed to the API for some reason

The cookie is only valid for 2 days, but it gets extended with every request to the API. Maybe there are some users who keep the editor opened for more than 2 days but without any interaction at all, so there are no API request extending the cookie expiration?

pablinos commented 4 years ago

Potentially! Anything is possible I suppose. People are logging out and back in, and it's still not working though.

Perhaps there's something about the cookie expiring which means it doesn't get reset properly in that instance, but in all my tests it was deleting the cookie correctly when I logged out.

Most of the screenshots have the editor loaded from /block-editor which suggests they have come via Calypso, so I would have thought a problem with the API would have affected them before they got to the editor. It's definitely a strange one.

If it was related to the third-party cookies change, then perhaps the old cookies were functioning correctly in Calypso, but become invalid when used in the editor iframe. These old cookies without the SameSite/Secure settings, would get their expiration extended as they used Calypso, but would stop working in the editor. I think I'll see if I can get a cookie set on the API without the SameSite settings, and see how it behaves.

smithkyle45 commented 4 years ago

24579192-hc reported the same issue with “Sorry, you are not allowed to edit this post”

Suggested clearing browser cache as a temporary workaround

Follow up ticket: 3370352-zen

supernovia commented 4 years ago

Just noting in this case, the user realized something was going on with her antivirus and cookies. https://wordpress.com/forums/topic/sorry-you-are-not-allowed-to-edit-this-post-2/

rootjosh commented 4 years ago

We've got a number of these popping up in the forums and social media

https://wordpress.com/forums/topic/new-wordpress-editor-5/ https://wordpress.com/forums/topic/i-am-locked-out-of-my-blog-4/ https://twitter.com/landdnet/status/1312476035842154496 https://twitter.com/NathanBurgoine/status/1311267435765526528

jerrysarcastic commented 4 years ago

Also reported in https://twitter.com/ExtraInningsUK/status/1312832178670178304

cpapazoglou commented 4 years ago

I have posted a P2 p7DVsv-9vm-p2 to raise HEs awareness and collect some feedback. Next steps: 1) Collect some demographics about users / sites in conjunction with evidence collected 2) Add an error logging mechanism that will log the cookies currently set

carinapilar commented 4 years ago

Got 2 today in the PT-BR forums, we have followed up asking details:

cpapazoglou commented 4 years ago

Seems that this page https://wordpress.com/support/third-party-cookies/#checking-your-browser reports false - positives

Since HEs use it p7DVsv-9vm-p2#comment-31705, I have prepared a fix D50694-code here in case someone can accept it!

inaikem commented 4 years ago

24651537-HC. Troubleshooting data is in the transcript.

RealCarFax commented 4 years ago

24369746-hc

Chrome Version 85.0.4183.83 (Official Build) (64-bit) on Windows 10. First noticed the issue today. They log in through email with password. No Antivirus, using a wireless network.

Incognito browser window in Chrome worked for them.

cpapazoglou commented 4 years ago

Well, I have audited the demographics data https://docs.google.com/spreadsheets/d/1dcsU96Q7ChdQGnest975BLG5HBXmysSPkQ6dEN0d-iU/edit?usp=sharing

Some Notes:

cpapazoglou commented 4 years ago

Deployed r214767-wpcom to fix https://github.com/Automattic/wp-calypso/issues/45881#issuecomment-704125015

tbradsha commented 4 years ago

Occurred in 16073465-hc.

• Chrome 85 + Windows 10 • Logs in with a password • Happens on all their sites • No VPN/proxy • All browser extensions deactivated

eoinsav commented 4 years ago

21107819-hc

Ended up working for them in Firefox.

rickmgithub commented 4 years ago

4469847-hc

3383388-zd

Permission error when trying to add images in Chrome. Works fine in Safari No images appearing in their media folder now either Screenshot links in #3383388-zd

fresatomica commented 4 years ago

Another report: https://wordpress.com/forums/topic/updating-failed-sorry-you-are-not-allowed-to-edit-this-post-8/ User logged in with the password on desktop, no VPN nor proxy, Sophos AV not blocking cookies. The issue appeared during the past weekend. Chrome 85 on macOS (High Sierra). Console errors: https://snipboard.io/gw1P8y.jpg

cpapazoglou commented 4 years ago

Case 1: third party cookie problem

Setting the wp_api_sec SameSite attribute to ` orStrictinstead ofNone intrunk/public.api/rest-proxy/index.php#73doesn't create any problems to me (with third party cookies disabled) ![](https://cln.sh/VmPr8q+) I can save posts with success fromhttps://wordpress.com/block-editor/post Also, If thewp_api_secis not set or has wrong value, you cannot reach the edit page. Even if you reach it fromwp-admin` the page will not load and be blank.

So, this rules out the possibility of being a third party cookie problem not set. And also suggests that we need a valid wp_api_sec cookie to edit / create a page / post

Case 2: cookie being changed while user edits the page

Opening an other tab with any .wordpress.com/ domain OR previewing the page will result in wp_api_sec being set again. In that case, if the value is not set correctly (???) or the cookie gets deleted (eg user logs out) then user will not be able to edit or create a post on the open editor tab.

supernovia commented 4 years ago

Are there any other ways cookies could be getting deleted? I've seen some complaints where the user says this happens while they are editing the post, so is it possible the preview is breaking the cookie somehow? I unfortunately have not been able to duplicate this yet.

pablinos commented 4 years ago

Thanks for the investigation you're doing here @cpapazoglou. It's good that we can rule out a third party issue with the API cookie

I have audited the demographics data

This is very useful. One thing I noticed was that of the customers I checked, they all had multiple sites, and at least one of those sites had a mapped domain. That shouldn't matter because the API cookie is valid for all sites, but perhaps there's something in that. Maybe some combination of remote login and the third party cookie change?

The exception I can see to this is #3326321-zd, but the solution there was to create a new post, which suggests that maybe it was a different issue.

cpapazoglou commented 4 years ago

Thanks for chiming in @pablinos!

Maybe some combination of remote login and the third party cookie change?

What do we mean by remote login?

I am also thinking if a load balancer could temporarily assign a User to an other server and a miss-configuration leads to sessions being different.

pablinos commented 4 years ago

What do we mean by remote login?

When there's a domain mapped to a blog there is a 'remote login' flow that transfers the auth cookie to be valid for that domain as well as .wordpress.com. It works by redirecting them back and forth via wordpress.com with a nonce value. I'm not sure how to link to the code here but have a look at remote-login.php in the WordPress.com codebase.

I'm not sure how it could happen, but I'm wondering if they end up in a state where a cookie is valid for another site (which would potentially give them read permissions on the post they're editing on the current site) but when they go to save the post it fails as they don't have a valid cookie for updating the current site.

I don't think it would be possible to load the editor without a valid API auth cookie, so it's strange that it appears to be valid at the point the editor is loaded, but not when they save the post. Maybe it's a long-lived session that gets invalidated, but that should be solved by logging in again. The way the problem persists for people suggests that a cookie is passing a check in some contexts but not others.

I'm sure you've seen, but the editor loads from wp-admin which has a separate auth cookie to the API. There are two auth cookies for the site, the paths for which are wp-admin and wp-content/plugins. I was wondering if something was getting out of sync there, but with no way to reliably reproduce this, it's tricky to debug.

It was suggested that we put some logging of the cookies (but not their values!) at the point the error is thrown in the API, but we're not able to see the full picture at that point. Nevertheless, it's probably a good next step. It might give us some idea of how many people are affected by this too.

cpapazoglou commented 4 years ago

@pablinos

I'm sure you've seen, but the editor loads from wp-admin which has a separate auth cookie to the API. There are two auth cookies for the site, the paths for which are wp-admin and wp-content/plugins. I was wondering if something was getting out of sync there, but with no way to reliably reproduce this, it's tricky to debug.

From my tests, only the wordpress_logged_in and wp_api_sec not validating can return that error. I can't get an error when a cookie with path wp-admin or wp-content/plugins doesn't validate. I may be wrong though.

It was suggested that we put some logging of the cookies

In the quest to find data - solution I totally forgot the logging part.. I have created a patch here D50847-code

cpapazoglou commented 4 years ago

Deployed r214901-wpcom .

We can now have some logging in kibana for feature : update_item_permissions_check_failure

which I am going to make better tomorrow.

pablinos commented 4 years ago

We can now have some logging in kibana

Nice one! Hopefully that will give us some insights.

I can't get an error when a cookie with path wp-admin or wp-content/plugins doesn't validate.

Yes, that's sort of what I'm getting at, that maybe those cookies are allowing people to load the editor and start editing a post, but that the API cookie is broken. One of the odd things for me with this problem is that you shouldn't be able to load the editor with an invalid API cookie.

Let's see what the logging uncovers.

cpapazoglou commented 4 years ago

Found an interesting log on Oct 9

User 145369461 of blog 61029054 could not update a post

Cookies Set: wpc_wpc, wp_api_sec, tk_tc, tk_qs, _fbp, _derived_epik, _pin_unauth, _ga, _uetvid, _gcl_au, wordpress_eli, _wpndash, recognized_logins, wordpress_logged_in

cpapazoglou commented 4 years ago

User 145369461 has the role author on this site and they should be able to edit. wp_api_sec was correctly set (validation returned the user id).

dcoleonline commented 4 years ago

Another in 24744744-hc They got the error whenever they tried to underline text in a draft post. They also have multiple sites and were using Chrome on Windows

formosattic commented 4 years ago

Anohter in 22980354-hc. Publishing failed. Sorry , you are not allowed to edit this post.

Clearing cache helped.

liviopv commented 4 years ago

Another 3377979-zen not fully working even after the most recent merge.

Edit/Publish posts with just text work, but they see the same error when trying to add an image block.

The list of Notifications also never finishes loading.

cpapazoglou commented 4 years ago

Deployed D50934-code in r215043-wpcom which adds the following to logs:

cpapazoglou commented 4 years ago

I have updated the spreadsheet with some insights from the latest tickets. It seems as most of the users affected where using the deprecated editor.

Also, most (not all) failed attempts lack of wordpress, wordpress_sec, wp_api, wp_api_sec cookies.

I added a comment pMz3w-c2B-p2#comment-82907 regarding multiple hosts that server a single user in a short period of time.

cathymcbride commented 4 years ago

@liviopv if you have a repro on the list of notifications not loading, can you write that up separately? Especially if it reproes outside the context of this issue.

supernovia commented 4 years ago

Just noting another case here: https://wordpress.com/forums/topic/how-to-get-rid-of-this-message/

No mapped domains, but they do have a Jetpack-connected site.

supernovia commented 4 years ago

Another case with no mapped domains, though they do have a Jetpack site: https://wordpress.com/forums/topic/updating-failed-18/

kristarella commented 4 years ago

fixed: clearing cache and cookies, logging out and in fixed it

7334351-hc

sophiegyo commented 4 years ago

Another report in 3393437-zd. Site is Simple, has a registered (not mapped) domain. I've asked the user to clear their cache and cookies, log out and in, and ensure the browser accepts cookies.

yashitamittal11 commented 4 years ago

Another report - #6653175-hc

Clearing cookies and cache fixed it.

liviopv commented 4 years ago

@liviopv if you have a repro on the list of notifications not loading, can you write that up separately? Especially if it reproes outside the context of this issue.

@cathymcbride I haven't been able to reproduce it myself, but I'm asking the user for more info (if it's still happening, screenshot, browser info). If there's anything else that would be valuable to you, let me know.