User invite email fails if visited more than once

[dchallener]

Which Umbraco version are you using? (Please write the exact version, example: 10.1.0)

13.5.2

Bug summary

If you invite a user and the link is visited more than once the link doesn't work and a token is invalid message is displayed.

Specifics

This only happens for links that are visited multiple times - whether this is by a user by accident/on purpose or by a mail scanner or corporate link checker.

From what I can see is happening is that when the invite is sent out a user is created in the db with a generated securityStampToken that is used in the token sent to the new user.
When the link is visited, the email is confirmed and the db table is updated with an emailConfirmedDate - which in turn generates a new securityStampToken.
The next time the link is visited the token is validated again which no longer matches this token and fails.

It looks very similar to this reported issue in aspnet core dotnet/aspnetcore#32681 but hopefully something that can be resolved within Umbraco.

Steps to reproduce

1. Invite a user
2. Visit the link in a browser (works)
3. Visit the link again (invalid token)

Expected result / actual result

A user should be able to visit this link until they have logged in successfully.

Possibly excluding the emailConfirmedDate field from the Identity generated securityStamp is the way forward here?

[github-actions]

Hi there @dchallener!

Firstly, a big thank you for raising this issue. Every piece of feedback we receive helps us to make Umbraco better.

We really appreciate your patience while we wait for our team to have a look at this but we wanted to let you know that we see this and share with you the plan for what comes next.

• We'll assess whether this issue relates to something that has already been fixed in a later version of the release that it has been raised for.
• If it's a bug, is it related to a release that we are actively supporting or is it related to a release that's in the end-of-life or security-only phase?
• We'll replicate the issue to ensure that the problem is as described.
• We'll decide whether the behavior is an issue or if the behavior is intended.

We wish we could work with everyone directly and assess your issue immediately but we're in the fortunate position of having lots of contributions to work with and only a few humans who are able to do it. We are making progress though and in the meantime, we will keep you in the loop and let you know when we have any questions.

Thanks, from your friendly Umbraco GitHub bot 🤖 🙂

[ronaldbarendse]

This only happens for links that are visited multiple times - whether this is by a user by accident/on purpose or by a mail scanner or corporate link checker.

To correctly fix this, we should require the user to confirm the email validation on this linked page (using a form that does a POST request), instead of doing it on the initial (GET) request. This allows the link to be opened multiple times (including accidental clicks), until the email is actually confirmed. This should make the validation more secure as well, as users can check the website URL before confirming (e.g. if the email is sent through a mail provider that adds link tracking) and avoids the mail scanner/link checker to essentially 'auto-confirm' any email address (potentially even incorrect ones or catch-all addresses)...

[dchallener]

Thanks @ronaldbarendse

I do agree that this would be a better and more correct fix.
Reviewing how v14/15 work this looks to already be the case and don't think we have the same issue in the new version.

The typescript Umbraco.Web.UI.Login project backported in v13 is quite different however (presumably due to the new api work in v15), and I really don't have any experience in the new tech here. From comparing v13 code to v15 it looks like there would be some changes to method signatures newInvitedUserPassword(password) to newInvitedUserPassword(password, token, userid) and would also need to be able to add a validateInviteCode(token, userid) method.

I'm guessing changing these would then have a knock on to the other parts of the login process?