Data erasure/export links should notify the user that the action has already been confirmed

[dd32]

When a data erasure/export process is started, an email is sent to the email to confirm the action. That email contains only-use-once link that needs to be confirmed for the process to start.

The first request to that url has a nice "Thanks, you'll be notified when ready" type message, but clicking the link a second time will just trigger a wp_die( 'This link has expired.' ); message without any context as to why.

It's also possible that some email scanners (Either on the server, or on an email client) may request the URL on the users behalf to verify if the URL contains any malicious content in which case the email owner would never actually see the success message, and only the expired link message.

[dd32]

It's also possible that some email scanners (Either on the server, or on an email client) may request the URL on the users behalf to verify if the URL contains any malicious content in which case the email owner would never actually see the success message, and only the expired link message.

In retrospect, this is probably a legitimate separate issue entirely but is an example of how this bug/behaviour can be triggered (other than a double click of a link).

[johnbillion]

Is it common for email clients or servers to automatically follow links in emails? That sounds like a nightmare from a privacy and functional point of view.

Let's open a separate issue for that as it affects other functionality too such as password resets.

[garrett-eclipse]

Related #46079

[dd32]

Replying to johnbillion:

Is it common for email clients or servers to automatically follow links in emails? That sounds like a nightmare from a privacy and functional point of view.

The only place I've seen it happening is with Antivirus scanners (Client-based and server-side), Checking for malicious content in embedded links is a common offering as far as I know. Some just compare against known phishing urls, others check the actual page content for malicious content.

I can't really think of many links that you'll find in emails where an unauthenticated scanner requesting the URL would cause concern, let alone expire the link.

Let's open a separate issue for that as it affects other functionality too such as password resets.

I don't think that would be the case, since those links only expire once the form on the pages actually get used. The first request just adds the URL params to cookies and redirects to a non-tokenised url.

[garrett-eclipse]

Thanks @dd32 one question I have is would these scanners unintentionally confirm requests triggering export/erasure without the user making any action? I ask as I wonder if the confirmation screen then rather than auto-confirming on load should instead provide a button to trigger confirmation to ensure we're actually getting the user consent before the request is considered confirmed.

[dd32]

Replying to garrett-eclipse:

one question I have is would these scanners unintentionally confirm requests triggering export/erasure without the user making any action?

That's my understanding, although I'm yet to actually test such a scanner. It's been a long time since I've dealt with those systems, but I know they still exist within modern scanners.
Here's an example thread where users were seeing Gmail doing something similar: ​https://support.google.com/mail/thread/16878288

I ask as I wonder if the confirmation screen then rather than auto-confirming on load should instead provide a button to trigger confirmation to ensure we're actually getting the user consent before the request is considered confirmed.

I've seen some forms where Javascript automatically submits the form on the users behalf when loading the page, which would work around most automated scanners.

However, There's also a reasonable case to be made, that a user who doesn't want to erase their account may accidentally click a link (for example, copying it to ask "What?") or who are trying to figure out what the email is about. Requiring a final action from the user (such as clicking a confirm button on the followed link) would solve all of the above.

[garrett-eclipse]

Thanks @dd32 best err on the side of caution then and play it safe with the confirm button approach.

## Summary

• shows a confirmation form instead of confirming personal data requests on the initial GET request
• performs the request confirmation only after the form is submitted
• reports when a valid request link has already been confirmed
• adds regression coverage for confirmed request keys

## Testing

• phpunit tests/phpunit/tests/auth.php (143 tests, 358 assertions)
• PHPCBF and PHPCS on all changed files
• manually verified the GET, POST, and reused-link flows in the local WordPress environment

[arkaprabhachowdhury]

Opened [PR #12765](​https://github.com/WordPress/wordpress-develop/pull/12765) to address this ticket. Summary - shows a confirmation form instead of confirming personal data requests on the initial GET request - performs the request confirmation only after the form is submitted - reports when a valid request link has already been confirmed - adds regression coverage for confirmed request keys Testing - phpunit tests/phpunit/tests/auth.php (143 tests, 358 assertions) - PHPCBF and PHPCS on all changed files - manually verified the GET, POST, and reused-link flows in the local WordPress environme The PR includes focused regression coverage, and its validation details are recorded in the PR description.

I picked this up because the ticket describes a concrete core behavior or edge case that remains relevant in current WordPress. The proposed change is intentionally scoped to the ticket and is submitted here for code review, with the technical discussion remaining on this ticket.