Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSC3866: M_USER_AWAITING_APPROVAL error code #3866

Open
wants to merge 6 commits into
base: main
Choose a base branch
from
Open
Changes from 4 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
91 changes: 91 additions & 0 deletions proposals/3866-user-not-approved-error.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,91 @@
# MSC3866: `M_USER_AWAITING_APPROVAL` error code

Over the past few years, there has been some demand for the ability to let
administrators of homeservers approve any new user created on their homeserver
before their account can be used. This allows for better control upon
registration and a potential option for mitigating abuse as an alternative to
disabling registration on a homeserver or forcing new users to fill in
additional details such as an email address.

## Proposal

This document proposes the addition of a new `M_USER_AWAITING_APPROVAL` error
code to the Matrix specification. This error code can be returned in two
scenarios: registration and login.

This proposal does not describe a way for the homeserver to alert an
administrator about new accounts that are waiting to be reviewed, or a way for
administrators to approve or deny an account. This is left as an implementation
detail, as different homeserver implementations have different ways for
administrators to interact with them (e.g. Synapse's admin API vs Conduit's
admin room).

### Registration

When a user successfully registers on a homeserver that is configured so that
new accounts must be approved by an administrator, the final `POST
/_matrix/client/v3/register` request is responded to with a `403 Forbidden`
response that includes the `M_USER_AWAITING_APPROVAL` error code. For example:

```json
{
"errcode": "M_USER_AWAITING_APPROVAL",
"error": "This account needs to be approved by an administrator before it can be used."
}
```

### Login

When a user whose account is still pending approval by a server administrator
attempts to log in, `POST /_matrix/client/v3/login` requests are responded to
babolivier marked this conversation as resolved.
Show resolved Hide resolved
with a `403 Forbidden` response that includes the `M_USER_AWAITING_APPROVAL`
error code. For example:

```json
{
"errcode": "M_USER_AWAITING_APPROVAL",
"error": "This account is pending approval by a server administrator. Please try again later."
}
```

This error can be returned in any login request, as long as the homeserver is
confident that the user trying to log in is pending approval - as opposed to
registration requests where only the last one can return such an error, in order
to ensure the registration completes.

Once an account is approved, homeserver must allow the user to log in (unless
the account becomes unavailable for unrelated reasons, e.g. by getting
deactivated).
babolivier marked this conversation as resolved.
Show resolved Hide resolved

## Potential issues

This MSC does not include a way to communicate to clients early on whether the
homeserver requires new accounts to be approved by an administrator, which can
make the registration experience frustrating (because the user might not be
expecting to need to wait before using your account).

It is also unclear how to inform a user about their account being approved. This
can probably be done on a best-effort basis using contact information (e.g.
email address) provided by the user during the registration process, if any.

## Alternatives

The homeserver could include a boolean indicating whether new accounts require
approval in the response to an initial `/register` request, but it feels out of
place and possibly non-trivial to implement in a way that doesn't get in the way
of User-Interactive Authentication.

## Security considerations

It shouldn't be necessary to implement the `M_USER_AWAITING_APPROVAL` error code
on other endpoints than `/register` and `/login`. This is because other
endpoints are either unauthenticated (in which case we don't care about whether
the user is approved) or authenticated via an access token (in which case the
fact that the user has an access token either means they've managed to log in
(meaning they've been approved) or a server administrator generated one for
them).

## Unstable prefix

During development, `ORG.MATRIX.MSC3866_USER_AWAITING_APPROVAL` must be used
instead of `M_USER_AWAITING_APPROVAL`.