From 67e558da524acdc1c497afa314d8a3eb9810de0f Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Tue, 20 Jul 2021 13:23:17 -0400 Subject: [PATCH] Review feedback. --- proposals/3083-restricted-rooms.md | 60 ++++++++++++++++-------------- 1 file changed, 33 insertions(+), 27 deletions(-) diff --git a/proposals/3083-restricted-rooms.md b/proposals/3083-restricted-rooms.md index 83073f21..923477dc 100644 --- a/proposals/3083-restricted-rooms.md +++ b/proposals/3083-restricted-rooms.md @@ -63,45 +63,35 @@ if the user is invited to this room, or is joined to one of the listed rooms. If the user is not a member of at least one of the rooms, the homeserver should return an error response with HTTP status code of 403 and an `errcode` of `M_FORBIDDEN`. -It is possible for a resident homeserver (one which receives a `/make_join` / -`/send_join` request) to not know if the user is in some of the allowed rooms (due -to not participating in them). If the user is not in any of the allowed rooms that -are known to the homeserver it should return an error response with HTTP status code -of 400 with an `errcode` of `M_UNABLE_TO_AUTHORISE_JOIN`. The joining server should -attempt to join via another resident homeserver. If the resident homeserver knows -that the user is not in *any* of the allowed rooms it should return an error response -with HTTP status code of 403 and an `errcode` of `M_FORBIDDEN`. Note that it is a -configuration error if there are allowed rooms with no participating authorised -servers. - -A chosen resident homeserver might also be unable to issue invites; in this case -it should return an error response with HTTP status code of 400 and an `errcode` -of `M_CANNOT_ALLOW`. The joining server should attempt to join via another -resident homeserver. - From the perspective of the [auth rules](https://spec.matrix.org/unstable/rooms/v1/#authorization-rules), the `restricted` join rule has the same behavior as `public`, with the additional caveat that servers must ensure that: * The user's previous membership was `invite` or `join`, or -* The join event has a valid signature - from a homeserver whose users have the power to issue invites. This implies - that: +* The join event has a valid signature from a homeserver whose users have the + power to issue invites. + + When generating a join event the server should include the MXID of a local user + who could issue an invite in the content with the key + `join_authorised_via_users_server`. The actual user chosen is arbitrary. + + This implies that: * A join event issued via `/send_join` is signed by not just the requesting server, but also the resident server.[3](#f3) In order for the joining server to receive the proper signatures the join event will be returned via `/send_join` in the `event` field. - * The auth chain of the join event needs to include an event which proves - the homeserver can be issuing the join. This can be done by including the - `m.room.power_levels` event and an `m.room.member` event with `membership` - equal to `join` for a member who could issue invites from that server. + * The auth chain of the join event needs to include events which prove + the homeserver can be issuing the join. This can be done by including: - In order to find a corresponding event quickly for verification, the - content of the join event should include the chosen user's MXID in the - content with the key `join_authorised_via_users_server`. The actual user - chosen is arbitrary. + * The `m.room.power_levels` event + * The `m.room.member` event (with `membership` equal to `join`) the user + specified in `join_authorised_via_users_server`. + + It should be confirmed that the authorising user is in the room. (This + prevents situations where any homeserver could process the join, even if + they weren't in the room, under certain power level conditions.) This creates a new restriction on the relationship between the resident servers used for `/make_join` and `/send_join` -- they must now both go to @@ -113,6 +103,22 @@ Note that the homeservers whose users can issue invites are trusted to confirm that the `allow` rules were properly checked (since this cannot easily be enforced over federation by event authorisation).[4](#f4) +It is possible for a resident homeserver (one which receives a `/make_join` / +`/send_join` request) to not know if the user is in some of the allowed rooms (due +to not participating in them). If the user is not in any of the allowed rooms that +are known to the homeserver it should return an error response with HTTP status code +of 400 with an `errcode` of `M_UNABLE_TO_AUTHORISE_JOIN`. The joining server should +attempt to join via another resident homeserver. If the resident homeserver knows +that the user is not in *any* of the allowed rooms it should return an error response +with HTTP status code of 403 and an `errcode` of `M_FORBIDDEN`. Note that it is a +configuration error if there are allowed rooms with no participating authorised +servers. + +A chosen resident homeserver might also be unable to issue invites; in this case +it should return an error response with HTTP status code of 400 and an `errcode` +of `M_CANNOT_ALLOW`. The joining server should attempt to join via another +resident homeserver. + To better cope with joining via aliases, homeservers should use the list of authorised servers (not the list of candidate servers) when a user attempts to join a room.