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] 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 b0907829..289e40e5 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 7a8bc23b..e3b97587 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 90ba02b0..367efeea 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 c34029ec..24e45723 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 eed37bea..a76ee98b 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 87dea0e2..e7ea1b73 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.