mirror of
https://github.com/matrix-org/matrix-spec
synced 2026-03-23 19:44:09 +01:00
Further expand and clarify redaction authorization rules
Signed-off-by: Matthias Ahouansou <matthias@ahouansou.cz>
This commit is contained in:
parent
2dcf95f1a5
commit
67c651bc9a
|
|
@ -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`:
|
||||
|
|
|
|||
|
|
@ -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`:
|
||||
|
|
|
|||
|
|
@ -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" >}}
|
||||
|
|
|
|||
|
|
@ -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 %}}
|
||||
|
||||
<!-- set withVersioning=true so we get all the "new in this version" stuff -->
|
||||
{{< rver-fragment name="v3-auth-rules" withVersioning=true >}}
|
||||
|
|
|
|||
|
|
@ -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`:
|
||||
|
|
|
|||
|
|
@ -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`:
|
||||
|
|
|
|||
Loading…
Reference in a new issue