From 67c651bc9a2e3fcb9414cf3a3a52c4d271e9fbdc Mon Sep 17 00:00:00 2001 From: Matthias Ahouansou Date: Tue, 28 May 2024 17:28:55 +0100 Subject: [PATCH] Further expand and clarify redaction authorization rules Signed-off-by: Matthias Ahouansou --- content/rooms/fragments/v8-auth-rules.md | 16 ++++++++++++---- content/rooms/v10.md | 16 ++++++++++++---- content/rooms/v11.md | 16 ++++++++++++---- content/rooms/v3.md | 15 +++++++++++---- content/rooms/v6.md | 16 ++++++++++++---- content/rooms/v7.md | 16 ++++++++++++---- 6 files changed, 71 insertions(+), 24 deletions(-) diff --git a/content/rooms/fragments/v8-auth-rules.md b/content/rooms/fragments/v8-auth-rules.md index 37dc729d..7ca3d56a 100644 --- a/content/rooms/fragments/v8-auth-rules.md +++ b/content/rooms/fragments/v8-auth-rules.md @@ -1,10 +1,6 @@ Events must be signed by the server denoted by the `sender` property. -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: - [`m.room.create`](/client-server-api#mroomcreate) @@ -19,6 +15,18 @@ For example, mentions of the `sender`'s power level can also refer to the default power level for users in the room. {{% /boxes/note %}} +{{% boxes/note %}} +`m.room.redaction` events are subject to auth rules in the same way as any other event. +In practice, that means they will normally be allowed by the auth rules, unless the +`m.room.power_levels` event sets a power level requirement for `m.room.redaction` +events via the `events` or `events_default` properties. In particular, the /redact +level/ is **not** considered by the auth rules. + +The ability to send a redaction event does not mean that the redaction itself should +be performed. Receiving servers must perform additional checks, as described in +the [Handling Redactions](#handling-redactions) section below. +{{% /boxes/note %}} + The rules are as follows: 1. If type is `m.room.create`: diff --git a/content/rooms/v10.md b/content/rooms/v10.md index 5f70421d..0fa203ad 100644 --- a/content/rooms/v10.md +++ b/content/rooms/v10.md @@ -76,10 +76,6 @@ correctly structured are rejected under the authorization rules below. Events must be signed by the server denoted by the `sender` property. -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: - [`m.room.create`](/client-server-api#mroomcreate) @@ -94,6 +90,18 @@ For example, mentions of the `sender`'s power level can also refer to the default power level for users in the room. {{% /boxes/note %}} +{{% boxes/note %}} +`m.room.redaction` events are subject to auth rules in the same way as any other event. +In practice, that means they will normally be allowed by the auth rules, unless the +`m.room.power_levels` event sets a power level requirement for `m.room.redaction` +events via the `events` or `events_default` properties. In particular, the /redact +level/ is **not** considered by the auth rules. + +The ability to send a redaction event does not mean that the redaction itself should +be performed. Receiving servers must perform additional checks, as described in +the [Redactions](#redactions) section below. +{{% /boxes/note %}} + The rules are as follows: 1. If type is `m.room.create`: diff --git a/content/rooms/v11.md b/content/rooms/v11.md index 4d0bf7fe..a4905da2 100644 --- a/content/rooms/v11.md +++ b/content/rooms/v11.md @@ -83,10 +83,6 @@ such events over the Client-Server API. Events must be signed by the server denoted by the `sender` property. -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: - [`m.room.create`](/client-server-api#mroomcreate) @@ -101,6 +97,18 @@ For example, mentions of the `sender`'s power level can also refer to the default power level for users in the room. {{% /boxes/note %}} +{{% boxes/note %}} +`m.room.redaction` events are subject to auth rules in the same way as any other event. +In practice, that means they will normally be allowed by the auth rules, unless the +`m.room.power_levels` event sets a power level requirement for `m.room.redaction` +events via the `events` or `events_default` properties. In particular, the /redact +level/ is **not** considered by the auth rules. + +The ability to send a redaction event does not mean that the redaction itself should +be performed. Receiving servers must perform additional checks, as described in +the [Redactions](#redactions) section below. +{{% /boxes/note %}} + The rules are as follows: 1. {{< changed-in this="true" >}} diff --git a/content/rooms/v3.md b/content/rooms/v3.md index b8134e0d..90b84677 100644 --- a/content/rooms/v3.md +++ b/content/rooms/v3.md @@ -89,10 +89,17 @@ The complete structure of a event in a v3 room is shown below. ### Authorization rules -{{< 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. +{{% boxes/note %}} +{{< added-in this=true >}} `m.room.redaction` events are subject to auth rules in +the same way as any other event. In practice, that means they will normally be allowed +by the auth rules, unless the `m.room.power_levels` event sets a power level requirement +for `m.room.redaction`events via the `events` or `events_default` properties. In +particular, the /redact level/ is **not** considered by the auth rules. + +The ability to send a redaction event does not mean that the redaction itself should +be performed. Receiving servers must perform additional checks, as described in +the [Handling Redactions](#handling-redactions) section below. +{{% /boxes/note %}} {{< rver-fragment name="v3-auth-rules" withVersioning=true >}} diff --git a/content/rooms/v6.md b/content/rooms/v6.md index c430abfd..a27b06f6 100644 --- a/content/rooms/v6.md +++ b/content/rooms/v6.md @@ -40,10 +40,6 @@ in [room version 5](/rooms/v5). ### Authorization rules -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 authorization checks relating to state events. @@ -69,6 +65,18 @@ For example, mentions of the `sender`'s power level can also refer to the default power level for users in the room. {{% /boxes/note %}} +{{% boxes/note %}} +`m.room.redaction` events are subject to auth rules in the same way as any other event. +In practice, that means they will normally be allowed by the auth rules, unless the +`m.room.power_levels` event sets a power level requirement for `m.room.redaction` +events via the `events` or `events_default` properties. In particular, the /redact +level/ is **not** considered by the auth rules. + +The ability to send a redaction event does not mean that the redaction itself should +be performed. Receiving servers must perform additional checks, as described in +the [Handling Redactions](#handling-redactions) section below. +{{% /boxes/note %}} + The rules are as follows: 1. If type is `m.room.create`: diff --git a/content/rooms/v7.md b/content/rooms/v7.md index defe90d4..07525e27 100644 --- a/content/rooms/v7.md +++ b/content/rooms/v7.md @@ -37,10 +37,6 @@ new point for `membership=knock` is added. Events must be signed by the server denoted by the `sender` property. -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: - [`m.room.create`](/client-server-api#mroomcreate) @@ -55,6 +51,18 @@ For example, mentions of the `sender`'s power level can also refer to the default power level for users in the room. {{% /boxes/note %}} +{{% boxes/note %}} +`m.room.redaction` events are subject to auth rules in the same way as any other event. +In practice, that means they will normally be allowed by the auth rules, unless the +`m.room.power_levels` event sets a power level requirement for `m.room.redaction` +events via the `events` or `events_default` properties. In particular, the /redact +level/ is **not** considered by the auth rules. + +The ability to send a redaction event does not mean that the redaction itself should +be performed. Receiving servers must perform additional checks, as described in +the [Redactions](#redactions) section below. +{{% /boxes/note %}} + The rules are as follows: 1. If type is `m.room.create`: