Cookie Consent: send a REST nonce from the consent logger so logged-in user IDs are recorded

[chihsuan]

Related to WOOA7S-1563 / #49852 (prerequisite for the consent-log personal-data exporter/eraser).

Proposed changes

The consent logger posts to the REST write endpoint with no X-WP-Nonce header. For a logged-in visitor the browser still sends the auth cookie, so WordPress core (rest_cookie_check_errors) sees a cookie-authenticated request without a REST nonce and forces it anonymous — wp_set_current_user( 0 ). As a result, every consent row, even for logged-in users, was written with customer_id (renamed user_id in #49852) = 0. The POST still returns 200 because the route is permission_callback => '__return_true', so it failed silently.

This is load-bearing for the personal-data exporter/eraser in #49852, which matches consent rows by user ID: with every row stored as 0, it would match nothing for a real logged-in user.

Why

• The logger never sent a REST nonce, so core could not authenticate the cookie-bearing request and downgraded it to anonymous. The captured user_id was therefore always 0, making per-user export/erasure impossible.

How

• Localize a wp_rest nonce into jetpackCookieConsentConfig — only for logged-in visitors. Anonymous visitors deliberately get no nonce: their pages are full-page-cached, and a cached nonce would go stale and make core reject the request with rest_cookie_invalid_nonce (403). Without a nonce, core treats the request as anonymous and stores user_id = 0, which is correct for them. This keeps anonymous logging — the bulk of the traffic — working unchanged.
• The logger attaches X-WP-Nonce only when the nonce is present.

What

• class-cookie-consent.php — conditionally add a wp_rest nonce to the localized config when is_user_logged_in().
• logger.ts — send the X-WP-Nonce header when a nonce is present.
• types.ts — add the optional nonce field to the config type.

Does this pull request change what data or activity we track or use?

No new data is collected. This fixes attribution of an existing field: consent rows for logged-in users now record the real user ID instead of 0. Anonymous behavior is unchanged.

Testing instructions

Environment setup

The cookie-consent code ships inside the Premium Analytics plugin (Composer path dependency), which is the only consumer that boots Cookie_Consent::init() — registering the consent-log REST routes and enqueuing the logger.

1. On the test site, activate the Premium Analytics plugin and the WP Consent API plugin.
2. Load any front-end page and confirm window.jetpackCookieConsentConfig is defined in the browser console (this proves the logger is enqueued). The visible banner additionally needs a GDPR region or ?preview_cookie_consent=1, but the banner is not required for this test — the steps below POST to the same endpoint the banner uses.

Verify

Run both cases on the same site (same IP) and compare the stored user ID. To read rows back as admin: GET /wp-json/jetpack/v4/cookie-consent/consent-log?per_page=100 (needs manage_privacy_options + an X-WP-Nonce).

1. Logged-in — while logged in, load a front-end page and confirm window.jetpackCookieConsentConfig.nonce is present. Accept consent (or POST to the consent-log endpoint with the X-WP-Nonce header). Confirm the new row's user ID is your real user ID, not 0.
2. Anonymous — repeat logged out: confirm there is no nonce in the config, the POST still returns 200 (not 403), and the row's user ID is 0.

Verified live with this branch active (the column is customer_id on trunk, renamed user_id by #49852):

Scenario	X-WP-Nonce sent	POST status	Stored user ID
Logged-in (user ID 1)	yes (nonce in config)	200	1
Anonymous	no (no nonce in config)	200 (no 403)	0

[github-actions]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

• ✅ Include a description of your PR changes.
  
• ✅ Add a "[Status]" label (In Progress, Needs Review, ...).
  
• ✅ Add testing instructions.
  
• ✅ Specify whether this PR includes any changes to data or privacy.
  
• ✅ Add changelog entries to affected projects
  

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

---

Follow this PR Review Process:

1. Ensure all required checks appearing at the bottom of this PR are passing.
2. Make sure to test your changes on all platforms that it applies to. You're responsible for the quality of the code you ship.
3. You can use GitHub's Reviewers functionality to request a review.
4. When it's reviewed and merged, you will be pinged in Slack to deploy the changes to WordPress.com simple once the build is done.

If you have questions about anything, reach out in #jetpack-developers for guidance!

[jp-launch-control]

Code Coverage Summary

This PR did not change code coverage!

That could be good or bad, depending on the situation. Everything covered before, and still is? Great! Nothing was covered before? Not so great. 🤷

Full summary · PHP report

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.