Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-04-24 19:44:09 +02:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

events with rejected_auth_events must be rejected

Browse source 
This might be kinda obvious, but didn't seem to be spelt out anywhere.
This commit is contained in:
Richard van der Hoff 2022-06-17 16:55:06 +01:00
parent 66a5920804
commit c3adb4f4da
5 changed files with 80 additions and 67 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
changelogs/room_versions/newsfragments/1137.clarification Normal file
View file

@ -0,0 +1 @@
For room versions 1 through 10, clarify that events with rejected `auth_events` must be rejected.

37
content/rooms/fragments/v1-auth-rules.md
View file

@ -26,22 +26,25 @@ The rules are as follows:
version, reject.
4. If `content` has no `creator` field, reject.
5. Otherwise, allow.
2. Reject if event has `auth_events` that:
1. have duplicate entries for a given `type` and `state_key` pair
2. have entries whose `type` and `state_key` don't match those
2. Considering the event's `auth_events`:
1. If there are duplicate entries for a given `type` and `state_key` pair,
reject.
2. If there are entries whose `type` and `state_key` don't match those
specified by the [auth events
selection](/server-server-api#auth-events-selection)
algorithm described in the server specification.
3. If event does not have a `m.room.create` in its `auth_events`,
reject.
4. If the create event content has the field `m.federate` set to `false`
and the sender domain of the event does not match the sender domain of
algorithm described in the server specification, reject.
3. If there are entries which were themselves rejected under the [checks
performed on receipt of a
PDU](server-server-api/#checks-performed-on-receipt-of-a-pdu), reject.
4. If there is no `m.room.create` event among the entries, reject.
5. If the `m.room.create` event content has the field `m.federate` set to `false`
and the `sender` domain of the event does not match the `sender` domain of
the create event, reject.
5. If type is `m.room.aliases`:
3. If type is `m.room.aliases`:
1. If event has no `state_key`, reject.
2. If sender's domain doesn't matches `state_key`, reject.
3. Otherwise, allow.
6. If type is `m.room.member`:
4. If type is `m.room.member`:
1. If no `state_key` key or `membership` key in `content`, reject.
2. If `membership` is `join`:
1. If the only previous event is an `m.room.create` and the
@ -98,15 +101,15 @@ The rules are as follows:
than the `sender`'s power level, allow.
3. Otherwise, reject.
6. Otherwise, the membership is unknown. Reject.
7. If the `sender`'s current membership state is not `join`, reject.
8. If type is `m.room.third_party_invite`:
5. If the `sender`'s current membership state is not `join`, reject.
6. If type is `m.room.third_party_invite`:
1. Allow if and only if `sender`'s current power level is greater
than or equal to the *invite level*.
9. If the event type's *required power level* is greater than the
7. If the event type's *required power level* is greater than the
`sender`'s power level, reject.
10. If the event has a `state_key` that starts with an `@` and does not
8. If the event has a `state_key` that starts with an `@` and does not
match the `sender`, reject.
11. If type is `m.room.power_levels`:
9. If type is `m.room.power_levels`:
1. If `users` key in `content` is not a dictionary with keys that
are valid user IDs with values that are integers (or a string
that is an integer), reject.
@ -130,14 +133,14 @@ The rules are as follows:
1. If the current value is equal to the `sender`'s current
power level, reject.
6. Otherwise, allow.
12. If type is `m.room.redaction`:
10. If type is `m.room.redaction`:
1. If the `sender`'s power level is greater than or equal to the
*redact level*, allow.
2. If the domain of the `event_id` of the event being redacted is
the same as the domain of the `event_id` of the
`m.room.redaction`, allow.
3. Otherwise, reject.
13. Otherwise, allow.
11. Otherwise, allow.
{{% boxes/note %}}
Some consequences of these rules:

35
content/rooms/fragments/v3-auth-rules.md
View file

@ -33,22 +33,25 @@ The complete list of rules, as of room version 3, is as follows:
version, reject.
4. If `content` has no `creator` field, reject.
5. Otherwise, allow.
2. Reject if event has `auth_events` that:
1. have duplicate entries for a given `type` and `state_key` pair
2. have entries whose `type` and `state_key` don't match those
2. Considering the event's `auth_events`:
1. If there are duplicate entries for a given `type` and `state_key` pair,
reject.
2. If there are entries whose `type` and `state_key` don't match those
specified by the [auth events
selection](/server-server-api#auth-events-selection)
algorithm described in the server specification.
3. If event does not have a `m.room.create` in its `auth_events`,
reject.
4. If the create event content has the field `m.federate` set to `false`
and the sender domain of the event does not match the sender domain of
algorithm described in the server specification, reject.
3. If there are entries which were themselves rejected under the [checks
performed on receipt of a
PDU](server-server-api/#checks-performed-on-receipt-of-a-pdu), reject.
4. If there is no `m.room.create` event among the entries, reject.
5. If the `m.room.create` event content has the field `m.federate` set to `false`
and the `sender` domain of the event does not match the `sender` domain of
the create event, reject.
5. If type is `m.room.aliases`:
3. If type is `m.room.aliases`:
1. If event has no `state_key`, reject.
2. If sender's domain doesn't matches `state_key`, reject.
3. Otherwise, allow.
6. If type is `m.room.member`:
4. If type is `m.room.member`:
1. If no `state_key` key or `membership` key in `content`, reject.
2. If `membership` is `join`:
1. If the only previous event is an `m.room.create` and the
@ -105,15 +108,15 @@ The complete list of rules, as of room version 3, is as follows:
than the `sender`'s power level, allow.
3. Otherwise, reject.
6. Otherwise, the membership is unknown. Reject.
7. If the `sender`'s current membership state is not `join`, reject.
8. If type is `m.room.third_party_invite`:
5. If the `sender`'s current membership state is not `join`, reject.
6. If type is `m.room.third_party_invite`:
1. Allow if and only if `sender`'s current power level is greater
than or equal to the *invite level*.
9. If the event type's *required power level* is greater than the
7. If the event type's *required power level* is greater than the
`sender`'s power level, reject.
10. If the event has a `state_key` that starts with an `@` and does not
8. If the event has a `state_key` that starts with an `@` and does not
match the `sender`, reject.
11. If type is `m.room.power_levels`:
9. If type is `m.room.power_levels`:
1. If `users` key in `content` is not a dictionary with keys that
are valid user IDs with values that are integers (or a string
that is an integer), reject.
@ -137,7 +140,7 @@ The complete list of rules, as of room version 3, is as follows:
1. If the current value is equal to the `sender`'s current
power level, reject.
6. Otherwise, allow.
12. Otherwise, allow.
10. Otherwise, allow.
{{% boxes/note %}}
Some consequences of these rules:

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

@ -34,18 +34,21 @@ The rules are as follows:
version, reject.
4. If `content` has no `creator` field, reject.
5. Otherwise, allow.
2. Reject if event has `auth_events` that:
1. have duplicate entries for a given `type` and `state_key` pair
2. have entries whose `type` and `state_key` don't match those
2. Considering the event's `auth_events`:
1. If there are duplicate entries for a given `type` and `state_key` pair,
reject.
2. If there are entries whose `type` and `state_key` don't match those
specified by the [auth events
selection](/server-server-api#auth-events-selection)
algorithm described in the server specification.
3. If event does not have a `m.room.create` in its `auth_events`,
reject.
4. If the create event content has the field `m.federate` set to `false`
and the sender domain of the event does not match the sender domain of
algorithm described in the server specification, reject.
3. If there are entries which were themselves rejected under the [checks
performed on receipt of a
PDU](server-server-api/#checks-performed-on-receipt-of-a-pdu), reject.
4. If there is no `m.room.create` event among the entries, reject.
5. If the `m.room.create` event content has the field `m.federate` set to `false`
and the `sender` domain of the event does not match the `sender` domain of
the create event, reject.
5. If type is `m.room.member`:
3. If type is `m.room.member`:
1. If no `state_key` key or `membership` key in `content`, reject.
2. If `content` has a `join_authorised_via_users_server`
key:
@ -119,15 +122,15 @@ The rules are as follows:
or `join`, allow.
4. Otherwise, reject.
8. Otherwise, the membership is unknown. Reject.
6. If the `sender`'s current membership state is not `join`, reject.
7. If type is `m.room.third_party_invite`:
4. If the `sender`'s current membership state is not `join`, reject.
5. If type is `m.room.third_party_invite`:
1. Allow if and only if `sender`'s current power level is greater
than or equal to the *invite level*.
8. If the event type's *required power level* is greater than the
6. If the event type's *required power level* is greater than the
`sender`'s power level, reject.
9. If the event has a `state_key` that starts with an `@` and does not
7. If the event has a `state_key` that starts with an `@` and does not
match the `sender`, reject.
10. If type is `m.room.power_levels`:
8. If type is `m.room.power_levels`:
1. If `users` key in `content` is not a dictionary with keys that
are valid user IDs with values that are integers (or a string
that is an integer), reject.
@ -151,7 +154,7 @@ The rules are as follows:
1. If the current value is equal to the `sender`'s current
power level, reject.
6. Otherwise, allow.
11. Otherwise, allow.
9. Otherwise, allow.
{{% boxes/note %}}
Some consequences of these rules:

33
content/rooms/v10.md
View file

@ -106,18 +106,21 @@ The rules are as follows:
version, reject.
4. If `content` has no `creator` field, reject.
5. Otherwise, allow.
2. Reject if event has `auth_events` that:
1. have duplicate entries for a given `type` and `state_key` pair
2. have entries whose `type` and `state_key` don't match those
2. Considering the event's `auth_events`:
1. If there are duplicate entries for a given `type` and `state_key` pair,
reject.
2. If there are entries whose `type` and `state_key` don't match those
specified by the [auth events
selection](/server-server-api#auth-events-selection)
algorithm described in the server specification.
3. If event does not have a `m.room.create` in its `auth_events`,
reject.
4. If the create event content has the field `m.federate` set to `false`
and the sender domain of the event does not match the sender domain of
algorithm described in the server specification, reject.
3. If there are entries which were themselves rejected under the [checks
performed on receipt of a
PDU](server-server-api/#checks-performed-on-receipt-of-a-pdu), reject.
4. If there is no `m.room.create` event among the entries, reject.
5. If the `m.room.create` event content has the field `m.federate` set to `false`
and the `sender` domain of the event does not match the `sender` domain of
the create event, reject.
5. If type is `m.room.member`:
3. If type is `m.room.member`:
1. If no `state_key` key or `membership` key in `content`, reject.
2. If `content` has a `join_authorised_via_users_server`
key:
@ -194,15 +197,15 @@ The rules are as follows:
or `join`, allow.
4. Otherwise, reject.
8. Otherwise, the membership is unknown. Reject.
6. If the `sender`'s current membership state is not `join`, reject.
7. If type is `m.room.third_party_invite`:
4. If the `sender`'s current membership state is not `join`, reject.
5. If type is `m.room.third_party_invite`:
1. Allow if and only if `sender`'s current power level is greater
than or equal to the *invite level*.
8. If the event type's *required power level* is greater than the
6. If the event type's *required power level* is greater than the
`sender`'s power level, reject.
9. If the event has a `state_key` that starts with an `@` and does not
7. If the event has a `state_key` that starts with an `@` and does not
match the `sender`, reject.
10. If type is `m.room.power_levels`:
8. If type is `m.room.power_levels`:
1. {{< added-in this="true" >}}
If any of the keys `users_default`, `events_default`, `state_default`,
`ban`, `redact`, `kick`, or `invite` in `content` are present and
@ -233,7 +236,7 @@ The rules are as follows:
1. If the current value is equal to the `sender`'s current
power level, reject.
6. Otherwise, allow.
11. Otherwise, allow.
9. Otherwise, allow.
{{% boxes/note %}}
Some consequences of these rules: