wholetrans/docs-matrix-spec
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Various clarifications to auth rules text (#1270)

Browse source
This commit is contained in:
Richard van der Hoff 2022-10-05 17:54:34 +01:00 • committed by GitHub
parent 43a48314ac
commit c4505665e0
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
11 changed files with 78 additions and 66 deletions
Download patch file Download diff file Expand all files Collapse all files

1
changelogs/room_versions/newsfragments/1270.clarification Normal file
View file

@ -0,0 +1 @@
Various clarifications to the text on event authorisation rules.

17
content/rooms/fragments/v1-auth-rules.md
View file

@ -19,12 +19,12 @@ 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
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,
@ -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.
@ -56,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
@ -71,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.

21
content/rooms/fragments/v3-auth-rules.md
View file

@ -2,11 +2,11 @@
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.
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:
@ -26,12 +26,12 @@ 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
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,
@ -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.
@ -63,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
@ -78,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.

26
content/rooms/fragments/v8-auth-rules.md
View file

@ -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
@ -27,12 +27,12 @@ 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
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,
@ -49,9 +49,10 @@ 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.
2. If `content` has a `join_authorised_via_users_server`
key:
1. If there is no `state_key` property, or no `membership` property in
`content`, reject.
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
@ -70,11 +72,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
@ -85,8 +87,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.

19
content/rooms/v10.md
View file

@ -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
@ -99,12 +99,12 @@ 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
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,
@ -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
@ -143,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
@ -158,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.

4
content/rooms/v3.md
View file

@ -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.
<!-- set withVersioning=true so we get all the "new in this version" stuff -->
{{% rver-fragment name="v3-auth-rules" withVersioning=true %}}
{{< rver-fragment name="v3-auth-rules" withVersioning=true >}}
## Unchanged from v2

19
content/rooms/v6.md
View file

@ -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:
@ -74,12 +74,12 @@ 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
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
@ -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.
@ -101,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
@ -116,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.

30
content/rooms/v7.md
View file

@ -32,10 +32,10 @@ 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` 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
@ -60,12 +60,12 @@ 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
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
@ -76,22 +76,24 @@ 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.
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.
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
@ -102,8 +104,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.
@ -113,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`,
@ -132,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.

4
content/rooms/v8.md
View file

@ -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

2
content/rooms/v9.md
View file

@ -62,7 +62,7 @@ completeness.
### Authorization rules
{{% rver-fragment name="v8-auth-rules" %}}
{{< rver-fragment name="v8-auth-rules" >}}
### State resolution

1
layouts/shortcodes/rver-fragment.html
View file

@ -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 }}