Jetpack Comments: Different user ids in the environment when creating and verifying the nonce

[oskosk]

Impacted plugin

Jetpack

Quick summary

In #23439 we added nonces to the comments system, which are not being verified properly, If you're signed in to the site.

The nonce is generated with the idea of the user visiting the site, but the validation happens under id: 0 (anonymous) wp_verify_nonce fails.

Export-1692134613707.mp4

Steps to reproduce

1. Activate Jetpack comments under Jetpack -> Settings -> Discussion
2. On a post, while signed in to the site, try to leave a comment
3. Expect to get a Nonce verification failed message.

A clear and concise description of what you expected to happen.

I expected to be able to write a comment being signed in.

What actually happened

I can't write a comment

Impact

Some (< 50%)

Available workarounds?

No and the platform is unusable

Platform (Simple and/or Atomic)

No response

Logs or notes

No response

[oskosk]

@cuemarie Have you tried with this setup?

• Logged in to .com
• Logged in to the site with a user whose Jetpack connection matches the .com account you're signed with to .com
• Commenting

For example. This is in an incognito window. on a Jurassic Ninja site.

• If I'm signed into the self-hosted site, but not to WordPress.com, I can comment.

• In the same incognito window, I sign in to .com with the user that connected the Jetpack site and I can't comment

[oskosk]

The diagnosis here, matches mine

Upon further digging, the nonce is different because wp_get_current_user fails upon submission, and returns 0 as the user_id when it is typically something else at page load (in my case, 2).
I’m not sure why the wp_get_current_user fails upon submission. Hopefully, the developers can figure it out. Fort posterity, I checked this not only with my theme but also twenty-twenty-two. Both produced the same error for the same reasons.

https://wordpress.org/support/topic/jetpack-comment-error-nonce-verification-failed/#post-16276738

[cuemarie]

Thanks @oskosk for the added details! It seems the issue was my Discussion Settings. Updated notes below:

📌 SCRUBBING : RESULT - Replicated / Could Not Replicate / Uncertain

• Tested on Simple – Could Not Replicate
• Tested on Atomic – Replicated
• Replicable outside of Dotcom – Yes

📌 FINDINGS/SCREENSHOTS/VIDEO

• I was able to repro on Atomic and self-hosted site with the following steps:

• Settings > Discussion, enable Users must be registered and logged in to comment

• Refreshed post, and clicked "log in" under comment thread

• Log in to the WordPress.com account that the site is connected to via Jetpack

• Leave a comment.

Screenshots/Recordings

Atomic

yZU3Lf.mp4

Self-Hosted

L6VDl4.mp4

Simple site did not reproduce the same error, and commenting worked as expected.

📌 ACTIONS

• Assigned to Other

[cuemarie]

🔔Just a heads up FYI to @Automattic/loop as this impacts commenting/engagement.

[oskosk]

Thanks @cuemarie.

Noting here that in the Jetpack Admin page settings we don't have that setting as it comes from core. In calypso both sets of settings are merged

Jetpack -> Settings -> Discussion

Settings -> Discussion

Calypso

[jeherve]

Related:

• p1690992899536269-slack-CA17PSW87
• 7666-gh-jpop-issues

[jeherve]

I looked into this a bit. I was able to reproduce on one site (a brand new JN site, freshly connected to my a11n acount), but not on others. I was not able to figure out what was different about the site where I could reproduce.

A few things to note:

1. You do not need to enable the user login requirement (as shown on the screenshots above) to be able to reproduce the issue.
2. You do need to be logged in with both the local admin account and the linked WordPress.com user.
3. When the problem happens, there is indeed no user info available when Jetpack's pre_comment_on_post runs, so the nonce check logically fails.

The Verbum comment UI is slowly getting activated for more and more folks, and it does complicate testing in some scenarios since it does not always seem to reflect the current user situation on the site. In the example below, I was logged in as an admin on the site:

In this scenario, I should be logged in in the comment form as well. I cannot seem to be able comment as a logged in user at the moment.

In fact, one could argue that when you are locally logged in as admin, you may not need any type of Jetpack Comment UI; you are already logged in, you do not need any kind of social login option at this point.
Looking at the codebase, it looks like logged in users should be allowed to post with other options so the codebase disagrees with my statement above:

jetpack/projects/plugins/jetpack/modules/comments/base.php

Lines 218 to 227 in 24b4c87

	/**
	* Allow a logged in user to post as a guest, or FB credentialed request.
	* Bypasses WordPress' core overrides that force a logged in user to comment as that user.
	* Respects comment_registration option.
	*
	* @since 1.4
	* @param array $comment_data All data for a specific comment.
	* @return array Modified comment data, or an error if the required fields or a valid email address are not entered.
	*/
	public function allow_logged_in_user_to_comment_as_guest( $comment_data ) {

If we removed the Jetpack Comment UI when you're logged in, it would solve this issue. I think it may also avoid some confusion around Jetpack Comments and social login. It would, however, change the way Jetpack Comments have worked until today, and may potentially cause more confusion.

At this point, I'm not sure how to move forward with this. @Automattic/vertex Since you've been working on Verbum, you're most likely the most familiar with this at the moment. Do you have any ideas?

[heavyweight]

I looked into this a bit. I was able to reproduce on one site (a brand new JN site, freshly connected to my a11n acount), but not on others. I was not able to figure out what was different about the site where I could reproduce.

A few things to note:

1. You do not need to enable the user login requirement (as shown on the screenshots above) to be able to reproduce the issue.
2. You do need to be logged in with both the local admin account and the linked WordPress.com user.
3. When the problem happens, there is indeed no user info available when Jetpack's pre_comment_on_post runs, so the nonce check logically fails.

The Verbum comment UI is slowly getting activated for more and more folks, and it does complicate testing in some scenarios since it does not always seem to reflect the current user situation on the site. In the example below, I was logged in as an admin on the site:

In this scenario, I should be logged in in the comment form as well. I cannot seem to be able comment as a logged in user at the moment.

In fact, one could argue that when you are locally logged in as admin, you may not need any type of Jetpack Comment UI; you are already logged in, you do not need any kind of social login option at this point. Looking at the codebase, it looks like logged in users should be allowed to post with other options so the codebase disagrees with my statement above:

jetpack/projects/plugins/jetpack/modules/comments/base.php

Lines 218 to 227 in 24b4c87

	/**
	* Allow a logged in user to post as a guest, or FB credentialed request.
	* Bypasses WordPress' core overrides that force a logged in user to comment as that user.
	* Respects comment_registration option.
	*
	* @since 1.4
	* @param array $comment_data All data for a specific comment.
	* @return array Modified comment data, or an error if the required fields or a valid email address are not entered.
	*/
	public function allow_logged_in_user_to_comment_as_guest( $comment_data ) {

If we removed the Jetpack Comment UI when you're logged in, it would solve this issue. I think it may also avoid some confusion around Jetpack Comments and social login. It would, however, change the way Jetpack Comments have worked until today, and may potentially cause more confusion.

At this point, I'm not sure how to move forward with this. @Automattic/vertex Since you've been working on Verbum, you're most likely the most familiar with this at the moment. Do you have any ideas?

Our efforts are scattered across multiple places ATM, but we have this patch D123363-code. We need to address the issues there.

[heavyweight]

We were fixing a related issue and to me it seems that this got fixed as well.
Can someone try to reproduce this? No need for any testing setup except a sandbox pull.

[jeherve]

@heavyweight This is still happening I'm afraid.

[heavyweight]

Screen.Recording.2023-10-06.at.17.43.22.mov

Not sure what I'm doing wrong.
I logged in to the site with email password. The same email from my wp account.
Later I logged in into wordpress.com.
When posting the comment I don't see the error.

[jeherve]

I was having trouble reproducing as well; it happens on some of my sites, but not others. I haven't been able to understand why sometimes it works and sometimes it doesn't.

[danjjohnson]

A few users affected by this:

8481771-zen
8495110-zen

https://wordpress.org/support/topic/chrome-jetpack-gives-nonce-errors-firefox-jetpack-is-completely-fine/

[github-actions]

Support References

This comment is automatically generated. Please do not edit it.

• 8481771-zen
• 8495110-zen
• 8669002-zen

[StefMattana]

Another user reporting it on this forum thread: https://wordpress.org/support/topic/chrome-jetpack-gives-nonce-errors-firefox-jetpack-is-completely-fine/#post-17920955

[heavyweight]

The PR got merged #38554
It will be fixed once jetpack is deployed to atomic sites

[jenhooks]

@heavyweight - is there any chance that this could still be a problem? I'll refrain from reopening this, but we have a Jetpack user in 8669002-zen reporting this problem, and we're able to reproduce the Nonce verification failed. error when trying a test comment on their site.

[heavyweight]

After the merged PR I didn't expect to see this again.
I tried to reproduce on my atomic site and couldn't.
I tried on the customer site and the comment went through.

I suspect that this could be an old or cached nonce that got sent.
I see on the ticket that @lschuyler managed to reproduce this. Could you share replication steps?

[lschuyler]

I simply loaded the site and attempted to leave a comment on the latest post and got the Nonce verification failed. message. I then checked the Jetpack connection, and saw a bit of a sync discrepancy in the Sync Validation. I clicked the Schedule a Fix button. I came back later in the hour to confirm that was fixed. I did a hard refresh of the blog and attempted to comment again, but got the same Nonce verification failed. when I tried. I checked the comments page on her dashboard just to see if the comment went through anyway, but it did not. Hope that helps!

[escapemanuele]

@heavyweight are you able to give it a test following @lschuyler steps?

[heavyweight]

I wasn't able to reproduce this issue unfortunately.

[lrtottenham]

@heavyweight are you able to offer some guidance on how to reply to the customer, if we aren't able to reproduce the issue? I tried and was also able to comment on one of their posts.

thanks!

[heavyweight]

It's always tricky with issues that we can't reproduce.
I don't have any meaningful ideas on how to follow up on this unfortunately.

We could ask again if the issue persist for the user in question and what authentication method was used for commenting: email or social login.

[dmsnell]

On November 17 I experienced what appears to be a similar issue, if not the same issue, as I was unable to post a comment on my own site due to an invalid nonce error. The comment form showed that I was logged in.

Given that we don’t seem to have any evidence collected for how frequently this impacts Jetpack customers’ ability to leave comments, I’m concerned that we could be overlooking something wider spread.

Would it be possible to recognize these failures inside Jetpack so that we could have some idea of the incidence rate and any apparent patterns?

My mind immediately jumps to long-running sessions as a suspect (without any other evidence) if we’ve been unable to resolve it. This because weird authentication issues can happen once tokens of various kinds expire.

If this is related in any way to old browser sessions, the impact could be hitting hardest on those who are most prolific in engaging in online discussion — or at least those who are trying.