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. Events must be signed by the server denoted by the `sender` property.
`m.room.redaction` events are not explicitly part of the auth rules. While they are still subject to them, there are no auth rules specifically for
They are still subject to the minimum power level rules, but should always `m.room.redaction` events. The actual redaction of content is authorized at a
fall into "10. Otherwise, allow". Instead of being authorized at the time later stage: see the [Redactions](#redactions) section below for more information.
of receipt, they are authorized at a later stage: see the
[Redactions](#redactions) section below for more information.
The types of state events that affect authorization are: 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. Events must be signed by the server denoted by the `sender` property.
`m.room.redaction` events are not explicitly part of the auth rules. While they are still subject to them, there are no auth rules specifically for
They are still subject to the minimum power level rules, but should always `m.room.redaction` events. The actual redaction of content is authorized at a
fall into "10. Otherwise, allow". Instead of being authorized at the time later stage: see the [Redactions](#redactions) section below for more information.
of receipt, they are authorized at a later stage: see the
[Redactions](#redactions) section below for more information.
The types of state events that affect authorization are: 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. Events must be signed by the server denoted by the `sender` property.
`m.room.redaction` events are not explicitly part of the auth rules. While they are still subject to them, there are no auth rules specifically for
They are still subject to the minimum power level rules, but should always `m.room.redaction` events. The actual redaction of content is authorized at a
fall into "10. Otherwise, allow". Instead of being authorized at the time later stage: see the [Redactions](#redactions) section below for more information.
of receipt, they are authorized at a later stage: see the
[Redactions](#redactions) section below for more information.
The types of state events that affect authorization are: 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 ### Authorization rules
{{< added-in this=true >}} `m.room.redaction` events are no longer {{< added-in this=true >}} While they are still subject to them,
explicitly part of the auth rules. They are still subject to the there are no auth rules specifically for `m.room.redaction` events anymore.
minimum power level rules, but should always fall into "11. Otherwise, The actual redaction of content is authorized at alater stage: see the
allow". Instead of being authorized at the time of receipt, they are [Redactions](#redactions) section below for more information.
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 --> <!-- 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 >}}

8
content/rooms/v6.md
View file

@ -40,11 +40,9 @@ in [room version 5](/rooms/v5).
### Authorization rules ### Authorization rules
`m.room.redaction` events are not explicitly part of the auth rules. While they are still subject to them, there are no auth rules specifically for
They are still subject to the minimum power level rules, but should always `m.room.redaction` events. The actual redaction of content is authorized at a
fall into "10. Otherwise, allow". Instead of being authorized at the time later stage: see the [Redactions](#redactions) section below for more information.
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 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. Events must be signed by the server denoted by the `sender` property.
`m.room.redaction` events are not explicitly part of the auth rules. While they are still subject to them, there are no auth rules specifically for
They are still subject to the minimum power level rules, but should always `m.room.redaction` events. The actual redaction of content is authorized at a
fall into "10. Otherwise, allow". Instead of being authorized at the time later stage: see the [Redactions](#redactions) section below for more information.
of receipt, they are authorized at a later stage: see the
[Redactions](#redactions) section below for more information.
The types of state events that affect authorization are: The types of state events that affect authorization are: