This PR creates an endpoint GET/POST /_matrix/identity/api/v1/validate/email/submitToken
which mirrors the same endpoint on the identity server used for submitting tokens
used for validating 3PID addresses.
When the token is submitted, it is checked along with the client_secret and session_id in
the db and if it matches and isn't expired, we mark the session as validated. Then, when
the user attempts to change their password, we check if the session is valid, and if so
allow it. We also delete the session at this point, as as far as I can tell there's no
further use for it.
Database component of new behaviour of sending password reset emails from Synapse instead of Sydent.
Allows one to store threepid validation sessions along with password reset token attempts and retrieve them again.
This changes the default behaviour of Synapse to send password reset
emails itself rather than through an identity server. The reasoning
behind the change is to prevent a malicious identity server from
being able to initiate a password reset attempt and then answering
it, successfully resetting their password, all without the user's
knowledge. This also aides in decentralisation by putting less
trust on the identity server itself, which traditionally is quite
centralised.
If users wish to continue with the old behaviour of proxying
password reset requests through the user's configured identity
server, they can do so by setting
email.enable_password_reset_from_is to True in Synapse's config.
Users should be able that with that option disabled (the default),
password resets will now no longer work unless email sending has
been enabled and set up correctly.
It takes at least 20 minutes to work through the long_retries schedule (11
attempts, each with a 60 second timeout, and 60 seconds between each request),
so if the notary server isn't returning within the timeout, we'll just end up
blocking whatever request is happening for 20 minutes.
Ain't nobody got time for that.
Andrew Morgan