Related: https://github.com/matrix-org/matrix-doc/issues/2907, #8009

CC: @clokep

DINUM were finding after upgrading to Synapse v1.23.0 that email registration was no longer working due to "Missing params: password". Their flow consisted of the following requests.

Check with the homeserver what the required flows to register are:

POST /register

{}

# get back a sessionID

Request a validation token from Synapse (no Sydent involved here):

POST /register/email/requestToken

{some client_secret and email address info}

# get back a sid (session ID for validating the email)

Request /register again, this time with a password which we want to save. We're doing to do a m.login.email.identity here even though we know that it's going to fail. Note that m.login.email.identity is the only flow the server gives us. We just want to save the password.

POST /register

{
  "auth": {
    "threepid_creds": { threepid_validation stuff that won't succeed because the link in the email hasn't been pressed yet },
    "session": "what_we_got_from_the_first_request",
    "type": "m.login.email.identity"
  },
  "password": "please_save_this_password123"
}

# Get back a 401. Fair, I expected this. But my password_hash has been recorded, right?

The client got a 401 one, but not from a InteractiveAuthIncompleteError exception, but a LoginError coming from here:

Now unfortunately, the code that stores password_hash in ui_auth_sessions for subsequent UI Auth requests will only do so if a InteractiveAuthIncompleteError is raised, not LoginError:

So uh oh. A password_hash never got saved. In the case of DINUM, a user now clicks the link in their email and is brought to a completely separate client which doesn't know what the password is supposed to be.

That client (having validated the threepid) then makes a final request to /register:

POST /register

{
  "auth": {
    "threepid_creds": { threepid_validation stuff that won't succeed because the link in the email hasn't been pressed yet }
  }
}

# Gets back a 400! Missing params: password

And thus registration fails.

I think a simple solution here would be to catch LoginError in addition to InteractiveAuthIncompleteError where we store the pasword_hash:

That way the client would still get the same exact error, but now we're storing the hash when a LoginError is raised. If we go with this, we should also do it in /account/password, which does the same:

Additionally, the client could just send the password without attempting to complete an auth step, though this isn't really clear from the perspective of the client developer.