Closed KristinaKay closed 3 years ago
Thank you @KristinaKay ! 🎉
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:
current_user_can
permissions check. It made me think it was cookie-related and I assumed it was related to the iframe. Most screenshots of the problem show the wordpress.com/block-editor
URL (indicating the iframe was in use), but there was an example where the error looked like it was from wp-admin
, which would rule out the iframe theory.@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?
@blackjackkent can you take a look at this please? 👍
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)?
I did a quick search and found the following cases too:
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:
PUT
/POST
request to /wp/v2/posts/:post-id
when a user publishes/updates a post.
<ACTION> failed
message (e.g. "Publishing failed") plus the error message returned by the API endpoint.
/wp/v2/posts/:post-id
endpoint is handled by WP_REST_Posts_Controller
.
PUT
/POST
requests are validated by update_item_permissions_check
.
update_item_permissions_check
returns a Sorry, you are not allowed to edit this post.
error if check_update_permission
returns a false value.
check_update_permission
returns a false value when any of the check_is_post_type_allowed
or current_user_can
checks fail.
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.
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)
Update: They said that using Incognito in Chrome they could not reproduce the error after trying a few pages.
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.
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
.
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!
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?
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.
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
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/
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
Also reported in https://twitter.com/ExtraInningsUK/status/1312832178670178304
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
Got 2 today in the PT-BR forums, we have followed up asking details:
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!
24651537-HC. Troubleshooting data is in the transcript.
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.
Well, I have audited the demographics data https://docs.google.com/spreadsheets/d/1dcsU96Q7ChdQGnest975BLG5HBXmysSPkQ6dEN0d-iU/edit?usp=sharing
Some Notes:
Starting on July 14, cookies that don’t specify a SameSite attribute will be treated as if they were SameSite=Lax. Cookies that still need to be delivered in a cross-site context must explicitly request SameSite=None. Cookies with SameSite=None must also be marked Secure and delivered over HTTPS. To reduce disruption, the updates will be enabled gradually, so different users will see it at different times. We recommend that you test critical sites using the instructions for testing.
/trunk/public.api/rest-proxy/index.php#57
and as it seems HTTP_USER_AGENT
may be empty by some client configurations or firewallsDeployed r214767-wpcom to fix https://github.com/Automattic/wp-calypso/issues/45881#issuecomment-704125015
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
Ended up working for them in Firefox.
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
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
Setting the wp_api_sec
SameSite
attribute to ` or
Strictinstead of
None in
trunk/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 from
https://wordpress.com/block-editor/post Also, If the
wp_api_secis not set or has wrong value, you cannot reach the edit page. Even if you reach it from
wp-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
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.
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.
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.
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.
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.
@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
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.
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.
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
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).
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
Anohter in 22980354-hc.
Publishing failed. Sorry , you are not allowed to edit this post.
Clearing cache helped.
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.
Deployed D50934-code in r215043-wpcom which adds the following to logs:
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.
@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.
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.
Another case with no mapped domains, though they do have a Jetpack site: https://wordpress.com/forums/topic/updating-failed-18/
fixed: clearing cache and cookies, logging out and in fixed it
7334351-hc
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.
Another report - #6653175-hc
Clearing cookies and cache fixed it.
@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.
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. Ifwp_api_sec
is set and valid it will have the user id as value. If not valid it will havefalse
as value. The rest cookiesfalse
values are a side effect only.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.
23849977-hc, #24239938-hc - Scheduling failed. Sorry, you are not allowed to edit this post.”
3254656-zen: “Scheduling failed. Sorry, you are not allowed to edit this post.” error as shown in this screenshot: https://d.pr/i/QncCb4/VxdNKTS4Xi
https://wordpress.com/forums/topic/red-line-says-updating-failed-sorry-you-are-not-allowed-to-edit-this-post/
23849977-hc: “Sorry, you are not allowed to edit this post” as shown in this screenshot: https://d.pr/i/Xt7KAf
3299020-hc – “Sorry, you are not allowed to edit this post”
3302662-zen - “Sorry, you are not allowed to edit this post”
Social Post 1
Social Post 2
3315500-zen - Only occurring in Edge and not Chrome.
24239938-hc - They used Chrome and tried clearing cache in Chrome but the issue persists. It works when they used Firefox though.
11163274-hc I can’t get my blog posts to update or save- I can’t get HTML blocks to show up. I keep getting the message that I am not allowed to edit something when I am the only person who does have permissions for this site. It deletes my work and won’t save. This is not a common error message.”
Error: “Updating failed. Sorry, you are not allowed to edit this post.” Domain: (unspecified, presumably multiple sites as this user has many, but I’ll ask) Ticket: https://wordpress.com/forums/topic/block-editor-preventing-me-to-publish-as-usual/ Browser: Chrome Theme: (unspecified) Plan: Free
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?
3340559-zen - Clearing cache works immediately – but the problem keeps recurring regularly.
They also report this happening more widely with people they know:
@davemart-in @cathymcbride