Wp-calypso: Editor: Permission Errors when trying to Update/Publish Post/Pages

[KristinaKay]

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.

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:

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]

Thank you @KristinaKay ! 🎉

[pablinos]

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:

• The message 'Sorry, you are not allowed to edit this post' is specifically related to the 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.
• As far as I can see the sites affected aren't Atomic, which made me wonder if it was related to authentication against the wp.com API.
• Of the customers I've checked, they all have multiple sites. I'm not sure if this is a factor, or if it simply shows they're actively posting.
• There are reports of people solving it by changing their password. Again this points to cookies, but I'm not sure why deleting cookies would not work when this does.
• The fact that the problem goes away and comes back for some people made me wonder about remote login, and whether an invalid cookie is being set, as they browse the frontend of a site. There's an old issue where it's possible to logout of a site, but not Calypso. Could this be a similar problem in reverse?

[davemart-in]

@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]

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

[KristinaKay]

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

[blackjackkent]

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]

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

• #3337918-zen
• #3330145-zen
• #3302641-zen
• #3326321-zen
• #3322122-zen
• #3300211-zen
• #3291027-zen
• #3299020-zen
• #3256787-zen
• #3268698-zen
• #3280738-zen

[mmtr]

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:

• Gutenberg makes a PUT/POST request to /wp/v2/posts/:post-id when a user publishes/updates a post.
  
  
  
  • https://github.com/WordPress/gutenberg/blob/6ade0d28a45e2bf6089a2ed33e2dcd354bb10003/packages/core-data/src/actions.js#L504-L508
  
  
• If the request above returns an error, Gutenberg displays a notice error in the editor.
  
  
  
  • https://github.com/WordPress/gutenberg/blob/bf0b8ab18f061bf1360171277769fd8fc7f6d0fc/packages/editor/src/store/actions.js#L265-L280
  
  
• The message of the notice error shown is a combination of a <ACTION> failed message (e.g. "Publishing failed") plus the error message returned by the API endpoint.
  
  
  
  • https://github.com/WordPress/gutenberg/blob/bf0b8ab18f061bf1360171277769fd8fc7f6d0fc/packages/editor/src/store/utils/notice-builder.js#L87-L120
  
  
• The /wp/v2/posts/:post-id endpoint is handled by WP_REST_Posts_Controller.
  
  
  
  • https://core.trac.wordpress.org/browser/trunk/src/wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php
  
  
• PUT/POST requests are validated by update_item_permissions_check.
  
  
  
  • https://core.trac.wordpress.org/browser/trunk/src/wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php?rev=48782#L108
  
  
• update_item_permissions_check returns a Sorry, you are not allowed to edit this post. error if check_update_permission returns a false value.
  
  
  
  • https://core.trac.wordpress.org/browser/trunk/src/wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php?rev=48782#L705
  
  
• check_update_permission returns a false value when any of the check_is_post_type_allowed or current_user_can checks fail.
  
  
  
  • https://core.trac.wordpress.org/browser/trunk/src/wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php?rev=48782#L1518
  
  

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]

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)

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

[mmtr]

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.

[pablinos]

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]

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]

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]

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]

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]

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]

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

[cpapazoglou]

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]

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

• https://wordpress.com/br/forums/topic/mensagem-de-erro-falha-ao-publicar-sem-permissao-para-atribuir-os-termos-fornecidos/
• https://wordpress.com/br/forums/topic/nao-consigo-postar-5/

[cpapazoglou]

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]

24651537-HC. Troubleshooting data is in the transcript.

[RealCarFax]

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]

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

Some Notes:

• The problem is certainly cookie related.
• Users who couldn't solve it by clearing cookies, had either Cookie Blocking Enabled OR the didn't correctly clear the cookies.
• Most of them are using Chrome 84, 85 which introduced the following.

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.

• We set the SameSite attribute conditionally /trunk/public.api/rest-proxy/index.php#57
  and as it seems HTTP_USER_AGENT may be empty by some client configurations or firewalls
• Although most of the users haven't reached us again after we provided a solution, it seems that the problem is intermittent and they may be clearing the cookies themselves every time.
• Most of the users are on Premium plan and they are particularly annoyed. @cathymcbride maybe we should follow up to offer a coupon and ask if problem is actually solved.
• Uses affected should also not being able to like or see the notifications panel which load from
  https://widgets.wp.com/ and obviously need a valid cookie.

[cpapazoglou]

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

[tbradsha]

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]

21107819-hc

• Chrome 85.0 on Mac OS X 10.15.6
• Logs in with a password
• No VPN/proxy
• No antivirus that blocks cookies

Ended up working for them in Firefox.

[rickmgithub]

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]

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]

Case 1: third party cookie problem

Setting the wp_api_sec SameSite attribute to or Strict instead of None
in trunk/public.api/rest-proxy/index.php#73 doesn't create any problems to me (with third party cookies disabled)

I can save posts with success from https://wordpress.com/block-editor/post
Also, If the wp_api_sec is 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

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]

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]

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]

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]

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]

@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]

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]

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]

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]

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]

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]

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

Clearing cache helped.

[liviopv]

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]

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

• browser
• url
• post_id

[cpapazoglou]

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]

@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]

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]

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

[kristarella]

• user: findyourinneranalog
• site: findyourinneranalog.wordpress.com
• domain: findyourinneranalog.com
• first noticed: 12 Oct 2020
• browser: chrome
• OS: Windows 10
• antivirus: thinks so, but not sure which one

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

7334351-hc

[sophiegyo]

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]

Another report - #6653175-hc

• user: chris98765
• site: michaels-story.blog
• browser: Chrome

Clearing cookies and cache fixed it.

[liviopv]

@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.

[sophiegyo]

Another report: 3816989-hc

Asked user to log out, clear their cookies and cache, and log back in again, but they left with no further response.

Edit: wow, this user doesn't even have a mapped domain on their site, it's a .wordpress.com address only.

[rickmgithub]

Report here
3394528-zd

https://whatismybrowser.com/w/R74DNDM

[pablinos]

Edit: wow, this user doesn't even have a mapped domain on their site, it's a .wordpress.com address only.

Yep, that one disproves most of my theories, as they only have a single site too.

I was wondering if it could be related to the JS from a particular theme/widget/plugin. I can't see anything in common about the sites affected by this problem at the moment. More investigation is needed!

[cpapazoglou]

Just checked:

• plugins shouldn't be an issue since most users are in Premium and below plans, where they cannot add plugins
• opened 4 random issues, with 4 different themes so themes shouldn't be an issue too

I think the only thing in common is that they were using the deprecated editor, here is an other example with the first User with Edge instead of Chrome
3400019-zd-woothemes

[adelineyaw]

24869654-hc
3405951-zen (follow up ticket)

Issue occurs on two simple sites intermittently.

I've asked the user to clear their browser's cache and cookies. And to try another device / browser but no luck. I'm unable to replicate the issue when I SU into the account.

[hacchism]

Another report: 23433772-hc

Asked the user to log out, clear their cookies and cache, and log back in again, but they left with no further response.

[pauloeaquino]

24877533-hc
I advised to clear cache and see how that goes, but user left. I had no issues saving/updating on my end

3166423-hc
I was unable to replicate the issue when SU. Clearing cache or trying a different browser did not help. Pushed to ticket in 3406703-zd

[nagpai]

https://toocoolformiddleschool.com

24877829-hc

Error: "The editor has encountered an unexpected error"

On clicking Copy error from Gutenberg:

TypeError: r is not a function
at https://c0.wp.com/c/5.5.1/wp-includes/js/dist/components.min.js:7:394527
at Vb (https://c0.wp.com/c/5.5.1/wp-includes/js/dist/vendor/react-dom.min.js:104:431)
at Xi (https://c0.wp.com/c/5.5.1/wp-includes/js/dist/vendor/react-dom.min.js:151:136)
at unstable_runWithPriority (https://c0.wp.com/c/5.5.1/wp-includes/js/dist/vendor/react.min.js:26:340)
at Ma (https://c0.wp.com/c/5.5.1/wp-includes/js/dist/vendor/react-dom.min.js:52:280)
at Yb (https://c0.wp.com/c/5.5.1/wp-includes/js/dist/vendor/react-dom.min.js:150:420)
at Ae (https://c0.wp.com/c/5.5.1/wp-includes/js/dist/vendor/react-dom.min.js:118:178)
at xi (https://c0.wp.com/c/5.5.1/wp-includes/js/dist/vendor/react-dom.min.js:39:146)

Works fine on incognito window.

https://whatismybrowser.com/w/WC2TWS7

[rinazrina]

Another report: #3371540-zen.
The user shared a video on how they reproduce the issue (see ticket notes). It works fine when they click Edit link from the front end and edit the post from there. It also works on WP Admin's Classic editor.

• Browser: Google Chrome Version 86.0.4240.75 (Official Build) (64-bit)
• 2-3 weeks ago
• They log in log in via username and password
• No VPN, no proxy, no special antivirus except the Microsoft standard.

[noahtallen]

I want to note that there was an issue we solved in #46475 where a specific data subscription would consistently fail. This meant that every time any data changed in any gutenberg data store, a certain error would be triggered. I believe that this caused many features in gutenberg to become buggy, specifically on Atomic sites while accessing the editor via Calypso.

That specific issue should now be fixed, but it is unrelated to the original issue here. Just wanted to include this since some reports could have gotten mixed into this issue.

See this thread as well: p1602727238248200-slack-create-gardeners

[galakhyati]

Got another case here: 24879211-hc, they shared the error they got on clicking on Copy Error button:

TypeError: r is not a function at https://c0.wp.com/c/5.5.1/wp-includes/js/dist/components.min.js:7:394527 at Vb (https://c0.wp.com/c/5.5.1/wp-includes/js/dist/vendor/react-dom.min.js:104:431) at Xi (https://c0.wp.com/c/5.5.1/wp-includes/js/dist/vendor/react-dom.min.js:151:136) at unstable_runWithPriority (https://c0.wp.com/c/5.5.1/wp-includes/js/dist/vendor/react.min.js:26:340) at Ma (https://c0.wp.com/c/5.5.1/wp-includes/js/dist/vendor/react-dom.min.js:52:280) at Yb (https://c0.wp.com/c/5.5.1/wp-includes/js/dist/vendor/react-dom.min.js:150:420) at Ae (https://c0.wp.com/c/5.5.1/wp-includes/js/dist/vendor/react-dom.min.js:118:178) at xi (https://c0.wp.com/c/5.5.1/wp-includes/js/dist/vendor/react-dom.min.js:39:146)

Shared the fix is deployed, and it can take some while for it to come into effect.

[pablinos]

I think the only thing in common is that they were using the deprecated editor,

Are we sure that's the case? It seems to be in the majority of cases, but 24579192-hc wasn't part of the editor deprecation group (so didn't receive our emails about the change). It could be that they used the Calypso editor more than a year ago (which looks possible). I'm not sure what about the editor deprecation could cause a problem with cookies, though.

The other thing I notice is that a lot of these people are returning after a period of inactivity. I'm wondering if the cookies were set before some change (perhaps the third party cookie updates) then perhaps they're not getting updated in some circumstances.

I'm seeing reports of it not working in wp-admin but working when they try in Calypso, which is strange. Any cookie issues I would expect to be related to the iframe. If authentication via the cookie fails for some reason it does get reset, so that could be the reason we're not seeing the wordpress_sec and wp_api_sec cookies on the failed requests.

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

Do we have any examples where the sec cookies are set, but the request is failing?

[cpapazoglou]

24877533-hc
I advised to clear cache and see how that goes, but user left. I had no issues saving/updating on my end

3166423-hc
I was unable to replicate the issue when SU. Clearing cache or trying a different browser did not help. Pushed to ticket in 3406703-zd

https://toocoolformiddleschool.com

24877829-hc

Error: "The editor has encountered an unexpected error"

24877533-hc, 3406703-zen, 24877829-hc Seems to have another problem. They get a blank / freezed page when they load the editor. They are on atomic. https://github.com/Automattic/wp-calypso/pull/46475 may have resolve the issues

[cpapazoglou]

Are we sure that's the case?

Hey @pablinos , it is more the fact that issues have emerged right after the deprecation. But I agree, I am not sure. It is true that a user 3371540-zd-woothemes had success through the block-editor but failed in wp-admin...

Do we have any examples where the sec cookies are set, but the request is failing?

No, all logs suggest that wordpress, wordpress_sec, wp_api, wp_api_sec cookies are missing.
Since wordpress_sec is missing, wp_api_sec cannot be set, so we now have to find why wordpress_sec is missing!

[supernovia]

Another report here.
https://wordpress.com/forums/topic/i-cant-add-a-page-like-i-use-to/#post-3578743

[lakellie]

Another report in 8919599-hc
Browser details: Firefox 81 on Windows 7

[druesome]

24655356-hc

[druesome]

20437344-hc

[kylemcph]

Another report: 3417101-zen

Asked the user to log out, clear their cookies and cache, and log back in again.

[rachelwinspear]

Report here: 3398051-zen
Browser: https://www.whatsmybrowser.org/b/WSOLE

[serabi]

Report here: 192163920-hc

[pablinos]

I've been doing some investigation into this, and the bit that's confusing me the most is that this problem seems to persist between reloads of the editor. I can break the cookies in some way but that will always be solved by a refresh, which will reset the cookies or redirect me to log back in.

@cpapazoglou Were you able to reproduce this in a way that it would persist between reloads of the browser?

[cpapazoglou]

I've been doing some investigation into this, and the bit that's confusing me the most is that this problem seems to persist between reloads of the editor. I can break the cookies in some way but that will always be solved by a refresh, which will reset the cookies or redirect me to log back in.

@cpapazoglou Were you able to reproduce this in a way that it would persist between reloads of the browser?

Nope, not really. The only way to _mimic_ the error is by firstly loading the editor and then changing if ( isset( $_COOKIE[SECURE_AUTH_COOKIE] ) ) { to if ( ! isset( $_COOKIE[SECURE_AUTH_COOKIE] ) ) { so that the wp_api_sec cookie gets cleared and you get the error when you click update / publish.

[pablinos]

Right, but once it's cleared then you are logged out. Refresh your browser and you'll be asked to log back in, or if there are cookies still set against .wordpress.com then we log them back into the API, and everything's fine. The reports here seem to have the editor consistently loading successfully, but that the save action on the API becomes unauthenticated for some reason.

There are many requests made against the API as the editor loads, and while it's being used. Why would this manifest only when someone goes to update or publish the post? Autosave requests happen around every 30 seconds. It would be interesting to know if the error is also appearing when that happens or if it only comes from an explicit click of the 'Update/Publish' button.

I'm wondering about whether we should get a HAR export from the network tab of an affected customer, but that's not particularly simple to walk someone through, and there are security implications, as it will have all their cookies in it.

[jonnyruzek]

3423097-zen

[ivan-ottinger]

Another report: 3412031-zen → I have suggested them to try a different browser and asked for details on their setup (browser version, ...)

[jonnyruzek]

Another report: 3412031-zen → I have suggested them to try a different browser and asked for details on their setup (browser version, ...)

User has replied in the ticket with the information requested.

[villanovachile]

Another report here: 3405308-zen

[jonnyruzek]

3429014-zen

[philnick206]

21102742-hc

[nagpai]

25089175-hc

Microsoft Edge 86 browser
https://www.whatsmybrowser.org/b/7R8KV

No ad blockers, Cookies enabled, JS enabled.

[pauloeaquino]

25090405-hc

I suggested to try clearing cache or edit on a different browser for now.

[bsanevans]

Another report 25113936-hc

After creating a new post, the user added a new Image Block. Selecting images from the Media work fine. But if the user goes to add an image from their computer, or drag-drops an image into the block, the editor says

Updating failed. Sorry, you are not allowed to edit this post.

And the image block says

Sorry, you are not allowed to create posts as this user.

Browser: Edge
We are in the process of clearing cache. (Follow-up: 3432655-zd-woothemes)

[bsanevans]

Another report: 3369575-zd-woothemes
Clearing the cache on Edge didn't work. Installing Chrome and logging into their account there did work.

[geekinthegirl]

Just had another issue here: 25142582-hc

User came across the 'Updating failed. Sorry, you are not allowed to edit this post.' error when trying to edit any post or page - specifically when using Chrome and running on PC (it seems to work fine on Mac). I suggested logging out and back in, but no indication of whether that worked for them or not.

[kdevnel]

Just noting this person that also had the issue. I've reached out to see if they're still having issues and to guage if they're in the mood to provide us any of the info you ask or maybe run the screenshare session with them. At this point, what information would you like us to get from them to help troubleshoot?

3440851-zd-woothemes

[pablinos]

I'm curious to understand if people seeing this issue can reload the editor and if it's just the updating/saving of the post that is not working. Looking at the reports it seems that it can persist between loads of the editor, but updating/saving the post fails. This suggests that there's a particular API call that is causing the issue.

If that's the case, then I think we need to find a way of getting a more detailed log for someone while they're stuck in this state. I was wondering about getting a HAR export from the network tab, but that seems laden with problems.

Could someone confirm that people are getting stuck not being able to update posts, but can otherwise load the editor, come in and out of editing posts etc.? Then we can work out toggling some detailed logging for these customers.

[chaitanyamsv]

@pablinos

Could someone confirm that people are getting stuck not being able to update posts, but can otherwise load the editor, come in and out of editing posts etc.? Then we can work out toggling some detailed logging for these customers.

I just confirmed with a customer in 25215346-hc. Customer gets Updating failed. Sorry, you are not allowed to edit this post. in Chrome and Edge even after clearing cache and cookies. They didn't find wp_api_sec cookie, but they found wordpress_test_cookie in their Chrome.

Their site is https://brianjump.net/

Could you suggest the next steps to toggle additional logging for this site?

[pablinos]

Thanks @chaitanyamsv We haven't got the additional logging in place yet, we'll have to add that.

Before clearing their cache and cookies were they still logged in? Could they load the editor and use Calypso? I assume they must have been, because they were still in chat. It seems odd that they were authenticated at all if they had cleared the cookies.

I'll see about how we might be able to get some more information for specific users.

[hacchism]

Another report: 12727590-hc
They were on Chrome. Clearing browser cache worked!

[jonnyruzek]

3449178-zen

Clearing cache did not work.

[ivan-ottinger]

Another report: 2383900-hc,

They were quite unhappy and didn't want to clear the cache to resolve the issue - since they are logged into multiple services and don't want to get kicked out.

I didn't ask them for details, as I didn't want them to become even more frustrated.

Browser: Chrome 86.0 on Windows 10.0.0.

They noticed the issue just today (October 30), but they don't post frequently. They were not able to do a site export either.

[rinazrina]

Another report: 25269983-hc

They're seeing Updating failed. User cannot access this private blog whenever they try to save a post as a draft or even try to publish it.

• Browser: Microsoft Edge
• They noticed the issue today.
• They're using password to log in as Administrator.
• Not using VPN, proxy, antivirus and all cookies are accepted.

It worked after they clearing cache and cookies.

[TeniCola]

Probable case in 156262-hc

They said they have a RST API issue on one of their posts. Saving and publishing their post via WP Admin seemed to work for them. No browser info was provided in transcript.

[blackjackkent]

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?

I don't know if anyone followed up on this possibility from @mmtr (and given that the issue seems to persist between reloads for reporting users, it may be a red herring) but on the off chance that it leads anywhere, I have a post editor open in a browser on my personal computer and will try to reproduce the issue later this week.

[dolgelukkig]

Another case #3458328-zd

They're on a Personal plan, browser is chrome, issue happens in Calypso and in wp-admin.

[pablinos]

(and given that the issue seems to persist between reloads for reporting users, it may be a red herring)

That's my feeling @blackjackkent. I think you could probably get it to fail on that basis, but I'm not sure if it would be reproducing this problem. It would be great if we could reproduce it though!

Another report: 25269983-hc

This one is interesting. The error message mentions that they haven't got access to a private blog, but the blog isn't private. Maybe it hadn't been launched at the time, but it seems odd. Perhaps a request is being made without the site ID and it's defaulting to one. An invalid request would also clear the authentication cookies.

[dolgelukkig]

This looks like another one: #3449089-zd which is a follow up for #3395522-zd

[blackjackkent]

In the hopes of getting some more specific info about what's happening here, I'm going to work on adding some logstash logging to the places in the codebase where this message can manifest, which should hopefully help narrow down what we should be looking at.

Let me know if there's any particular info that I should be sure to include in the logs.

[cpapazoglou]

In the hopes of getting some more specific info about what's happening here, I'm going to work on adding some logstash logging to the places in the codebase where this message can manifest, which should hopefully help narrow down what we should be looking at.

Let me know if there's any particular info that I should be sure to include in the logs.

There are already some logs, you can append any info needed there I assume!

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.

[blackjackkent]

Oh, awesome, didn't realize someone had already gotten there ahead of me. :D Thanks. Will have a look.

[adelineyaw]

Another case #22576506-hc (Personal plan). I've asked them to clear their browser's cache and cookies.

[blackjackkent]

Looked up the logs from @cpapazoglou 's code using the blog ID from the case @adelineyaw just reported - definitely see that in this user's case, wp_api_sec did not appear to be set at all, not just invalid.

[{"_ga":false},{"G_ENABLED_IDPS":false},{"recognized_logins":false},{"wordpress_logged_in":false},{"wordpress_eli":false},{"_pin_unauth":false},{"_derived_epik":false},{"_wpndash":false},{"tk_qs":false},{"wpc_wpc":false},{"dcmsid":false},{"tk_tc":false}]

[ccwalburn]

I have another report here: 25400913-hc
They are on the Premium plan.

[davemart-in]

@griffbrad is this an issue that the Calypso team might be able to lend a hand with? Reports continue to stream in. Each of the teams within the Manage Group have taken a pass at this and at this point it feels like we might be going in circles.

Heads up: @creativecoder, @kwight, @obenland

[griffbrad]

@Automattic/team-calypso can take a look, sure. Happy to help!

[tyxla]

Has anyone been able to reproduce the issue consistently on any site? We'd like to dig further, but we're having trouble reproducing it in the first place.

[cpapazoglou]

Has anyone been able to reproduce the issue consistently on any site? We'd like to dig further, but we're having trouble reproducing it in the first place.

Not really, that is the biggest problem of this issue. We are blindfolded!

[jsnajdr]

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?

@mmtr The wp_api cookies are set when the REST proxy iframe is loaded, and are renewed whenever that iframe is reloaded. Issuing API requests doesn't reset the expiration timer. It's possible that the wp_api_sec cookie expires when the browser tab is open and active for 2 days.

And I confirmed that deleting the wp_api_sec cookie indeed leads to post save failing with that "Sorry you are not allowed" error.

I think it's almost certain that the bug is caused by the wp_api_sec cookie getting lost somehow. The expiration after 2 days is not likely though: I expect that it's removed by one of the many security mechanisms that filter cookies: SameSite, storage partitioning, some tracking prevention...

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?

@pablinos There are multiple auth cookies for different parts of WordPress.com. For loading stuff from *.wordpress.com/wp-admin/*, the cookie is wordpress_sec, while public-api.wordpress.com request require wp_api_sec. While loading public-api.wordpress.com/wp-admin/rest-proxy, the first one is traded for the second one -- note how the proxy URL is in the intersection of both cookie's domains -- that's not an accident 🙂

So, it's possible to successfully load authenticated Gutenberg from a wp-admin URL and still fail at issuing REST requests.

Also, the wp-admin response includes some preloaded data from REST endpoints that the editor would be going to call anyway. That includes the post to be edited. So, the editor can load almost completely without touching a REST endpoint. Trying to save a change can plausibly be the first REST request that visibly fails.

It's interesting that this preloading seems to be broken when iframing Simple sites. When loading the editor in a Gutenframe, I get preload data only for the / REST path. The others are missing. That looks like a bug that should be fixed.

Another strange behavior I was while testing was when opening the editor on an Atomic site. Sometimes, from /posts pages, the edit links lead to Gutenframe (wordpress.com/post/...), sometimes they lead to wp-admin (atomic-example.blog/wp-admin/...). I've got both, rather randomly.

I've also seen a case where the Atomic site editor was initially iframed, then, because the inner frame didn't have auth cookies for atomic-example.blog, redirected to atomic-example.blog/wp-login, that page was refused by the browser because it had X-Frame-Options: DENY header, and few seconds later I was redirected from Calypso to wp-admin.

Is that wait-and-redirect flow intentional? I vaguely remember that @glendaviesnz worked on something similar maybe a year ago, related to Safari ITP.

I'm mentioning all this because bugs related to Gutenframe seem a bit too easy to find. Not a good sign when dealing with an intermittent issue like this one.

[cpapazoglou]

@jsnajdr let me mention, that all logs miss both wordpress_sec and wp_api_sec. Since a missing wordpress_sec leads to clearing the wp_api_sec (270ef-pb), I suppose that we need to find why wordpress_sec is missing in the first place.

[blackjackkent]

For the record, I just tried to edit the post I left open in the editor since Monday morning and did get an error, but not the same one reported in the issue - instead of "Sorry, you are not allowed to edit this post," I got "Updating failed. User cannot access this private blog."

(This was also reported in some of the subsequent reports above, i believe, so we may be onto something for a separate issue here as well. But I don't think it's the cause of the errors from the original report.)

[jsnajdr]

@blackjackkent For our purposes, I think we can treat both errors as one. If the wp_api_sec auth cookie is missing, then for private sites, the "cannot access this private blog" check is done first and therefore fails first. The "allowed to edit this post" check is done only after the first one passes. It's also more specific -- checks permissions for a specific post rather than the entire blog.

[kwight]

Another strange behavior I was while testing was when opening the editor on an Atomic site. Sometimes, from /posts pages, the edit links lead to Gutenframe (wordpress.com/post/...), sometimes they lead to wp-admin (atomic-example.blog/wp-admin/...). I've got both, rather randomly.

Not being compatible for Gutenframe can be for a number of reasons, yes:

• the classic editor is active,
• an incompatible plugin is installed,
• the parent frame has no SSL cert while the child does,
• there's a timeout for whatever reason (we just send the user to wp-admin instead of them seeing the brick wall of "cannot connect")

[noahtallen]

Is that wait-and-redirect flow intentional

Yeah, plus one to what Kirk said, this is intentional. We also redirect to wp-admin if the iframe did not load successfully in 5 seconds:

https://github.com/Automattic/wp-calypso/blob/087dd974f0a0d610a282b985bd1bd7b06de27fb0/client/gutenberg/editor/calypsoify-iframe.tsx#L658-L685

We added that when troubleshooting issues with loading the iframe in ie11.

[jsnajdr]

let me mention, that all logs miss both wordpress_sec and wp_api_sec. Since a missing wordpress_sec leads to clearing the wp_api_sec, I suppose that we need to find why wordpress_sec is missing in the first place.

For a REST request to public-api.wordpress.com, it's expected that the wordpress_sec cookie is not sent. That cookie is scoped to *.wordpress.com/wp-admin. Only requests to /wp-admin, e.g., /wp-admin/post.php or /wp-admin/rest-proxy, are authenticated with that cookie.

REST requests need to have the wp_api_sec cookie and the Authorization: X-WPCOOKIE header.

The user was able to load the editor in frame, including the post content, and REST requests started failing only a while later. That means that the /wp-admin/post.php request was properly authenticated with wordpress_sec, and that the page managed to get the post content from REST, authenticated with wp_api_sec (the server preload doesn't work, so the post content must have been fetched with REST).

How could wp_api_sec suddenly disappear? There's one way: if we load another instance of the /wp-admin/rest-proxy iframe at some point, and that request is not properly authenticated with wordpress_sec, the request will reset the wp_api_sec cookie. That change applies to all other instances of the iframe, too. Calypso with Gutenframe loads at least three proxy iframes, and I see two of them in the iframed Gutenberg document:

One of them is coming from the code that intercepts apiFetch requests, rewrites their paths and sends them to the proxy. I don't know who loads the other one.

How could a proxy iframe be loaded without wordpress_sec auth? The browser can reject to send the cookie because of SameSite restrictions.

First, SameSite=None is added by the server only if the User-Agent header matches certain browsers and version ranges. If the server thinks the User-Agent is not eligible, SameSite=None won't be set.

Second, with Gutenframe, we are dealing with several nested iframes that make requests:

- wordpress.com (Calypso in my browser)
  - jsnajdr-test-blog.wordpress.com/wp-admin/post.php (Gutenberg in iframe)
    - public-api.wordpress.com/wp-admin/rest-proxy (REST proxy inside Gutenberg)
      - public-api.wordpress.com/wp/v2/sites/... (REST requests issued by the proxy)

We need that the wordpress_sec cookie is sent with the /wp-admin/rest-proxy request, and that the wp_api_sec cookie is sent with the /wp/v2/sites REST request.

That happens only if either:

• the cookies are set with SameSite=None
• or all sites in the iframe chain are "samesite", i.e., their scheme and registrable domain are the same. In our case, if everything is https:// and *.wordpress.com, that condition is satisfied.

But imagine that the server finds the User-Agent ineligible and doesn't set SameSite=None.

And that one of the iframes in the chain is outside *.wordpress.com. That frequently happens for widgets loaded from widgets.wp.com, or maybe also static.wp.com. If we load such a widget into iframe and it loads the REST proxy iframe, the wordpress_sec cookie (without SameSite=None) won't be send because the samesite conditions are not satisfied. The server will send a wp_api_sec reset in response, resetting the cookie even for eligible frames.

Or we can load iframed Gutenberg not from the compatible jsnajdr-test-blog.wordpress.com domain, but from a custom domain like jsnajdr-test-blog.blog. That can happen for Atomic sites that don't have the *.wordpress.com unmapped address.

More logging:
@cpapazoglou There are two useful bits of information we could add to the update_item_permissions_check_failure:

• parse the User-Agent string with parse_user_agent and log the parsed browser and version values. See the source of the wp_set_auth_cookie in OpenGrok and notice how it checks, e.g., for chrome >= 76, before adding SameSite=None. If we see failed requests whose User-Agent doesn't match, it will confirm the suspictions I raised above.
• look at the Authorization header of the failed requests, and if it matches X-WPCOOKIE secret:{0,1}:origin, then log the origin string to LogStash. That tells us the origin of the failed REST request. Was it https://jsnajdr-test-blog.wordpress.com? Or https://widgets.wp.com?

That could give us further insight whether the theory I'm laying out in this comment is true. I.e., that SameSite=None is sometimes not set and that the REST frame loaded from non-wordpress.com origin can reset the wp_api_sec cookie for everyone else.

[blackjackkent]

@jsnajdr I've opened a diff at D52402-code to add the features you requested to the log. Please have a look at it when you can! (@cpapazoglou , I followed the same testing instructions that you provided in D50847-code but was not actually seeing my logs show up even though I could see my local logging executing the code; not sure if something's wrong there or not, but if you could verify as well I would appreciate it.)

I'm out Monday but will follow up Tuesday on this unless someone else has commandeered it by then.

[eduardozulian]

For the record, another case in 3435042-zen

[formosattic]

[phone]-zen

[dolgelukkig]

Another case in #186218-hc
Simple site, Premium plan

[adelineyaw]

8000252-hc (Personal plan)

User was seeing "can't create posts as this user" in Chrome but then when they switched to Safari, they didn't have any issues.

[kylemcph]

14108444-hc (Personal plan)

Operating system: OS X 10.15.7
Browser: Chrome 86

[kylemcph]

25547391-hc (Personal plan)

[poojashetty18]

Another case #23833186-hc. Followed up here: #3483929-zd

They're on a Personal plan, browser is chrome, issue happens in Calypso and in wp-admin.

[as-esu]

3476919-zen another case.
Safari browser ( Personal plan ).
"Sorry, you are not allowed to edit this post".

[blackjackkent]

D52402-code has been deployed adding new logging info as described by @jsnajdr - hopefully some extra context can be gleaned from that.

[jsnajdr]

Thanks @blackjackkent for adding the logging. I haven't found anything groundbreaking there yet. Just a few observations:

When I tried to simulate the "update post" error by deleting the wp_api_sec cookie and getting my action logged in Logstash, I didn't succeed. I got the expected error in the UI and in the REST response:

But there is nothing with my blog_id in Kibana. Can anyone reproduce that? This looks almost like there is another place in the codebase that can throw the same error, but with no logging code attached. I was not sandboxed, simply accessing the production servers through proxy.

The browsers from the parsed User-Agent header look fine: it's almost always Chrome 86.

Unrelated: in some of the failed requests, the origin is "https:\/\/wordpress.com\/?trashed=1&ids=9" which is weird. That's not a valid origin and the request fails because of that. The log record reports a valid wp_api_sec.

If we don't find anything, I think the next step is to add some logging to the rest-proxy/index.php script that sets the wp_api_* cookies and log whether it successfully authenticated the iframe or not.

[cpapazoglou]

When I tried to simulate the "update post" error by deleting the wp_api_sec cookie and getting my action logged in Logstash, I didn't succeed. I got the expected error in the UI and in the REST response:

@jsnajdr I am afraid that

User cannot access this private blog.

is an other error (maybe related)! Is your blog private? Could you try from a public one?

[jsnajdr]

@cpapazoglou Of course, it's a different error 🤦 It's related -- and I set my testing blog to private when researching the comment in https://github.com/Automattic/wp-calypso/issues/45881#issuecomment-722608678

I see my error in Logstash now when the blog is back to public.

[AtrumGeost]

Got another report here:

3505717-zd-woothemes

[gwensmithx]

Another reported here: #3503389-zd and customer would like to know once this is solved. I'll mark this for my own followup though I have a large list of GH followups so I'm giving the customer the ticket number to reference as well for an update.

[adelineyaw]

18401728-hc - User refuses to clear their browser's cache or cookies and they're not willing to switch browsers in the interim.

[carinapilar]

Got another one on #21999946-hc - Worked on incognito on Chrome, suggested clearing the cache.

[sophiegyo]

Got another one on #21999946-hc - Worked on incognito on Chrome, suggested clearing the cache.

I ended up with #21999946-hc

Browser: Google chrome Version 85.0.4183.83 (Official Build) (64-bit)
OS: Catalina 10.15.6

Is it me or does this regularly happen specifically with Chrome, but not other browsers?

[jonnyruzek]

6245514-hc