diff --git a/changelogs/room_versions/newsfragments/1137.clarification b/changelogs/room_versions/newsfragments/1137.clarification new file mode 100644 index 00000000..b7c04045 --- /dev/null +++ b/changelogs/room_versions/newsfragments/1137.clarification @@ -0,0 +1 @@ +For room versions 1 through 10, clarify that events with rejected `auth_events` must be rejected. diff --git a/content/rooms/fragments/v1-auth-rules.md b/content/rooms/fragments/v1-auth-rules.md index 3abc1ac2..242c7620 100644 --- a/content/rooms/fragments/v1-auth-rules.md +++ b/content/rooms/fragments/v1-auth-rules.md @@ -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 - the create event, reject. -5. If type is `m.room.aliases`: + 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. +3. If the `content` of the `m.room.create` event in the room state has the + property `m.federate` set to `false`, and the `sender` domain of the event + does not match the `sender` domain of the create event, reject. +4. 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`: +5. 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`: +6. If the `sender`'s current membership state is not `join`, reject. +7. 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 +8. 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 +9. 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`: +10. 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`: +11. 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. +12. Otherwise, allow. {{% boxes/note %}} Some consequences of these rules: diff --git a/content/rooms/fragments/v3-auth-rules.md b/content/rooms/fragments/v3-auth-rules.md index 4c238fa2..d5da48c5 100644 --- a/content/rooms/fragments/v3-auth-rules.md +++ b/content/rooms/fragments/v3-auth-rules.md @@ -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 - the create event, reject. -5. If type is `m.room.aliases`: + 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. +3. If the `content` of the `m.room.create` event in the room state has the + property `m.federate` set to `false`, and the `sender` domain of the event + does not match the `sender` domain of the create event, reject. +4. 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`: +5. 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`: +6. If the `sender`'s current membership state is not `join`, reject. +7. 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 +8. 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 +9. 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`: +10. 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. +11. Otherwise, allow. {{% boxes/note %}} Some consequences of these rules: diff --git a/content/rooms/fragments/v8-auth-rules.md b/content/rooms/fragments/v8-auth-rules.md index 33813a86..ac067884 100644 --- a/content/rooms/fragments/v8-auth-rules.md +++ b/content/rooms/fragments/v8-auth-rules.md @@ -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 - the create event, reject. -5. If type is `m.room.member`: + 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. +3. If the `content` of the `m.room.create` event in the room state has the + property `m.federate` set to `false`, and the `sender` domain of the event + does not match the `sender` domain of the create event, reject. +4. 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`: +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*. -8. 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. -9. 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. -10. 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. @@ -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. +10. Otherwise, allow. {{% boxes/note %}} Some consequences of these rules: diff --git a/content/rooms/v10.md b/content/rooms/v10.md index 86ef7dc4..b4c20653 100644 --- a/content/rooms/v10.md +++ b/content/rooms/v10.md @@ -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 - the create event, reject. -5. If type is `m.room.member`: + 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. +3. If the `content` of the `m.room.create` event in the room state has the + property `m.federate` set to `false`, and the `sender` domain of the event + does not match the `sender` domain of the create event, reject. +4. 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`: +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*. -8. 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. -9. 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. -10. If type is `m.room.power_levels`: +9. 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. +10. Otherwise, allow. {{% boxes/note %}} Some consequences of these rules: