-
-
Notifications
You must be signed in to change notification settings - Fork 3
Prevent M_USER_IN_USE from being raised by registration methods until after email has been verified #48
Conversation
@anoadragon453 I had a look on your PR. I'm sorry but I think you took a wrong way. We should not abort the register request because the provided username is already used. I'm available to sync with you in order to expose my point of view |
@giomfo OK, let's sync tomorrow |
About |
@anoadragon453 I don't know if I'm right, but don't you think you should pass Perhaps this change is useless in case of Tchap. I don't know |
|
||
self.assertEquals(channel.result["code"], b"400", channel.result) | ||
self.assertEquals(channel.json_body["error"], "Invalid username") | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test is no longer relevant.
@giomfo Have updated to:
|
@@ -357,15 +357,9 @@ async def on_GET(self, request): | |||
403, "Registration has been disabled", errcode=Codes.FORBIDDEN | |||
) | |||
|
|||
ip = self.hs.get_ip_from_request(request) | |||
with self.ratelimiter.ratelimit(ip) as wait_deferred: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why do you remove the ratelimiter
check here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now that this endpoint just always returns {"available": True}
I don't think there's much point in ratelimiting it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you're right, I agree
I forgot it was change about /register/available
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, hard to notice in the diff :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SGTM
) This is mostly motivated by the tchap use case, where usernames are automatically generated from the user's email address (in a way that allows figuring out the email address from the username). Therefore, it's an issue if we respond to requests on /register and /register/available with M_USER_IN_USE, because it can potentially leak email addresses (which include the user's real name and place of work). This commit adds a flag to inhibit the M_USER_IN_USE errors that are raised both by /register/available, and when providing a username early into the registration process. This error will still be raised if the user completes the registration process but the username conflicts. This is particularly useful when using modules (#11790 adds a module callback to set the username of users at registration) or SSO, since they can ensure the username is unique. More context is available in the PR that introduced this behaviour to synapse-dinsic: matrix-org/synapse-dinsic#48 - as well as the issue in the matrix-dinsic repo: matrix-org/matrix-dinsic#476
…743) This is mostly motivated by the tchap use case, where usernames are automatically generated from the user's email address (in a way that allows figuring out the email address from the username). Therefore, it's an issue if we respond to requests on /register and /register/available with M_USER_IN_USE, because it can potentially leak email addresses (which include the user's real name and place of work). This commit adds a flag to inhibit the M_USER_IN_USE errors that are raised both by /register/available, and when providing a username early into the registration process. This error will still be raised if the user completes the registration process but the username conflicts. This is particularly useful when using modules (matrix-org/synapse#11790 adds a module callback to set the username of users at registration) or SSO, since they can ensure the username is unique. More context is available in the PR that introduced this behaviour to synapse-dinsic: #48 - as well as the issue in the matrix-dinsic repo: matrix-org/matrix-dinsic#476
) This is mostly motivated by the tchap use case, where usernames are automatically generated from the user's email address (in a way that allows figuring out the email address from the username). Therefore, it's an issue if we respond to requests on /register and /register/available with M_USER_IN_USE, because it can potentially leak email addresses (which include the user's real name and place of work). This commit adds a flag to inhibit the M_USER_IN_USE errors that are raised both by /register/available, and when providing a username early into the registration process. This error will still be raised if the user completes the registration process but the username conflicts. This is particularly useful when using modules (#11790 adds a module callback to set the username of users at registration) or SSO, since they can ensure the username is unique. More context is available in the PR that introduced this behaviour to synapse-dinsic: matrix-org/synapse-dinsic#48 - as well as the issue in the matrix-dinsic repo: matrix-org/matrix-dinsic#476
Prevents
M_USER_IN_USE
from being returned to the client before they're verified an associated email.