Registration with email is unnecessarily complicated, potentially causing myriad problems

[lampholder]

Today, if I register for a fresh account on matrix.org, with an email address, using Riot Web:

• enter mxid, password and email address
• riot tells me to check my emails
• i open my email and click the verif link, which opens in a new tab
• now I have two tabs!
• both tabs ask me to complete a CAPTCHA
• both tabs ask me to accept the terms and conditions
• both tabs start logging in, and: probably something weird is going to happen now.

We've seen:

• you're logged in as a guest
• you are logged in as yourselve but with 2 - 10 devices also logged in
• one tab asks you to accept the terms and conditions, the other tells you that it's missing session data (and you should Sign Out)

[lampholder]

After discussion, this is better:

• enter mxid, password and email address,
• CAPTCHA, t's and c's
• riot tells me to check my emails to complete registration
  • this tab sits there polling for registration completion to give it the go ahead to log in
• i open my email and click the verif link, which opens a new tab
  • this tabs says 'well done email verifed thanks'
• your original tab completes login by itself, no racings

And as a stretch goal we could add some better wording to the email-verified tab that tells you what you should do now (go back to the original tab or login fresh at https://riot.instance/login_uri)

[lampholder]

We should think carefully about this in the context of other clients/riot instances/homeservers.

[turt2live]

can we please also consider supporting post-registration verification of email? It really suck trying to get going when you're being asked to verify your email now instead of in the next 24-48 hours.

[dbkr]

How do we want to handle the case where the user closes the original tab?

can we please also consider supporting post-registration verification of email? It really suck trying to get going when you're being asked to verify your email now instead of in the next 24-48 hours.

The problem with this is that we have HSes that require email addresses to create accounts, so we would have to fairly fundamentally change registration so you could register an account and then 'activate' it later by completing email verification.

[dbkr]

How do we want to handle the case where the user closes the original tab?

Answer: the link-clicking tab would complete the register but not log in, so if you closed the original tab, you'll just have to log in to your new account.

[dbkr]

Some updates on this, mostly for my own notes, because quite a lot has happened:

• you're logged in as a guest

This one was matrix-org/matrix-react-sdk#2967

CAPTCHA, t's and c's
riot tells me to check my emails to complete registration

matrix-org/synapse#5174 re-ordered the stages so email comes last. The problem with this is that if your email is already registered, you don't get told until after you've done through a captcha and the t&cs. We can fix this by sending the mail right after you hit submit on the form, before captcha/t&cs, but only telling you to go & check your mail after you've done the captcha / t&cs. This also gives some time for the mail to arrive which is kind of nice.

i open my email and click the verif link, which opens a new tab
this tabs says 'well done email verifed thanks'
your original tab completes login by itself, no racings

The problem with this is that the link-clicking client needs to do a register request in order to actually make the account (otherwise if you closed the original tab, the email will get verified but your account won't get created). If we do this though, we end up with a login, even if we don't want one. One idea was to supply inhibit_login to the original register request, so no session gets created, but then in the original client once the registration completes, submit the request again with out inhibitLogin to get our session. This didn't work because the parameters for the UI auth session get replaced and the tabs race, so if the link-clicking client gets there last, the stored parameters will now have no inhibitLogin.

The conclusion here is to add a 'click here to continue' after the email stage so the clients don't log in automatically when registration is done, but you can click to continue if you do actually want to be logged in. If the server didn't do email auth last you might get another auth stage after clicking continue, but that's OK.

[dbkr]

Clarifying because I went off to do other things before implementing this and am now about to do so again. We can't just add a 'click to continue' to both sides because that means if you don't click continue in either place, your account doesn't get registered.

I think the best we can do is:

• Use inhibitLogin
• On link-clicking client, just dead-end with a link to login page. If the user wants to log in, they click the link & enter their creds.
• On original client, poll as we do now, but don't supply the email sid: instead let the link-clicking client actually create the account. When it succeeds, offer a continue button that, ,if pressed, will do the request without inhibitLogin. The request will replace the stored params on the server to remove inhibitLogin but because we didn't supply the email sid, we know the link-clicking client has done their register request so we won't race.
• The only problem is if the user clicks the continue link, then clicks the validation link again, at which point they will be logged straight in, creating another device, whether they wanted one or not (because the stored params have now been replaced with the set that does not have inhibitLogin.

[jryans]

Related to registration with email, I just got an error when trying to complete the validation link. I'm mentioning this here in case it's a regression related to recent work in this area.