Make homeservers able to handle registration-with-email without depending on an Identity Server #5751
Comments
|
I've been thinking a little more about whether the 'current behaviour' will represent a desirable state for any homeserver after this change. The current behavior is that your homeserver will talk to whichever identity server your client tells it to (as long as it is on your whitelist), except when deactivating your account (when it will communicate with whichever identity servers it knows were used to bind specific threepids). For homeserver admins who want to send registration and password-reset emails via an identity server, it's likely that they will have a specific identity server/servers in mind (since it would be atypical for anyone running an Identity Server to accept mail-send requests on behalf of just anyone). Would it make sense then for the homeserver configuration options to be one of either:
This would have no impact on the account deactivation behaviour. It would also be nice if there were a way to query the homeserver's whitelist of identity servers (I think not being able to do this will result in some glitchy edge cases that are hard to detect and handle). |
|
Having thought about this some more I think ^ is a great idea. We should make it as clear as possible that the homeserver handles registration and password reset emails by itself, unless an Specifying an |
|
Is there a case where someone would want registration emails to be handled by the IS but the HS handles password resets? |
This is still filtered by the HS's whitelist, correct? |
|
Interestingly, The homeserver should still handle the email sending based on a HS option though. Edit: From element-hq/element-web#10424, it seems we do. |
|
Synapse currently has an So if we're going with the above solution, in that the IS is getting decoupled from sending registration emails/texts, then |
|
I'm currently trying to make Should we just override this value? Also synapse/synapse/handlers/register.py Line 760 in 4806651 threepid object which would never have a threepid_creds key.
Edit: Turns out this function is called from somewhere else which does provide a threepid dict with a |
|
So we're going to go with having If it's set, account/password resets will go through that set identity server. if it's not, then the HS will handle everything. We'd need to update the spec to reflect this. This also means we can get rid of the server's identity server whitelist, since that was a weak attempt at preventing users from using malicious identity servers which could do nasty things with password resets. The only place where Also |
|
The thing you're going to run into is that only the v1 endpoint of an IS will let you call
Actually now they're probably more relevant since a HS could send different emails depending on what the user was trying to do. |
Well one would be the IS sending an email, and the other being the HS sending an email, so you could put different things in the emails that way, no? |
Right... so we can't delegate sending registration emails via the IS anymore. So this option would only be useful for password resets, but I don't really think anyone in their right mind would want to do homeserver password resets through an IS. So... should we just ditch homeserver's calling to IS' for registration/password resets altogether? Edit: This means that homeservers would no longer be able to offer signing up with email if they didn't configure their SMTP options, which does make intuitive sense, but may catch some people off-guard upon upgrading. |
Doesn't that mean they're not the same? But yes,
I think we'd already decided to ditch it for registration (although I don't know if that was before we decided on the |
|
After a meeting IRL, we're keeping We also need to be very clear during the next Synapse update that homeserver admins are aware of this, as to avoid confusing them when we remove |
…il (#5835) ~~Fixes #5833 Moved out to ~~#5863 Part of fixing #5751 Decouples the activity of sending registration emails and binding them to an identity server. This PR simply sends the registration email, but clicking it does not approve the user for registration. That will come in PR #2. Some of this makes use of existing stuff for sending password reset emails from Synapse. Some work was done to make that stuff even more generic. Upgrade notes: * There is a new top-level config option, `account_threepid_delegate` which defines the address of an identity server that you would like to send registration/password reset emails on your behalf. The option `email.trust_identity_server_for_password_resets` has been replaced by this. If you set `email.trust_identity_server_for_password_resets` in your config to `true`, please remove it and configure `account_threepid_delegate` instead. The [sample config](https://github.com/matrix-org/synapse/blob/anoa/reg_email_sending_email/docs/sample_config.yaml) has information on how to configure it. Note: This PR does not allow homeservers to send emails when simply adding an email to your account. That will come after this and will be blocked on a new MSC. Part [2/2] will be successfully completing the registration step when `/submit_token` is hit with the correct details, and clearing out the `password_servlet` flag stuff, which is no longer needed. Will be a much smaller PR than this one. ~~Requires #5863 has been merged into the base branch. ~~Requires #5876 has been merged into the base branch.
…erification (#5940) Fixes: #5751 Fixes: #5928 #5835 allowed Synapse to send registration emails to the user. Now we need to accept them and have it succeed the `m.login.email.identity` registration flow step. `account_threepid_handler` will also be switched from a `str` in the config file to a dictionary which contains entries for `msisdn` and `email`, each with their own `str`. This will let people use an external server to handle `msisdn` registration and password reset requests, while using Synapse for email-based things. And the `password_servlet` hack that was introduced in https://github.com/matrix-org/synapse/pull/5377/files#diff-b8464485d36f6f87caee3f4d82524213R189 to distinguish a registration call from a password reset call will be removed.
|
this is now fixed, thanks to #6011 and all the other PRs which have formed the epic privacy project 🎉 |
Ultimately we want to stop allowing third parties to use the Identity Servers at matrix.org and vector.im to send emails on their behalf for any reason.
The text was updated successfully, but these errors were encountered: