Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-01-01 21:48:37 +01:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

Fix incorrect assumptions about the sender field of a knock event

Browse source 
Got a bit confused with the sender and state_key being different in invite
membership events. In case of a knock, even if the knock event is being
inserted into the room by another homeserver over federation, the sender
of the event is still the knocking user, just like the state_key.
This commit is contained in:
Andrew Morgan 2020-10-05 20:24:54 +01:00
parent 525d1d33e0
commit a924f5b3d5
1 changed files with 17 additions and 14 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

31
proposals/2403-knock.md
View file

@ -50,20 +50,21 @@ rules from room version 5 are:
```
a. If `membership` is `knock`:
i. If the `join_rule` is anything other than `knock`, reject.
ii. If `sender` matches `state_key`, reject.
iii. If the `sender`'s current membership state is not `join`, reject.
iv. If the *target user*'s membership is not `ban` or `join`, allow.
v. Otherwise, reject.
ii. If `sender` does not match `state_key`, reject.
iii. If the `sender`'s membership is not `ban` or `join`, allow.
iv. Otherwise, reject.
```
Note that:
- a.ii is justified as it doesn't make sense for a user that is already
in the room to knock.
- a.iii is justified as an event should be rejected if it was sent by
someone not in the room (note the sender of a knock event is the
homserver that's in the room, rather than the homeserver knocking).
- a.iv is justified as knocks should be allowed if the knocking user has
been banned from the room, or they're already in the room.
- The `sender` field in the event is set to the user ID of the knocking
user, not any other user in the room that belongs to a homeserver that
the knocking user is using to inject into the room DAG. This is separate
from an invite membership event, where the `sender` is the inviter and
the `state_key` is the invitee.
- a.ii is justified as one user should not be able to knock on behalf of
another user.
- a.iii is justified as knocks should not be allowed if the knocking user
has been banned from the room, or if they are already in the room.
- Knocks are not restricted by power level like invites are. The `join_rules`
are already used to enforce whether someone can or cannot knock.
@ -71,13 +72,15 @@ rules from room version 5 are:
* Under "11. If type is `m.room.redaction`", the following should be added:
```
a. If the type of the `event_id` of the event being redacted is `m.room.member` and the `membership` field in its `content` dictionary is `knock`, reject.
a. If the type of the `event_id` of the event being redacted is
`m.room.member` and the `membership` field in its `content` dictionary is
`knock`, reject.
```
Notes:
- The server you sent a knock through later should not be able to redact
that knock afterwards. The knock should instead be rejected by whoever
has the authority to.
that knock afterwards. The knock should instead be rejected by whoever
has the authority to.
XXX: Is this the best place in the auth rules to enforce this?