|
| 1 | +# MSC4183: Additional Error Codes for submitToken endpoints |
| 2 | + |
| 3 | +The [`POST |
| 4 | +/_matrix/identity/v2/validate/email/submitToken`](https://spec.matrix.org/v1.11/identity-service-api/#post_matrixidentityv2validateemailsubmittoken) |
| 5 | +and [`POST |
| 6 | +/_matrix/identity/v2/validate/msisdn/submitToken`](https://spec.matrix.org/v1.11/identity-service-api/#post_matrixidentityv2validatemsisdnsubmittoken) |
| 7 | +endpoints do not specify any specific error codes, instead relying on the common error codes defined in the identity |
| 8 | +service API. |
| 9 | + |
| 10 | +However, these common error codes don't have any codes to signal many errors that can occur in these APIs: most |
| 11 | +obviously, that the token the user entered was incorrect. |
| 12 | + |
| 13 | +This MSC can be considered similar to [MSC4178](https://github.com/matrix-org/matrix-spec-proposals/pull/4178) although |
| 14 | +that MSC is for `requestToken` on the C/S API only. |
| 15 | + |
| 16 | +The numerous `requestToken` endpoints (enumerated in the proposal section) in the C/S API also specify a `submit_url` |
| 17 | +response parameter, defining their parameters to be the same as the Identity API's `submitToken` endpoints. Everything |
| 18 | +this MSC specifies applies to these endpoint in the same way. |
| 19 | + |
| 20 | +Note that the `POST` version of the email `submitToken` endpoint ([`POST |
| 21 | +/_matrix/identity/v2/validate/email/submitToken`](https://spec.matrix.org/v1.11/identity-service-api/#post_matrixidentityv2validateemailsubmittoken)) |
| 22 | +is not generally used in practice: Sydent's emails include a link to click instead of the `submit_url` response field and |
| 23 | +therefore use the `GET` version. Synapse does not implement the `POST` API for email validation for this reason. This |
| 24 | +proposal updates both `POST` and `GET` versions for consistency. |
| 25 | + |
| 26 | +## Proposal |
| 27 | + |
| 28 | +Add the following specific error code as a code that can be returned by both |
| 29 | +[`POST |
| 30 | +/_matrix/identity/v2/validate/email/submitToken`](https://spec.matrix.org/v1.11/identity-service-api/#post_matrixidentityv2validateemailsubmittoken) |
| 31 | +and [`POST |
| 32 | +/_matrix/identity/v2/validate/msisdn/submitToken`](https://spec.matrix.org/v1.11/identity-service-api/#post_matrixidentityv2validatemsisdnsubmittoken): |
| 33 | + * `M_TOKEN_INCORRECT`: Indicates that the token that the user entered to validate the session is incorrect. |
| 34 | + |
| 35 | +Note that we deliberately chose not to re-use `M_UNKNOWN_TOKEN` since that refers to an access token, whereas this |
| 36 | +refers to a token that the user enters. |
| 37 | + |
| 38 | +HTTP status code 400 should be used for this error. |
| 39 | + |
| 40 | +Additionally specify that the following common error codes can be returned: |
| 41 | + * `M_INVALID_PARAM`: One of the supplied parameters in not valid. |
| 42 | + * `M_SESSION_EXPIRED`: The validation session is question has expired. |
| 43 | + |
| 44 | +HTTP status code 400 should also be used for both of these errors. |
| 45 | + |
| 46 | +Also apply the same change to the endpoints returned in the `submit_url` fields in the response to the various `POST requestToken` endpoints in the client-server API, i.e.: |
| 47 | + |
| 48 | + * [`POST /_matrix/client/v3/register/email/requestToken`](https://spec.matrix.org/v1.11/client-server-api/#post_matrixclientv3registeremailrequesttoken) |
| 49 | + * [`POST /_matrix/client/v3/register/msisdn/requestToken`](https://spec.matrix.org/v1.11/client-server-api/#post_matrixclientv3registerrequesttoken) |
| 50 | + * [`POST /_matrix/client/v3/account/3pid/email/requestToken`](https://spec.matrix.org/v1.11/client-server-api/#post_matrixclientv3account3pidemailrequesttoken) |
| 51 | + * [`POST /_matrix/client/v3/account/3pid/msisdn/requestToken`](https://spec.matrix.org/v1.11/client-server-api/#post_matrixclientv3account3pidmsisdnrequesttoken) |
| 52 | + * [`POST /_matrix/client/v3/account/password/email/requestToken`](https://spec.matrix.org/v1.11/client-server-api/#post_matrixclientv3accountpasswordemailrequesttoken) |
| 53 | + * [`POST /_matrix/client/v3/account/password/msisdn/requestToken`](https://spec.matrix.org/v1.11/client-server-api/#post_matrixclientv3accountpasswordmsisdnrequesttoken) |
| 54 | + |
| 55 | +...to specify that response parameters and error codes are the same as the I/S API version, as well as request parameters. |
| 56 | + |
| 57 | +## Potential issues |
| 58 | + |
| 59 | +None foreseen. |
| 60 | + |
| 61 | +## Alternatives |
| 62 | + |
| 63 | +None considered. |
| 64 | + |
| 65 | +## Security considerations |
| 66 | + |
| 67 | +None foreseen. |
| 68 | + |
| 69 | +## Unstable prefix |
| 70 | + |
| 71 | +No unstable prefix is deemed necessary. Sydent already sends the common error codes and also sends |
| 72 | +`M_NO_VALID_SESSION` if the code is incorrect. Once an identity server (or homeserver) switches to |
| 73 | +use the new error code, clients (including homeservers proxying the IS API) may not recognise the |
| 74 | +error condition correctly until updated to support the new code. We say that this is acceptable in |
| 75 | +favour of avoiding the complexity of negotiating error codes with API versions. Since the identity |
| 76 | +server is generally used via the homeserver now, most users of this API will not currently receive |
| 77 | +a sensible error code in this situation anyway. |
| 78 | + |
| 79 | +## Dependencies |
| 80 | + |
| 81 | +None |
0 commit comments