Activation links should be idempotent so they're not consumed by crawlers or accidental clicks

[MoritzLost]

We frequently have issues with sites that have public registrations. Users complain that the activation link they received doesn't work, instead they get a HTTP 400 Bad Request error response.

Usually, this means that the activation code has already been consumed. The problem is that those links are not idempotent. They only work once and throw an error when they're visited again. This only happens with activation links like this, it doesn't happen with the password reset flow:

example.com/cms/verify-email?code=[abc123]&id=[abc123]

This behavior is way too error-prone. Users may have clicked the link already and then closed the tab, maybe even before the page fully loaded, and then forgot about it. But this can even happen without any user interaction. Some email providers and antivirus software will follow links to scan for malware, which also consumes the activation link. Any plugin or email app feature that shows a link preview will also break this workflow. And we all remember that time Microsoft decided to send all links in all emails from Outlook to Bing for indexing …

A good solution would be to make the email verification links idempotent to make them more resilient. For example:

• Any subsequent visit to the URL could redirect to the login page if the code exists, even if it was already consumed.
• Instead of immediately consuming the token when the URL is visited, display a page with a button to press, to prevent the token being accidentally consumed.

---

Broader view: I've only noticed this in the context of verification links, but I'm not sure if this also affects any other links generated by Craft. User impersonation also does this, though I don't think it's an issue here. Any fix should probably address this problem in a general way.

[brandonkelly]

I’m not able to reproduce that behavior. Activation links show a Set Password template initially, and the verification code isn’t actually removed from the user until they set their password. What am I missing?

[MoritzLost]

@brandonkelly I can only reproduce this problem when using public registration. When I create a user through the normal flow in the Control Panel, I don't even get the normal activation mail. When I click on Save and send activation mail, I get a password reset email (example.com/cms/set-password) instead of the /cms/verify-email path. This one shows a password form and doesn't have side effects.

But with public registration, it's a different story. We have the following settings:

Our registration form also includes a password fields, so registered accounts will be inactive, but already have a password set.

So accounts created through public registrations are disabled by default, and no email is sent immediately. The website maintainers manually check the accounts, and if they want to allow the registration, they use Send activation mail. Then they get an email to /cms/verify-email. This one only works once, it activates the account and then redirects to the same password reset form. The second time the link is visited, I get a 400 response.

I don't really understand why those two flows send different emails even though I click a button to send an activation mail in either case (I don't even understand the difference between inactive and suspended to be honest). But with the above settings, it's definitely a problem. Not sure which other combinations of settings or user creation flows are affected.

[brandonkelly]

Sorry, yeah I’m able to reproduce with front-end registration.

I agree that the verification URL should probably take you to a page with a button you have to press to actually verify the account. We’ll discuss that.

One thing you can do to improve the experience now is change the invalidUserTokenPath config setting to 'login' (or whatever your login path is), so if authors click the link a second time, they’re taken to the login page.

[MoritzLost]

@brandonkelly Thanks, I'm interested how your discussion turns out!

One thing you can do to improve the experience now is change the invalidUserTokenPath config setting to 'login' (or whatever your login path is), so if authors click the link a second time, they’re taken to the login page.

I just tried that, but it doesn't work in my case. Looks like that setting is only used in frontend requests. But the activation email path goes to /cms/verify-email, so it's not a site request, which means that setting is not used.

Is that because the user accounts have access to the Control Panel?
(as per https://craftcms.com/events/dot-all-2023/sessions/building-a-collaborative-content-platform-with-the-control-panel 🙂)

[brandonkelly]

Ah, yeah, invalidUserTokenPath only affects users w/o control panel access.

I updated the default behavior for users with and without CP access, for Craft 5.8, in #17392.

[brandonkelly]

This has been addressed for Craft 5.8: #17392

[MoritzLost]

@brandonkelly That looks great! Thanks, Brandon!