Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-03-23 11:34:09 +01:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

Clarify that redaction events are subject to auth rules

Browse source
This commit is contained in:
Matthias Ahouansou 2024-05-18 15:08:56 +01:00
parent dac867dd6a
commit 084fbdc4a6
No known key found for this signature in database
6 changed files with 19 additions and 31 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

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

@ -1,11 +1,9 @@
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
fall into "10. Otherwise, allow". Instead of being authorized at the time
of receipt, they are authorized at a later stage: see the
[Redactions](#redactions) section below for more information.
While they are still subject to them, there are no auth rules specifically for
`m.room.redaction` events. The actual redaction of content is authorized at a
later stage: see the [Redactions](#redactions) section below for more information.
The types of state events that affect authorization are:

8
content/rooms/v10.md
View file

@ -76,11 +76,9 @@ correctly structured are rejected under the authorization rules below.
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
fall into "10. Otherwise, allow". Instead of being authorized at the time
of receipt, they are authorized at a later stage: see the
[Redactions](#redactions) section below for more information.
While they are still subject to them, there are no auth rules specifically for
`m.room.redaction` events. The actual redaction of content is authorized at a
later stage: see the [Redactions](#redactions) section below for more information.
The types of state events that affect authorization are:

8
content/rooms/v11.md
View file

@ -83,11 +83,9 @@ such events over the Client-Server API.
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
fall into "10. Otherwise, allow". Instead of being authorized at the time
of receipt, they are authorized at a later stage: see the
[Redactions](#redactions) section below for more information.
While they are still subject to them, there are no auth rules specifically for
`m.room.redaction` events. The actual redaction of content is authorized at a
later stage: see the [Redactions](#redactions) section below for more information.
The types of state events that affect authorization are:

10
content/rooms/v3.md
View file

@ -89,12 +89,10 @@ 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
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
authorized at a later stage: see the [Handling Redactions](#handling-redactions)
section below for more information.
{{< added-in this=true >}} While they are still subject to them,
there are no auth rules specifically for `m.room.redaction` events anymore.
The actual redaction of content is authorized at alater stage: see the
[Redactions](#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 >}}

8
content/rooms/v6.md
View file

@ -40,11 +40,9 @@ in [room version 5](/rooms/v5).
### Authorization rules
`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
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.
While they are still subject to them, there are no auth rules specifically for
`m.room.redaction` events. The actual redaction of content is authorized at a
later stage: see the [Redactions](#redactions) section below for more information.
{{< 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

8
content/rooms/v7.md
View file

@ -37,11 +37,9 @@ new point for `membership=knock` is added.
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
fall into "10. Otherwise, allow". Instead of being authorized at the time
of receipt, they are authorized at a later stage: see the
[Redactions](#redactions) section below for more information.
While they are still subject to them, there are no auth rules specifically for
`m.room.redaction` events. The actual redaction of content is authorized at a
later stage: see the [Redactions](#redactions) section below for more information.
The types of state events that affect authorization are: