Apply suggestions from code review

Co-authored-by: Hubert Chathi <hubert@uhoreg.ca>
Co-authored-by: penn5 <penn5@users.noreply.github.com>
Co-authored-by: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com>
This commit is contained in:
Travis Ralston 2021-06-22 20:25:46 -06:00 committed by GitHub
parent f9a5b34099
commit fb091fed03
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23

View file

@ -44,13 +44,13 @@ The response body should be unchanged from the existing `/login` specification.
If one of the following conditions are true:
- The access token is not provided
- The access token does not correspond to a appservice
- The access token does not correspond to an appservice
- Or the user has not previously been registered
Then the servers MUST reject with HTTP 403, with an `errcode` of `"M_FORBIDDEN"`.
If the access token DOES correspond to a appservice but the user is not inside its namespace,
then the `errcode` should be `"M_EXCLUSIVE"`.
If the access token DOES correspond to an appservice but the user is not inside its namespace,
then the `errcode` must be `"M_EXCLUSIVE"`.
Homeservers should ignore the `access_token` parameter if a type other than
`m.login.application_service` has been provided.
@ -109,10 +109,10 @@ Furthermore, the ability to generate access tokens for real users who registered
## Security considerations
Appservices could use this new functionality to generate devices for any userId that are within its namespace e.g. setting the
user namespace regex to `@.*:example.com` would allow appservice to control anyone on the homeserver. While this sounds scary, in practise
user namespace regex to `@.*:example.com` would allow appservice to control anyone on the homeserver. While this sounds scary, in practice
this is not a problem because:
- Appservice namespaces are mainained by the homeserver admin. If the namespace were to change, then it's reasonable
- Appservice namespaces are maintained by the homeserver admin. If the namespace were to change, then it's reasonable
to assume that the server admin is aware. There is no defense mechanism to stop a malicious server admin from creating new
devices for a given user's account as they could also do so by simply modifying the database.