From 4751785a8c7fea71552188cdfe1a0b6e97599d16 Mon Sep 17 00:00:00 2001 From: Will Hunt Date: Wed, 16 Sep 2020 18:26:32 +0100 Subject: [PATCH] Some spelling fixes --- proposals/2778-appservice-login.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/proposals/2778-appservice-login.md b/proposals/2778-appservice-login.md index ba3ae1f1..22e06eb7 100644 --- a/proposals/2778-appservice-login.md +++ b/proposals/2778-appservice-login.md @@ -32,7 +32,8 @@ Example request The response body should be unchanged from the existing `/login` specification. -If +If: + - The access token is not provided - The access token does not correspond to a appservice - The access token does not correspond to a appservice that manages this user @@ -44,7 +45,7 @@ Homeservers should ignore the `access_token` parameter if a type other than `m.login.application_service` has been provided. The expected flow for appservices would be to `/register` their users, and -then `/login` to generate the appropraite device. +then `/login` to generate the appropriate device. ## Potential issues @@ -56,12 +57,13 @@ new devices should the appservice intentionally or inadvertently lost the client One minor tweak to the current proposal could be to include the token as part of the auth data, rather than being part of the header/params to the request. An argument could be made for either, but since the specification -expects the appservice to pass the token this way in all requests, including /register it seems wise to keep +expects the appservice to pass the token this way in all requests, including `/register`, it seems wise to keep it that way. Some community members have used implementation details such as a "shared secret" authentication method to log into the accounts without having to use the /login process at all. Synapse provides such a function, -but also means the appservice can now authenticate as any user on the homeserver. +but also means the appservice can now authenticate as any user on the homeserver. This seems undesirable from a +security standpoint. A third option could be to create a new endpoint that simply creates a new device for an appservice user on demand. Given the rest of the matrix eco-system does this with /login, and /login is already extensible with `type`, it would