From 6fb950ab6d892225ed55e9b24eab760b6438dd1d Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Tue, 4 Oct 2022 17:54:43 +0100 Subject: [PATCH 1/7] Clarify wording of auth rule 1.1 what exactly is a "previous event" --- content/rooms/fragments/v1-auth-rules.md | 2 +- content/rooms/fragments/v3-auth-rules.md | 2 +- content/rooms/fragments/v8-auth-rules.md | 2 +- content/rooms/v10.md | 2 +- content/rooms/v6.md | 2 +- content/rooms/v7.md | 2 +- 6 files changed, 6 insertions(+), 6 deletions(-) diff --git a/content/rooms/fragments/v1-auth-rules.md b/content/rooms/fragments/v1-auth-rules.md index 242c7620c..d438d514f 100644 --- a/content/rooms/fragments/v1-auth-rules.md +++ b/content/rooms/fragments/v1-auth-rules.md @@ -19,7 +19,7 @@ the default power level for users in the room. The rules are as follows: 1. If type is `m.room.create`: - 1. If it has any previous events, reject. + 1. If it has any `prev_events`, reject. 2. If the domain of the `room_id` does not match the domain of the `sender`, reject. 3. If `content.room_version` is present and is not a recognised diff --git a/content/rooms/fragments/v3-auth-rules.md b/content/rooms/fragments/v3-auth-rules.md index d5da48c54..2f5c8b527 100644 --- a/content/rooms/fragments/v3-auth-rules.md +++ b/content/rooms/fragments/v3-auth-rules.md @@ -26,7 +26,7 @@ the default power level for users in the room. The complete list of rules, as of room version 3, is as follows: 1. If type is `m.room.create`: - 1. If it has any previous events, reject. + 1. If it has any `prev_events`, reject. 2. If the domain of the `room_id` does not match the domain of the `sender`, reject. 3. If `content.room_version` is present and is not a recognised diff --git a/content/rooms/fragments/v8-auth-rules.md b/content/rooms/fragments/v8-auth-rules.md index f1e0532eb..e1a762a35 100644 --- a/content/rooms/fragments/v8-auth-rules.md +++ b/content/rooms/fragments/v8-auth-rules.md @@ -27,7 +27,7 @@ the default power level for users in the room. The rules are as follows: 1. If type is `m.room.create`: - 1. If it has any previous events, reject. + 1. If it has any `prev_events`, reject. 2. If the domain of the `room_id` does not match the domain of the `sender`, reject. 3. If `content.room_version` is present and is not a recognised diff --git a/content/rooms/v10.md b/content/rooms/v10.md index d5d294e9d..d5979d917 100644 --- a/content/rooms/v10.md +++ b/content/rooms/v10.md @@ -99,7 +99,7 @@ the default power level for users in the room. The rules are as follows: 1. If type is `m.room.create`: - 1. If it has any previous events, reject. + 1. If it has any `prev_events`, reject. 2. If the domain of the `room_id` does not match the domain of the `sender`, reject. 3. If `content.room_version` is present and is not a recognised diff --git a/content/rooms/v6.md b/content/rooms/v6.md index 0e2e70dc6..c88887da7 100644 --- a/content/rooms/v6.md +++ b/content/rooms/v6.md @@ -74,7 +74,7 @@ the default power level for users in the room. The rules are as follows: 1. If type is `m.room.create`: - 1. If it has any previous events, reject. + 1. If it has any `prev_events`, reject. 2. If the domain of the `room_id` does not match the domain of the `sender`, reject. 3. If `content.room_version` is present and is not a recognised diff --git a/content/rooms/v7.md b/content/rooms/v7.md index 8bb4dad27..8a0a82944 100644 --- a/content/rooms/v7.md +++ b/content/rooms/v7.md @@ -60,7 +60,7 @@ the default power level for users in the room. The rules are as follows: 1. If type is `m.room.create`: - 1. If it has any previous events, reject. + 1. If it has any `prev_events`, reject. 2. If the domain of the `room_id` does not match the domain of the `sender`, reject. 3. If `content.room_version` is present and is not a recognised From 66f0b52c2746f4c33297b74da99b5786cfb25f6a Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Tue, 4 Oct 2022 17:57:13 +0100 Subject: [PATCH 2/7] Fix wording of auth rule 5.1.1 `state_key` is not a subkey of `content` --- content/rooms/fragments/v1-auth-rules.md | 3 ++- content/rooms/fragments/v3-auth-rules.md | 3 ++- content/rooms/fragments/v8-auth-rules.md | 3 ++- content/rooms/v10.md | 3 ++- content/rooms/v6.md | 3 ++- content/rooms/v7.md | 3 ++- 6 files changed, 12 insertions(+), 6 deletions(-) diff --git a/content/rooms/fragments/v1-auth-rules.md b/content/rooms/fragments/v1-auth-rules.md index d438d514f..b09078298 100644 --- a/content/rooms/fragments/v1-auth-rules.md +++ b/content/rooms/fragments/v1-auth-rules.md @@ -45,7 +45,8 @@ The rules are as follows: 2. If sender's domain doesn't matches `state_key`, reject. 3. Otherwise, allow. 5. If type is `m.room.member`: - 1. If no `state_key` key or `membership` key in `content`, reject. + 1. If there is no `state_key` property, or no `membership` property in + `content`, reject. 2. If `membership` is `join`: 1. If the only previous event is an `m.room.create` and the `state_key` is the creator, allow. diff --git a/content/rooms/fragments/v3-auth-rules.md b/content/rooms/fragments/v3-auth-rules.md index 2f5c8b527..7a8bc23b4 100644 --- a/content/rooms/fragments/v3-auth-rules.md +++ b/content/rooms/fragments/v3-auth-rules.md @@ -52,7 +52,8 @@ The complete list of rules, as of room version 3, is as follows: 2. If sender's domain doesn't matches `state_key`, reject. 3. Otherwise, allow. 5. If type is `m.room.member`: - 1. If no `state_key` key or `membership` key in `content`, reject. + 1. If there is no `state_key` property, or no `membership` property in + `content`, reject. 2. If `membership` is `join`: 1. If the only previous event is an `m.room.create` and the `state_key` is the creator, allow. diff --git a/content/rooms/fragments/v8-auth-rules.md b/content/rooms/fragments/v8-auth-rules.md index e1a762a35..90ba02b0d 100644 --- a/content/rooms/fragments/v8-auth-rules.md +++ b/content/rooms/fragments/v8-auth-rules.md @@ -49,7 +49,8 @@ The rules are as follows: property `m.federate` set to `false`, and the `sender` domain of the event does not match the `sender` domain of the create event, reject. 4. If type is `m.room.member`: - 1. If no `state_key` key or `membership` key in `content`, reject. + 1. If there is no `state_key` property, or no `membership` property in + `content`, reject. 2. If `content` has a `join_authorised_via_users_server` key: 1. If the event is not validly signed by the homeserver of the user ID denoted diff --git a/content/rooms/v10.md b/content/rooms/v10.md index d5979d917..c34029ec4 100644 --- a/content/rooms/v10.md +++ b/content/rooms/v10.md @@ -121,7 +121,8 @@ The rules are as follows: property `m.federate` set to `false`, and the `sender` domain of the event does not match the `sender` domain of the create event, reject. 4. If type is `m.room.member`: - 1. If no `state_key` key or `membership` key in `content`, reject. + 1. If there is no `state_key` property, or no `membership` property in + `content`, reject. 2. If `content` has a `join_authorised_via_users_server` key: 1. If the event is not validly signed by the homeserver of the user ID denoted diff --git a/content/rooms/v6.md b/content/rooms/v6.md index c88887da7..eed37beae 100644 --- a/content/rooms/v6.md +++ b/content/rooms/v6.md @@ -90,7 +90,8 @@ The rules are as follows: 3. If event does not have a `m.room.create` in its `auth_events`, reject. 4. If type is `m.room.member`: - 1. If no `state_key` key or `membership` key in `content`, reject. + 1. If there is no `state_key` property, or no `membership` property in + `content`, reject. 2. If `membership` is `join`: 1. If the only previous event is an `m.room.create` and the `state_key` is the creator, allow. diff --git a/content/rooms/v7.md b/content/rooms/v7.md index 8a0a82944..87dea0e20 100644 --- a/content/rooms/v7.md +++ b/content/rooms/v7.md @@ -76,7 +76,8 @@ The rules are as follows: 3. If event does not have a `m.room.create` in its `auth_events`, reject. 4. If type is `m.room.member`: - 1. If no `state_key` key or `membership` key in `content`, reject. + 1. If there is no `state_key` property, or no `membership` property in + `content`, reject. 2. If `membership` is `join`: 1. If the only previous event is an `m.room.create` and the `state_key` is the creator, allow. From 16f0ec9861331a0ea266027ddebcd22f717653df Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Tue, 4 Oct 2022 18:00:24 +0100 Subject: [PATCH 3/7] Fix references to "keys" and "fields" in the auth rules Fixes #1112 --- content/rooms/fragments/v1-auth-rules.md | 12 ++++++------ content/rooms/fragments/v3-auth-rules.md | 14 +++++++------- content/rooms/fragments/v8-auth-rules.md | 17 ++++++++--------- content/rooms/v10.md | 14 +++++++------- content/rooms/v6.md | 14 +++++++------- content/rooms/v7.md | 14 +++++++------- 6 files changed, 42 insertions(+), 43 deletions(-) diff --git a/content/rooms/fragments/v1-auth-rules.md b/content/rooms/fragments/v1-auth-rules.md index b09078298..289e40e55 100644 --- a/content/rooms/fragments/v1-auth-rules.md +++ b/content/rooms/fragments/v1-auth-rules.md @@ -24,7 +24,7 @@ The rules are as follows: `sender`, reject. 3. If `content.room_version` is present and is not a recognised version, reject. - 4. If `content` has no `creator` field, reject. + 4. If `content` has no `creator` property, reject. 5. Otherwise, allow. 2. Considering the event's `auth_events`: 1. If there are duplicate entries for a given `type` and `state_key` pair, @@ -57,11 +57,11 @@ The rules are as follows: 5. If the `join_rule` is `public`, allow. 6. Otherwise, reject. 3. If `membership` is `invite`: - 1. If `content` has `third_party_invite` key: + 1. If `content` has a `third_party_invite` property: 1. If *target user* is banned, reject. 2. If `content.third_party_invite` does not have a `signed` - key, reject. - 3. If `signed` does not have `mxid` and `token` keys, + property, reject. + 3. If `signed` does not have `mxid` and `token` properties, reject. 4. If `mxid` does not match `state_key`, reject. 5. If there is no `m.room.third_party_invite` event in the @@ -72,8 +72,8 @@ The rules are as follows: 7. If any signature in `signed` matches any public key in the `m.room.third_party_invite` event, allow. The public keys are in `content` of `m.room.third_party_invite` as: - 1. A single public key in the `public_key` field. - 2. A list of public keys in the `public_keys` field. + 1. A single public key in the `public_key` property. + 2. A list of public keys in the `public_keys` property. 8. Otherwise, reject. 2. If the `sender`'s current membership state is not `join`, reject. diff --git a/content/rooms/fragments/v3-auth-rules.md b/content/rooms/fragments/v3-auth-rules.md index 7a8bc23b4..e3b97587f 100644 --- a/content/rooms/fragments/v3-auth-rules.md +++ b/content/rooms/fragments/v3-auth-rules.md @@ -6,7 +6,7 @@ toc_hide: true signature from the domain of the `event_id` in order to be considered valid. This room version does not include an `event_id` over federation in the same respect, so does not need a signature from that server. -The event must still be signed by the server denoted by the `sender`, +The event must still be signed by the server denoted by the `sender` property, however. The types of state events that affect authorization are: @@ -31,7 +31,7 @@ The complete list of rules, as of room version 3, is as follows: `sender`, reject. 3. If `content.room_version` is present and is not a recognised version, reject. - 4. If `content` has no `creator` field, reject. + 4. If `content` has no `creator` property, reject. 5. Otherwise, allow. 2. Considering the event's `auth_events`: 1. If there are duplicate entries for a given `type` and `state_key` pair, @@ -64,11 +64,11 @@ The complete list of rules, as of room version 3, is as follows: 5. If the `join_rule` is `public`, allow. 6. Otherwise, reject. 3. If `membership` is `invite`: - 1. If `content` has `third_party_invite` key: + 1. If `content` has a `third_party_invite` property: 1. If *target user* is banned, reject. 2. If `content.third_party_invite` does not have a `signed` - key, reject. - 3. If `signed` does not have `mxid` and `token` keys, + property, reject. + 3. If `signed` does not have `mxid` and `token` properties, reject. 4. If `mxid` does not match `state_key`, reject. 5. If there is no `m.room.third_party_invite` event in the @@ -79,8 +79,8 @@ The complete list of rules, as of room version 3, is as follows: 7. If any signature in `signed` matches any public key in the `m.room.third_party_invite` event, allow. The public keys are in `content` of `m.room.third_party_invite` as: - 1. A single public key in the `public_key` field. - 2. A list of public keys in the `public_keys` field. + 1. A single public key in the `public_key` property. + 2. A list of public keys in the `public_keys` property. 8. Otherwise, reject. 2. If the `sender`'s current membership state is not `join`, reject. diff --git a/content/rooms/fragments/v8-auth-rules.md b/content/rooms/fragments/v8-auth-rules.md index 90ba02b0d..367efeea3 100644 --- a/content/rooms/fragments/v8-auth-rules.md +++ b/content/rooms/fragments/v8-auth-rules.md @@ -2,7 +2,7 @@ toc_hide: true --- -Events must be signed by the server denoted by the `sender` key. +Events must be signed by the server denoted by the `sender` property. `m.room.redaction` events are not explicitly part of the auth rules. They are still subject to the minimum power level rules, but should always @@ -32,7 +32,7 @@ The rules are as follows: `sender`, reject. 3. If `content.room_version` is present and is not a recognised version, reject. - 4. If `content` has no `creator` field, reject. + 4. If `content` has no `creator` property, reject. 5. Otherwise, allow. 2. Considering the event's `auth_events`: 1. If there are duplicate entries for a given `type` and `state_key` pair, @@ -51,8 +51,7 @@ The rules are as follows: 4. If type is `m.room.member`: 1. If there is no `state_key` property, or no `membership` property in `content`, reject. - 2. If `content` has a `join_authorised_via_users_server` - key: + 2. If `content` has a `join_authorised_via_users_server` property: 1. If the event is not validly signed by the homeserver of the user ID denoted by the key, reject. 3. If `membership` is `join`: @@ -71,11 +70,11 @@ The rules are as follows: 6. If the `join_rule` is `public`, allow. 7. Otherwise, reject. 4. If `membership` is `invite`: - 1. If `content` has `third_party_invite` key: + 1. If `content` has a `third_party_invite` property: 1. If *target user* is banned, reject. 2. If `content.third_party_invite` does not have a `signed` - key, reject. - 3. If `signed` does not have `mxid` and `token` keys, + property, reject. + 3. If `signed` does not have `mxid` and `token` properties, reject. 4. If `mxid` does not match `state_key`, reject. 5. If there is no `m.room.third_party_invite` event in the @@ -86,8 +85,8 @@ The rules are as follows: 7. If any signature in `signed` matches any public key in the `m.room.third_party_invite` event, allow. The public keys are in `content` of `m.room.third_party_invite` as: - 1. A single public key in the `public_key` field. - 2. A list of public keys in the `public_keys` field. + 1. A single public key in the `public_key` property. + 2. A list of public keys in the `public_keys` property. 8. Otherwise, reject. 2. If the `sender`'s current membership state is not `join`, reject. diff --git a/content/rooms/v10.md b/content/rooms/v10.md index c34029ec4..24e45723c 100644 --- a/content/rooms/v10.md +++ b/content/rooms/v10.md @@ -74,7 +74,7 @@ correctly structured are rejected under the authorization rules below. ### Authorization rules -Events must be signed by the server denoted by the `sender` key. +Events must be signed by the server denoted by the `sender` property. `m.room.redaction` events are not explicitly part of the auth rules. They are still subject to the minimum power level rules, but should always @@ -104,7 +104,7 @@ The rules are as follows: `sender`, reject. 3. If `content.room_version` is present and is not a recognised version, reject. - 4. If `content` has no `creator` field, reject. + 4. If `content` has no `creator` property, reject. 5. Otherwise, allow. 2. Considering the event's `auth_events`: 1. If there are duplicate entries for a given `type` and `state_key` pair, @@ -144,11 +144,11 @@ The rules are as follows: 6. If the `join_rule` is `public`, allow. 7. Otherwise, reject. 4. If `membership` is `invite`: - 1. If `content` has `third_party_invite` key: + 1. If `content` has a `third_party_invite` property: 1. If *target user* is banned, reject. 2. If `content.third_party_invite` does not have a `signed` - key, reject. - 3. If `signed` does not have `mxid` and `token` keys, + property, reject. + 3. If `signed` does not have `mxid` and `token` properties, reject. 4. If `mxid` does not match `state_key`, reject. 5. If there is no `m.room.third_party_invite` event in the @@ -159,8 +159,8 @@ The rules are as follows: 7. If any signature in `signed` matches any public key in the `m.room.third_party_invite` event, allow. The public keys are in `content` of `m.room.third_party_invite` as: - 1. A single public key in the `public_key` field. - 2. A list of public keys in the `public_keys` field. + 1. A single public key in the `public_key` property. + 2. A list of public keys in the `public_keys` property. 8. Otherwise, reject. 2. If the `sender`'s current membership state is not `join`, reject. diff --git a/content/rooms/v6.md b/content/rooms/v6.md index eed37beae..a76ee98b0 100644 --- a/content/rooms/v6.md +++ b/content/rooms/v6.md @@ -55,7 +55,7 @@ of type `m.room.power_levels` now include the content key `notifications`. This new rule takes the place of rule 10.4, which checked the `events` and `users` keys. -Events must be signed by the server denoted by the `sender` key. +Events must be signed by the server denoted by the `sender` property. The types of state events that affect authorization are: @@ -79,7 +79,7 @@ The rules are as follows: `sender`, reject. 3. If `content.room_version` is present and is not a recognised version, reject. - 4. If `content` has no `creator` field, reject. + 4. If `content` has no `creator` property, reject. 5. Otherwise, allow. 2. Reject if event has `auth_events` that: 1. have duplicate entries for a given `type` and `state_key` pair @@ -102,11 +102,11 @@ The rules are as follows: 5. If the `join_rule` is `public`, allow. 6. Otherwise, reject. 3. If `membership` is `invite`: - 1. If `content` has `third_party_invite` key: + 1. If `content` has a `third_party_invite` property: 1. If *target user* is banned, reject. 2. If `content.third_party_invite` does not have a `signed` - key, reject. - 3. If `signed` does not have `mxid` and `token` keys, + property, reject. + 3. If `signed` does not have `mxid` and `token` properties, reject. 4. If `mxid` does not match `state_key`, reject. 5. If there is no `m.room.third_party_invite` event in the @@ -117,8 +117,8 @@ The rules are as follows: 7. If any signature in `signed` matches any public key in the `m.room.third_party_invite` event, allow. The public keys are in `content` of `m.room.third_party_invite` as: - 1. A single public key in the `public_key` field. - 2. A list of public keys in the `public_keys` field. + 1. A single public key in the `public_key` property. + 2. A list of public keys in the `public_keys` property. 8. Otherwise, reject. 2. If the `sender`'s current membership state is not `join`, reject. diff --git a/content/rooms/v7.md b/content/rooms/v7.md index 87dea0e20..e7ea1b730 100644 --- a/content/rooms/v7.md +++ b/content/rooms/v7.md @@ -35,7 +35,7 @@ as do the versions v6 is based upon. {{% added-in this=true %}} For checks performed upon `m.room.member` events, a new point for `membership=knock` is added. -Events must be signed by the server denoted by the `sender` key. +Events must be signed by the server denoted by the `sender` property. `m.room.redaction` events are not explicitly part of the auth rules. They are still subject to the minimum power level rules, but should always @@ -65,7 +65,7 @@ The rules are as follows: `sender`, reject. 3. If `content.room_version` is present and is not a recognised version, reject. - 4. If `content` has no `creator` field, reject. + 4. If `content` has no `creator` property, reject. 5. Otherwise, allow. 2. Reject if event has `auth_events` that: 1. have duplicate entries for a given `type` and `state_key` pair @@ -88,11 +88,11 @@ The rules are as follows: 5. If the `join_rule` is `public`, allow. 6. Otherwise, reject. 3. If `membership` is `invite`: - 1. If `content` has `third_party_invite` key: + 1. If `content` has `third_party_invite` property: 1. If *target user* is banned, reject. 2. If `content.third_party_invite` does not have a `signed` - key, reject. - 3. If `signed` does not have `mxid` and `token` keys, + property, reject. + 3. If `signed` does not have `mxid` and `token` properties, reject. 4. If `mxid` does not match `state_key`, reject. 5. If there is no `m.room.third_party_invite` event in the @@ -103,8 +103,8 @@ The rules are as follows: 7. If any signature in `signed` matches any public key in the `m.room.third_party_invite` event, allow. The public keys are in `content` of `m.room.third_party_invite` as: - 1. A single public key in the `public_key` field. - 2. A list of public keys in the `public_keys` field. + 1. A single public key in the `public_key` property. + 2. A list of public keys in the `public_keys` property. 8. Otherwise, reject. 2. If the `sender`'s current membership state is not `join`, reject. From c50b3e808ae21ea2f336b7f5357810b0b64c0339 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Tue, 4 Oct 2022 18:03:15 +0100 Subject: [PATCH 4/7] Inline "[New in this version]" in auth rules This makes it much easier to see exactly what is new, and what is existing. --- content/rooms/fragments/v3-auth-rules.md | 2 +- content/rooms/v3.md | 4 ++-- content/rooms/v7.md | 2 +- content/rooms/v8.md | 4 ++-- content/rooms/v9.md | 2 +- 5 files changed, 7 insertions(+), 7 deletions(-) diff --git a/content/rooms/fragments/v3-auth-rules.md b/content/rooms/fragments/v3-auth-rules.md index e3b97587f..47aceea3d 100644 --- a/content/rooms/fragments/v3-auth-rules.md +++ b/content/rooms/fragments/v3-auth-rules.md @@ -2,7 +2,7 @@ toc_hide: true --- -{{% added-in this=true %}} In room versions 1 and 2, events need a +{{< added-in this=true >}} In room versions 1 and 2, events need a signature from the domain of the `event_id` in order to be considered valid. This room version does not include an `event_id` over federation in the same respect, so does not need a signature from that server. diff --git a/content/rooms/v3.md b/content/rooms/v3.md index 8dd261e8c..dd2fd144a 100644 --- a/content/rooms/v3.md +++ b/content/rooms/v3.md @@ -89,7 +89,7 @@ The complete structure of a event in a v3 room is shown below. ### Authorization rules -{{% added-in this=true %}} `m.room.redaction` events are no longer +{{< added-in this=true >}} `m.room.redaction` events are no longer explicitly part of the auth rules. They are still subject to the minimum power level rules, but should always fall into "11. Otherwise, allow". Instead of being authorized at the time of receipt, they are @@ -97,7 +97,7 @@ authorized at a later stage: see the [Handling Redactions](#handling-redactions) section below for more information. -{{% rver-fragment name="v3-auth-rules" withVersioning=true %}} +{{< rver-fragment name="v3-auth-rules" withVersioning=true >}} ## Unchanged from v2 diff --git a/content/rooms/v7.md b/content/rooms/v7.md index e7ea1b730..cdccdadd6 100644 --- a/content/rooms/v7.md +++ b/content/rooms/v7.md @@ -32,7 +32,7 @@ as do the versions v6 is based upon. ### Authorization rules -{{% added-in this=true %}} For checks performed upon `m.room.member` events, a +{{< added-in this=true >}} For checks performed upon `m.room.member` events, a new point for `membership=knock` is added. Events must be signed by the server denoted by the `sender` property. diff --git a/content/rooms/v8.md b/content/rooms/v8.md index 2a8cf1255..ab4cd9709 100644 --- a/content/rooms/v8.md +++ b/content/rooms/v8.md @@ -83,11 +83,11 @@ room without invite. Otherwise, the room version inherits all properties of ### Authorization rules -{{% added-in this=true %}} For checks performed upon `m.room.member` events, new +{{< added-in this=true >}} For checks performed upon `m.room.member` events, new points for handling `content.join_authorised_via_users_server` are added (Rule 4.2 and 4.3.5). -{{% rver-fragment name="v8-auth-rules" %}} +{{< rver-fragment name="v8-auth-rules" withVersioning=true >}} ### Redactions diff --git a/content/rooms/v9.md b/content/rooms/v9.md index d4da72de8..f67354155 100644 --- a/content/rooms/v9.md +++ b/content/rooms/v9.md @@ -62,7 +62,7 @@ completeness. ### Authorization rules -{{% rver-fragment name="v8-auth-rules" %}} +{{< rver-fragment name="v8-auth-rules" >}} ### State resolution From 740770a308e57d2032655bf33f592bd3265fb2fc Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Tue, 4 Oct 2022 18:04:46 +0100 Subject: [PATCH 5/7] Add some "[Changed in this version]" for individual auth rules For rooms v7 and v8, we can decorate individual auth rules to show what has changed. --- content/rooms/fragments/v8-auth-rules.md | 6 ++++-- content/rooms/v7.md | 9 ++++++--- layouts/shortcodes/rver-fragment.html | 1 + 3 files changed, 11 insertions(+), 5 deletions(-) diff --git a/content/rooms/fragments/v8-auth-rules.md b/content/rooms/fragments/v8-auth-rules.md index 367efeea3..86c3c697c 100644 --- a/content/rooms/fragments/v8-auth-rules.md +++ b/content/rooms/fragments/v8-auth-rules.md @@ -51,7 +51,8 @@ The rules are as follows: 4. If type is `m.room.member`: 1. If there is no `state_key` property, or no `membership` property in `content`, reject. - 2. If `content` has a `join_authorised_via_users_server` property: + 2. {{< added-in this=true >}} + If `content` has a `join_authorised_via_users_server` property: 1. If the event is not validly signed by the homeserver of the user ID denoted by the key, reject. 3. If `membership` is `join`: @@ -61,7 +62,8 @@ The rules are as follows: 3. If the `sender` is banned, reject. 4. If the `join_rule` is `invite` or `knock` then allow if membership state is `invite` or `join`. - 5. If the `join_rule` is `restricted`: + 5. {{< added-in this=true >}} + If the `join_rule` is `restricted`: 1. If membership state is `join` or `invite`, allow. 2. If the `join_authorised_via_users_server` key in `content` is not a user with sufficient permission to invite other diff --git a/content/rooms/v7.md b/content/rooms/v7.md index cdccdadd6..7bec77553 100644 --- a/content/rooms/v7.md +++ b/content/rooms/v7.md @@ -83,7 +83,8 @@ The rules are as follows: `state_key` is the creator, allow. 2. If the `sender` does not match `state_key`, reject. 3. If the `sender` is banned, reject. - 4. If the `join_rule` is `invite` or `knock` then allow if + 4. {{< changed-in this=true >}} + If the `join_rule` is `invite` or `knock` then allow if membership state is `invite` or `join`. 5. If the `join_rule` is `public`, allow. 6. Otherwise, reject. @@ -114,7 +115,8 @@ The rules are as follows: the *invite level*, allow. 5. Otherwise, reject. 4. If `membership` is `leave`: - 1. If the `sender` matches `state_key`, allow if and only if + 1. {{< changed-in this=true >}} + If the `sender` matches `state_key`, allow if and only if that user's current membership state is `invite`, `join`, or `knock`. 2. If the `sender`'s current membership state is not `join`, @@ -133,7 +135,8 @@ The rules are as follows: the *ban level*, and the *target user*'s power level is less than the `sender`'s power level, allow. 3. Otherwise, reject. - 6. If `membership` is `knock`: + 6. {{< added-in this=true >}} + If `membership` is `knock`: 1. If the `join_rule` is anything other than `knock`, reject. 2. If `sender` does not match `state_key`, reject. 3. If the `sender`'s current membership is not `ban` or `join`, allow. diff --git a/layouts/shortcodes/rver-fragment.html b/layouts/shortcodes/rver-fragment.html index 14a8a0271..62434586c 100644 --- a/layouts/shortcodes/rver-fragment.html +++ b/layouts/shortcodes/rver-fragment.html @@ -21,5 +21,6 @@ {{ $content := $page.Content }} {{ if not $withVersioning }} {{ $content = (replace $content "[New in this version]" "") }} + {{ $content = (replace $content "[Changed in this version]" "") }} {{ end }} {{ $content | safeHTML }} From c315f76299bce6011752664ea0666931ae153dda Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Tue, 4 Oct 2022 18:06:38 +0100 Subject: [PATCH 6/7] changelog --- changelogs/room_versions/newsfragments/1270.clarification | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 changelogs/room_versions/newsfragments/1270.clarification diff --git a/changelogs/room_versions/newsfragments/1270.clarification b/changelogs/room_versions/newsfragments/1270.clarification new file mode 100644 index 000000000..459aadc73 --- /dev/null +++ b/changelogs/room_versions/newsfragments/1270.clarification @@ -0,0 +1,2 @@ +Various clarifications to the text on event authorisation rules. + From a8aa245ac69cad0945e948a20b985aed28541953 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> Date: Wed, 5 Oct 2022 17:29:07 +0100 Subject: [PATCH 7/7] Update changelogs/room_versions/newsfragments/1270.clarification Co-authored-by: Erik Johnston --- changelogs/room_versions/newsfragments/1270.clarification | 1 - 1 file changed, 1 deletion(-) diff --git a/changelogs/room_versions/newsfragments/1270.clarification b/changelogs/room_versions/newsfragments/1270.clarification index 459aadc73..638ef04be 100644 --- a/changelogs/room_versions/newsfragments/1270.clarification +++ b/changelogs/room_versions/newsfragments/1270.clarification @@ -1,2 +1 @@ Various clarifications to the text on event authorisation rules. -