Skip to content
This repository has been archived by the owner on Apr 12, 2024. It is now read-only.

Mainline username generation #120

Closed
wants to merge 9 commits into from
Closed

Conversation

babolivier
Copy link
Contributor

@babolivier babolivier commented Jan 26, 2022

Note to reviewer:

1st commit is a cherry-pick of matrix-org/synapse#11743
2nd commit is a cherry-pick of matrix-org/synapse#11790
3rd commit removes the now obsolete register_mxid_from_3pid setting introduced in matrix-org/synapse#3096
4th commit removes some hacks specific to synapse-dinsic that were made to better ignore username at registration that aren't needed anymore.

Note to ops:

This change removes the register_mxid_from_3pid setting. To reproduce its behaviour, the new inhibit_user_in_use_error setting must be set to true and https://github.com/matrix-org/synapse-username-from-threepid must be installed and configured with threepid_to_use set to the same value as register_mxid_from_3pid was, and fail_if_not_found set to true.

…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
@babolivier babolivier requested a review from a team January 26, 2022 14:45
babolivier and others added 8 commits January 26, 2022 17:58
This is in the context of mainlining the Tchap fork of Synapse. Currently in Tchap usernames are derived from the user's email address (extracted from the UIA results, more specifically the m.login.email.identity step).
This change also exports the check_username method from the registration handler as part of the module API, so that a module can check if the username it's trying to generate is correct and doesn't conflict with an existing one, and fallback gracefully if not.

Co-authored-by: David Robertson <davidr@element.io>
* Deal with mypy errors w/ type-hinted pynacl 1.5.0

Fixes #11644.

I really don't like that we're monkey patching pynacl SignedKey
instances with alg and version objects. But I'm too scared to make the
changes necessary right now.

(Ideally I would replace `signedjson.types.SingingKey` with a runtime class which
wraps or inherits from `nacl.signing.SigningKey`.) C.f. matrix-org/python-signedjson#16
Similar to #11817.

In `_create_power_level_validator` we
- retrieve `validator`. This is a class implementing the
  `jsonschema.protocols.Validator` interface. In other words,
  `validator: Type[jsonschema.protocols.Validator]`.
- we then create an second validator class by modifying the original
  `validator`. We return that class, which is also of type
  `Type[jsonschema.protocols.Validator]`.

So the original annotation was incorrect: it claimed we were returning
an instance of jsonSchema.Draft7Validator, not the class (or a subclass)
itself. (Strictly speaking this is incorrect, because `POWER_LEVELS_SCHEMA`
isn't pinned to a particular version of JSON Schema. But there are other
complications with the type stubs if you try to fix this; I felt like
the change herein was a decent compromise that better expresses intent).

(I suspect/hope the typeshed project would welcome an effort to improve
the jsonschema stubs. Let's see if I get some spare time.)
@babolivier
Copy link
Contributor Author

Right, looks like this rebase went wrong, I'll recreate the PR.

@babolivier babolivier closed this Jan 26, 2022
@babolivier
Copy link
Contributor Author

Superseded by #121

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants