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

Clarify auth rules for m.room.power_levels events (#1269)

Browse source
This commit is contained in:
Richard van der Hoff 2022-10-12 13:36:02 +01:00 • committed by GitHub
parent 3808a679c1
commit 11cef5417a
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
7 changed files with 108 additions and 79 deletions
Download patch file Download diff file Expand all files Collapse all files

39
content/rooms/v6.md
View file

@ -46,14 +46,14 @@ fall into "10. Otherwise, allow". Instead of being authorized at the time
of receipt, they are authorized at a later stage: see the
[Handling Redactions](#handling-redactions) section below for more information.
{{% added-in this=true %}} Rule 4, which related specifically to events
{{< added-in this=true >}} Rule 4, which related specifically to events
of type `m.room.aliases`, is removed. `m.room.aliases` events must still pass
authorization checks relating to state events.
{{% added-in this=true %}} Additionally, the authorization rules for events
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.
{{< added-in this=true >}} Additionally, the authorization rules for events of
type `m.room.power_levels` now include a `notifications` property under
`content`. This updates rules 10.4 and 10.5 (now 9.4 and 9.5), which checked
the `events` property.
Events must be signed by the server denoted by the `sender` property.
@ -156,29 +156,36 @@ The rules are as follows:
8. If the event has a `state_key` that starts with an `@` and does not
match the `sender`, reject.
9. If type is `m.room.power_levels`:
1. If `users` key in `content` is not a dictionary with keys that
1. If the `users` property in `content` is not an object with keys that
are valid user IDs with values that are integers (or a string
that is an integer), reject.
2. If there is no previous `m.room.power_levels` event in the room,
allow.
3. For the keys `users_default`, `events_default`, `state_default`,
3. For the properties `users_default`, `events_default`, `state_default`,
`ban`, `redact`, `kick`, `invite` check if they were added,
changed or removed. For each found alteration:
1. If the current value is higher than the `sender`'s current
power level, reject.
2. If the new value is higher than the `sender`'s current power
level, reject.
4. For each entry being added, changed or removed in both the
`events`, `users`, and `notifications` keys:
1. If the current value is higher than the `sender`'s current
4. {{< changed-in this="true" >}}
For each entry being changed in, or removed from, the `events` or
`notifications` properties:
1. If the current value is greater than the `sender`'s current
power level, reject.
2. If the new value is higher than the `sender`'s current power
5. {{< changed-in this="true" >}}
For each entry being added to, or changed in, the `events` or
`notifications` properties:
1. If the new value is greater than the `sender`'s current power
level, reject.
5. For each entry being changed under the `users` key, other than
the `sender`'s own entry:
1. If the current value is equal to the `sender`'s current
power level, reject.
6. Otherwise, allow.
6. For each entry being changed in, or removed from, the `users` property,
other than the `sender`'s own entry:
1. If the current value is greater than or equal to the `sender`'s
current power level, reject.
7. For each entry being added to, or changed in, the `users` property:
1. If the new value is greater than the `sender`'s current power
level, reject.
8. Otherwise, allow.
10. Otherwise, allow.
{{% boxes/note %}}