Skip to content

Commit

Permalink
MSC4183: Additional Error Codes for submitToken endpoint (#4183)
Browse files Browse the repository at this point in the history
* MSC4180: Additional Error Codes for submitToken endpoint

* Bah, markdown

* Line wrapping

* Typos

* Right MSC number

Co-authored-by: Johannes Marbach <n0-0ne+github@mailbox.org>

* Rename

* Add http status code

* Apply suggestions from code review

Spelling / grammar fixes

Co-authored-by: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com>

* Word wrap

* Clearer wording

* clarify

* Clarify

* Add note about not reusing error code

* Clarify that we're taking about the submittoken api in requestToken

* spelling

* Clearer wording

Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>

* Add note on POST email submitToken api

and how it isn't really a thing in practice

* Hopefully make more clearer

* Apply same change to other submitToken endpoints

...from the other requestToken enpoints

Also try to further clarify the note about the largely unused POST email submitToken

* Remove stray lines, more clarifications & consistency fix

* clarify only c/s api

Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>

* Typos & clarity

Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>

* Clarify

---------

Co-authored-by: Johannes Marbach <n0-0ne+github@mailbox.org>
Co-authored-by: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com>
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
  • Loading branch information
4 people authored Feb 24, 2025
1 parent eb813af commit 93b0353
Showing 1 changed file with 81 additions and 0 deletions.
81 changes: 81 additions & 0 deletions proposals/4183-submitToken-error-codes.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,81 @@
# MSC4183: Additional Error Codes for submitToken endpoints

The [`POST
/_matrix/identity/v2/validate/email/submitToken`](https://spec.matrix.org/v1.11/identity-service-api/#post_matrixidentityv2validateemailsubmittoken)
and [`POST
/_matrix/identity/v2/validate/msisdn/submitToken`](https://spec.matrix.org/v1.11/identity-service-api/#post_matrixidentityv2validatemsisdnsubmittoken)
endpoints do not specify any specific error codes, instead relying on the common error codes defined in the identity
service API.

However, these common error codes don't have any codes to signal many errors that can occur in these APIs: most
obviously, that the token the user entered was incorrect.

This MSC can be considered similar to [MSC4178](https://github.com/matrix-org/matrix-spec-proposals/pull/4178) although
that MSC is for `requestToken` on the C/S API only.

The numerous `requestToken` endpoints (enumerated in the proposal section) in the C/S API also specify a `submit_url`
response parameter, defining their parameters to be the same as the Identity API's `submitToken` endpoints. Everything
this MSC specifies applies to these endpoint in the same way.

Note that the `POST` version of the email `submitToken` endpoint ([`POST
/_matrix/identity/v2/validate/email/submitToken`](https://spec.matrix.org/v1.11/identity-service-api/#post_matrixidentityv2validateemailsubmittoken))
is not generally used in practice: Sydent's emails include a link to click instead of the `submit_url` response field and
therefore use the `GET` version. Synapse does not implement the `POST` API for email validation for this reason. This
proposal updates both `POST` and `GET` versions for consistency.

## Proposal

Add the following specific error code as a code that can be returned by both
[`POST
/_matrix/identity/v2/validate/email/submitToken`](https://spec.matrix.org/v1.11/identity-service-api/#post_matrixidentityv2validateemailsubmittoken)
and [`POST
/_matrix/identity/v2/validate/msisdn/submitToken`](https://spec.matrix.org/v1.11/identity-service-api/#post_matrixidentityv2validatemsisdnsubmittoken):
* `M_TOKEN_INCORRECT`: Indicates that the token that the user entered to validate the session is incorrect.

Note that we deliberately chose not to re-use `M_UNKNOWN_TOKEN` since that refers to an access token, whereas this
refers to a token that the user enters.

HTTP status code 400 should be used for this error.

Additionally specify that the following common error codes can be returned:
* `M_INVALID_PARAM`: One of the supplied parameters in not valid.
* `M_SESSION_EXPIRED`: The validation session is question has expired.

HTTP status code 400 should also be used for both of these errors.

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.:

* [`POST /_matrix/client/v3/register/email/requestToken`](https://spec.matrix.org/v1.11/client-server-api/#post_matrixclientv3registeremailrequesttoken)
* [`POST /_matrix/client/v3/register/msisdn/requestToken`](https://spec.matrix.org/v1.11/client-server-api/#post_matrixclientv3registerrequesttoken)
* [`POST /_matrix/client/v3/account/3pid/email/requestToken`](https://spec.matrix.org/v1.11/client-server-api/#post_matrixclientv3account3pidemailrequesttoken)
* [`POST /_matrix/client/v3/account/3pid/msisdn/requestToken`](https://spec.matrix.org/v1.11/client-server-api/#post_matrixclientv3account3pidmsisdnrequesttoken)
* [`POST /_matrix/client/v3/account/password/email/requestToken`](https://spec.matrix.org/v1.11/client-server-api/#post_matrixclientv3accountpasswordemailrequesttoken)
* [`POST /_matrix/client/v3/account/password/msisdn/requestToken`](https://spec.matrix.org/v1.11/client-server-api/#post_matrixclientv3accountpasswordmsisdnrequesttoken)

...to specify that response parameters and error codes are the same as the I/S API version, as well as request parameters.

## Potential issues

None foreseen.

## Alternatives

None considered.

## Security considerations

None foreseen.

## Unstable prefix

No unstable prefix is deemed necessary. Sydent already sends the common error codes and also sends
`M_NO_VALID_SESSION` if the code is incorrect. Once an identity server (or homeserver) switches to
use the new error code, clients (including homeservers proxying the IS API) may not recognise the
error condition correctly until updated to support the new code. We say that this is acceptable in
favour of avoiding the complexity of negotiating error codes with API versions. Since the identity
server is generally used via the homeserver now, most users of this API will not currently receive
a sensible error code in this situation anyway.

## Dependencies

None

0 comments on commit 93b0353

Please sign in to comment.