From bf747b640920d94802a2fb27f7e97d96796e27ed Mon Sep 17 00:00:00 2001 From: Andrew Morgan Date: Tue, 16 Jul 2019 11:26:32 +0100 Subject: [PATCH 01/11] Add proposal regarding user deactivated err codes --- proposals/2181-user-deactivated-errcode.md | 53 ++++++++++++++++++++++ 1 file changed, 53 insertions(+) create mode 100644 proposals/2181-user-deactivated-errcode.md diff --git a/proposals/2181-user-deactivated-errcode.md b/proposals/2181-user-deactivated-errcode.md new file mode 100644 index 00000000000..1aed6f5e478 --- /dev/null +++ b/proposals/2181-user-deactivated-errcode.md @@ -0,0 +1,53 @@ +# Add an Error Code for Signaling a Deactivated User + +Currently, when a user attempts to log in, they will receive an `M_FORBIDDEN` +errcode if their password is incorrect. However, if the user's account is +deactivated, they will also receive an `M_FORBIDDEN`, leaving clients in a +state where they are unable to inform the user that the reason they cannot +log in is that their account has been deactivated. This leads to confusion +and password resetting with ultimately results in unnecessary support +requests. + +## Proposal + +This proposal asks to create a new errcode, `M_USER_DEACTIVATED`, that can be +returned whenever an action is attempted that requires an activited user, but +the authenticating user is deactivated. The recommended HTTP code to return +alongside is `403`. + +The template should have the following sections: + +* **Introduction** - This should cover the primary problem and broad description of the solution. +* **Proposal** - The gory details of the proposal. +* **Tradeoffs** - Any items of the proposal that are less desirable should be listed here. Alternative + solutions to the same problem could also be listed here. +* **Potential issues** - This is where problems with the proposal would be listed, such as changes + that are not backwards compatible. +* **Security considerations** - Discussion of what steps were taken to avoid security issues in the + future and any potential risks in the proposal. +* **Conclusion** - A repeat of the problem and solution. + +Furthermore, the template should not be required to be followed. However it is strongly recommended to +maintain some sense of consistency between proposals. + + +## Tradeoffs + +The alternative is to continue returning an `M_FORBIDDEN`, but send back a +different errmsg. This is undesirable as it requires clients to pattern match +on a long phrase that could be minutely changed at any time, breaking +everything. + +## Potential issues + +None + +## Security considerations + +This would allow users to be able to detect if their account had been +deactivated. This is probably something we'd like to allow though. + +## Conclusion + +Adding `M_USER_DEACTIVATED` would better inform clients about the state of a +user's account, and lead to less confusion when they cannot log in. From 7a08bc9fd745f564b4a89f62edcca7ee4863ca6b Mon Sep 17 00:00:00 2001 From: Andrew Morgan Date: Tue, 16 Jul 2019 11:29:57 +0100 Subject: [PATCH 02/11] Remove template bit --- proposals/2181-user-deactivated-errcode.md | 16 ---------------- 1 file changed, 16 deletions(-) diff --git a/proposals/2181-user-deactivated-errcode.md b/proposals/2181-user-deactivated-errcode.md index 1aed6f5e478..d9297e03578 100644 --- a/proposals/2181-user-deactivated-errcode.md +++ b/proposals/2181-user-deactivated-errcode.md @@ -15,22 +15,6 @@ returned whenever an action is attempted that requires an activited user, but the authenticating user is deactivated. The recommended HTTP code to return alongside is `403`. -The template should have the following sections: - -* **Introduction** - This should cover the primary problem and broad description of the solution. -* **Proposal** - The gory details of the proposal. -* **Tradeoffs** - Any items of the proposal that are less desirable should be listed here. Alternative - solutions to the same problem could also be listed here. -* **Potential issues** - This is where problems with the proposal would be listed, such as changes - that are not backwards compatible. -* **Security considerations** - Discussion of what steps were taken to avoid security issues in the - future and any potential risks in the proposal. -* **Conclusion** - A repeat of the problem and solution. - -Furthermore, the template should not be required to be followed. However it is strongly recommended to -maintain some sense of consistency between proposals. - - ## Tradeoffs The alternative is to continue returning an `M_FORBIDDEN`, but send back a From 4f54b8b4a727cafd2e2bf8e5a07e32153efb6569 Mon Sep 17 00:00:00 2001 From: Andrew Morgan Date: Tue, 16 Jul 2019 15:26:16 +0100 Subject: [PATCH 03/11] Update with review comments --- proposals/2181-user-deactivated-errcode.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/proposals/2181-user-deactivated-errcode.md b/proposals/2181-user-deactivated-errcode.md index d9297e03578..8f92d714d4a 100644 --- a/proposals/2181-user-deactivated-errcode.md +++ b/proposals/2181-user-deactivated-errcode.md @@ -12,15 +12,15 @@ requests. This proposal asks to create a new errcode, `M_USER_DEACTIVATED`, that can be returned whenever an action is attempted that requires an activited user, but -the authenticating user is deactivated. The recommended HTTP code to return -alongside is `403`. +the authenticating user is deactivated. The HTTP code to return alongside is +`403`. ## Tradeoffs The alternative is to continue returning an `M_FORBIDDEN`, but send back a -different errmsg. This is undesirable as it requires clients to pattern match -on a long phrase that could be minutely changed at any time, breaking -everything. +different errmsg. This is undesirable as clients are supposed to treat the +message as an opaque string, and should not be performing any +pattern-matching on it. ## Potential issues @@ -28,8 +28,9 @@ None ## Security considerations -This would allow users to be able to detect if their account had been -deactivated. This is probably something we'd like to allow though. +While the existence of a user was already public knowledge (one can check if +the User ID is available through `/register`, this proposal would allow any +user to be able to detect if a registered account has been deactivated. ## Conclusion From 028ea8950ab297069720c42b4e2c502d4378fc4f Mon Sep 17 00:00:00 2001 From: Andrew Morgan Date: Tue, 16 Jul 2019 16:03:56 +0100 Subject: [PATCH 04/11] /available --- proposals/2181-user-deactivated-errcode.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/proposals/2181-user-deactivated-errcode.md b/proposals/2181-user-deactivated-errcode.md index 8f92d714d4a..37b27963a64 100644 --- a/proposals/2181-user-deactivated-errcode.md +++ b/proposals/2181-user-deactivated-errcode.md @@ -29,8 +29,10 @@ None ## Security considerations While the existence of a user was already public knowledge (one can check if -the User ID is available through `/register`, this proposal would allow any -user to be able to detect if a registered account has been deactivated. +the User ID is available through +[/_matrix/client/r0/register/available](https://matrix.org/docs/spec/client_server/r0.5.0#get-matrix-client-r0-register-available), +this proposal would allow any user to be able to detect if a registered +account has been deactivated. ## Conclusion From 7f1e822f1918d7468d948ecc0eba30f4c22a5605 Mon Sep 17 00:00:00 2001 From: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com> Date: Fri, 19 Jul 2019 11:22:41 +0100 Subject: [PATCH 05/11] Update proposals/2181-user-deactivated-errcode.md Co-Authored-By: Hubert Chathi --- proposals/2181-user-deactivated-errcode.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/2181-user-deactivated-errcode.md b/proposals/2181-user-deactivated-errcode.md index 37b27963a64..60e1400de42 100644 --- a/proposals/2181-user-deactivated-errcode.md +++ b/proposals/2181-user-deactivated-errcode.md @@ -10,7 +10,7 @@ requests. ## Proposal -This proposal asks to create a new errcode, `M_USER_DEACTIVATED`, that can be +This proposal asks to create a new errcode, `M_USER_DEACTIVATED`, that MAY be returned whenever an action is attempted that requires an activited user, but the authenticating user is deactivated. The HTTP code to return alongside is `403`. From c1dd80492ae4ffdf680de875edd2ce5b463ffcd9 Mon Sep 17 00:00:00 2001 From: Andrew Morgan Date: Fri, 19 Jul 2019 16:42:51 +0100 Subject: [PATCH 06/11] Specify /login should have M_USER_DEACTIVATED --- proposals/2181-user-deactivated-errcode.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/proposals/2181-user-deactivated-errcode.md b/proposals/2181-user-deactivated-errcode.md index 37b27963a64..8674c9a4dd9 100644 --- a/proposals/2181-user-deactivated-errcode.md +++ b/proposals/2181-user-deactivated-errcode.md @@ -15,6 +15,11 @@ returned whenever an action is attempted that requires an activited user, but the authenticating user is deactivated. The HTTP code to return alongside is `403`. +This should initially be returned by `/login`, when an identifier of a +deactivated user is sent in the request. The password does not have to be +correct, as some homeserver implementations remove password information on +deactivation. + ## Tradeoffs The alternative is to continue returning an `M_FORBIDDEN`, but send back a From f3ca0331419efab953ed8d48d1de0e1eec716519 Mon Sep 17 00:00:00 2001 From: Andrew Morgan Date: Mon, 22 Jul 2019 11:38:43 +0100 Subject: [PATCH 07/11] kill the hashes --- proposals/2181-user-deactivated-errcode.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/2181-user-deactivated-errcode.md b/proposals/2181-user-deactivated-errcode.md index 85b23888afa..254237b9e54 100644 --- a/proposals/2181-user-deactivated-errcode.md +++ b/proposals/2181-user-deactivated-errcode.md @@ -17,7 +17,7 @@ the authenticating user is deactivated. The HTTP code to return alongside is This should initially be returned by `/login`, when an identifier of a deactivated user is sent in the request. The password does not have to be -correct, as some homeserver implementations remove password information on +correct, as homeserver implementations should remove password information on deactivation. ## Tradeoffs From a126fbbd3402a835d851ffe4d4f29f47aee77498 Mon Sep 17 00:00:00 2001 From: Andrew Morgan Date: Mon, 22 Jul 2019 15:00:24 +0100 Subject: [PATCH 08/11] Implementation details --- proposals/2181-user-deactivated-errcode.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/proposals/2181-user-deactivated-errcode.md b/proposals/2181-user-deactivated-errcode.md index 254237b9e54..6d40babb44e 100644 --- a/proposals/2181-user-deactivated-errcode.md +++ b/proposals/2181-user-deactivated-errcode.md @@ -16,9 +16,9 @@ the authenticating user is deactivated. The HTTP code to return alongside is `403`. This should initially be returned by `/login`, when an identifier of a -deactivated user is sent in the request. The password does not have to be -correct, as homeserver implementations should remove password information on -deactivation. +deactivated user is sent in the request. Whether the password has to be +correct depends on whether the Homeserver implementation removes login +information on deactivation. This is an implementation detail. ## Tradeoffs From 8c993ae0fd96089b172e7c810b3448e859d076e0 Mon Sep 17 00:00:00 2001 From: Andrew Morgan Date: Tue, 23 Jul 2019 12:05:09 +0100 Subject: [PATCH 09/11] respond to review comments --- proposals/2181-user-deactivated-errcode.md | 33 +++++++++++++--------- 1 file changed, 19 insertions(+), 14 deletions(-) diff --git a/proposals/2181-user-deactivated-errcode.md b/proposals/2181-user-deactivated-errcode.md index 6d40babb44e..fc9f2d24177 100644 --- a/proposals/2181-user-deactivated-errcode.md +++ b/proposals/2181-user-deactivated-errcode.md @@ -1,30 +1,35 @@ # Add an Error Code for Signaling a Deactivated User Currently, when a user attempts to log in, they will receive an `M_FORBIDDEN` -errcode if their password is incorrect. However, if the user's account is +error code if their password is incorrect. However, if the user's account is deactivated, they will also receive an `M_FORBIDDEN`, leaving clients in a state where they are unable to inform the user that the reason they cannot log in is that their account has been deactivated. This leads to confusion -and password resetting with ultimately results in unnecessary support -requests. +and password resetting which ultimately results in frustration. ## Proposal -This proposal asks to create a new errcode, `M_USER_DEACTIVATED`, that MAY be -returned whenever an action is attempted that requires an activited user, but -the authenticating user is deactivated. The HTTP code to return alongside is -`403`. +This proposal asks to create a new error code, `M_USER_DEACTIVATED`, that may +be returned whenever an action is attempted that requires an activited user, +but the authenticating user is deactivated. The HTTP code to return alongside +is `403`. -This should initially be returned by `/login`, when an identifier of a -deactivated user is sent in the request. Whether the password has to be -correct depends on whether the Homeserver implementation removes login -information on deactivation. This is an implementation detail. +An example of this could be returning `M_USER_DEACTIVED` on `/login`, when an +identifier of a deactivated user is sent to the homeserver. Whether the +password has to be correct depends on whether the Homeserver implementation +removes login information on deactivation. This is an implementation detail. + +It should be noted that this proposal is not requiring implementations to +return `M_USER_DEACTIVATED` on any endpoints when a request from a +deactivated user appears. Instead it is simply defining the new error code, +that it can be used by the homeserver when it chooses and that the client +should understand what it means. ## Tradeoffs The alternative is to continue returning an `M_FORBIDDEN`, but send back a -different errmsg. This is undesirable as clients are supposed to treat the -message as an opaque string, and should not be performing any +different error message. This is undesirable as clients are supposed to treat +the message as an opaque string, and should not be performing any pattern-matching on it. ## Potential issues @@ -37,7 +42,7 @@ While the existence of a user was already public knowledge (one can check if the User ID is available through [/_matrix/client/r0/register/available](https://matrix.org/docs/spec/client_server/r0.5.0#get-matrix-client-r0-register-available), this proposal would allow any user to be able to detect if a registered -account has been deactivated. +account has been deactivated, depending on the homeserver's implementation. ## Conclusion From f3358e45531cdd2e80b4c443419bbe8e40217b86 Mon Sep 17 00:00:00 2001 From: Andrew Morgan Date: Fri, 26 Jul 2019 10:32:41 +0100 Subject: [PATCH 10/11] Fix typo --- proposals/2181-user-deactivated-errcode.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/2181-user-deactivated-errcode.md b/proposals/2181-user-deactivated-errcode.md index fc9f2d24177..89da8fe2298 100644 --- a/proposals/2181-user-deactivated-errcode.md +++ b/proposals/2181-user-deactivated-errcode.md @@ -14,8 +14,8 @@ be returned whenever an action is attempted that requires an activited user, but the authenticating user is deactivated. The HTTP code to return alongside is `403`. -An example of this could be returning `M_USER_DEACTIVED` on `/login`, when an -identifier of a deactivated user is sent to the homeserver. Whether the +An example of this could be returning `M_USER_DEACTIVATED` on `/login`, when +an identifier of a deactivated user is sent to the homeserver. Whether the password has to be correct depends on whether the Homeserver implementation removes login information on deactivation. This is an implementation detail. From 502f5d5a905738aa3f92be6a3cfbcecc02b75e63 Mon Sep 17 00:00:00 2001 From: Andrew Morgan Date: Fri, 26 Jul 2019 11:13:53 +0100 Subject: [PATCH 11/11] Be less wishy-washy --- proposals/2181-user-deactivated-errcode.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/2181-user-deactivated-errcode.md b/proposals/2181-user-deactivated-errcode.md index 89da8fe2298..8d2e1893edc 100644 --- a/proposals/2181-user-deactivated-errcode.md +++ b/proposals/2181-user-deactivated-errcode.md @@ -22,8 +22,8 @@ removes login information on deactivation. This is an implementation detail. It should be noted that this proposal is not requiring implementations to return `M_USER_DEACTIVATED` on any endpoints when a request from a deactivated user appears. Instead it is simply defining the new error code, -that it can be used by the homeserver when it chooses and that the client -should understand what it means. +recommends that it should be used in situations as described above, and that +the client should understand the meaning of it when it is received. ## Tradeoffs