diff --git a/changelogs/room_versions/newsfragments/1103.clarification b/changelogs/room_versions/newsfragments/1103.clarification new file mode 100644 index 000000000..c20e5f989 --- /dev/null +++ b/changelogs/room_versions/newsfragments/1103.clarification @@ -0,0 +1 @@ +For all room versions: Add `m.federate` to the authorization rules, as originally intended. diff --git a/content/rooms/fragments/v1-auth-rules.md b/content/rooms/fragments/v1-auth-rules.md index e2429313e..3abc1ac24 100644 --- a/content/rooms/fragments/v1-auth-rules.md +++ b/content/rooms/fragments/v1-auth-rules.md @@ -34,11 +34,14 @@ The rules are as follows: algorithm described in the server specification. 3. If event does not have a `m.room.create` in its `auth_events`, reject. -4. If type is `m.room.aliases`: +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`: 1. If event has no `state_key`, reject. 2. If sender's domain doesn't matches `state_key`, reject. 3. Otherwise, allow. -5. If type is `m.room.member`: +6. 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 @@ -95,15 +98,15 @@ The rules are as follows: than the `sender`'s power level, allow. 3. Otherwise, reject. 6. 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`: +7. If the `sender`'s current membership state is not `join`, reject. +8. 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 +9. 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 +10. 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`: +11. 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. @@ -127,14 +130,14 @@ The rules are as follows: 1. If the current value is equal to the `sender`'s current power level, reject. 6. Otherwise, allow. -11. If type is `m.room.redaction`: +12. 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. -12. Otherwise, allow. +13. 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 8e902602e..4c238fa29 100644 --- a/content/rooms/fragments/v3-auth-rules.md +++ b/content/rooms/fragments/v3-auth-rules.md @@ -41,11 +41,14 @@ The complete list of rules, as of room version 3, is as follows: algorithm described in the server specification. 3. If event does not have a `m.room.create` in its `auth_events`, reject. -4. If type is `m.room.aliases`: +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`: 1. If event has no `state_key`, reject. 2. If sender's domain doesn't matches `state_key`, reject. 3. Otherwise, allow. -5. If type is `m.room.member`: +6. 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 @@ -102,15 +105,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. -6. If the `sender`'s current membership state is not `join`, reject. -7. If type is `m.room.third_party_invite`: +7. If the `sender`'s current membership state is not `join`, reject. +8. 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 +9. 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 +10. 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`: +11. 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. @@ -134,7 +137,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. -11. Otherwise, allow. +12. 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 6a5487873..33813a860 100644 --- a/content/rooms/fragments/v8-auth-rules.md +++ b/content/rooms/fragments/v8-auth-rules.md @@ -42,7 +42,10 @@ The rules are as follows: algorithm described in the server specification. 3. If event does not have a `m.room.create` in its `auth_events`, reject. -4. If type is `m.room.member`: +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`: 1. If no `state_key` key or `membership` key in `content`, reject. 2. If `content` has a `join_authorised_via_users_server` key: @@ -116,15 +119,15 @@ The rules are as follows: or `join`, allow. 4. Otherwise, reject. 8. Otherwise, the membership is unknown. Reject. -5. If the `sender`'s current membership state is not `join`, reject. -6. 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*. -7. 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. -8. 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. -9. 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. @@ -148,7 +151,7 @@ The rules are as follows: 1. If the current value is equal to the `sender`'s current power level, reject. 6. Otherwise, allow. -10. Otherwise, allow. +11. Otherwise, allow. {{% boxes/note %}} Some consequences of these rules: @@ -159,4 +162,4 @@ Some consequences of these rules: - To unban somebody, you must have power level greater than or equal to both the kick *and* ban levels, *and* greater than the target user's power level. -{{% /boxes/note %}} \ No newline at end of file +{{% /boxes/note %}} diff --git a/content/rooms/v10.md b/content/rooms/v10.md index 63a2e5297..86ef7dc4f 100644 --- a/content/rooms/v10.md +++ b/content/rooms/v10.md @@ -114,7 +114,10 @@ The rules are as follows: algorithm described in the server specification. 3. If event does not have a `m.room.create` in its `auth_events`, reject. -4. If type is `m.room.member`: +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`: 1. If no `state_key` key or `membership` key in `content`, reject. 2. If `content` has a `join_authorised_via_users_server` key: @@ -191,15 +194,15 @@ The rules are as follows: or `join`, allow. 4. Otherwise, reject. 8. Otherwise, the membership is unknown. Reject. -5. If the `sender`'s current membership state is not `join`, reject. -6. 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*. -7. 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. -8. 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. -9. If type is `m.room.power_levels`: +10. 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 @@ -230,7 +233,7 @@ The rules are as follows: 1. If the current value is equal to the `sender`'s current power level, reject. 6. Otherwise, allow. -10. Otherwise, allow. +11. Otherwise, allow. {{% boxes/note %}} Some consequences of these rules: