Document the event auth rules #1027
Conversation
These are a necessary precursor to state resolution.
This doesn't seem to be a thing that is actually used. Also remove unhelpful example which was more lies than truth.
specification/server_server_api.rst
Outdated
|
|
||
| i. If ``sender`` matches ``state_key``, allow. | ||
|
|
||
| #. If the ``sender``'s current membership state is not ``joined``, reject. |
There was a problem hiding this comment.
There's a clause that allows an admin "unbanning" someone if they were banned an the admin has a power level above the "ban_level"
There was a problem hiding this comment.
thanks, fixed in 47005d5.
My understanding of the code is that you can unban someone even if you have PL < ban, provided you have PL >= kick, and the target's PL is <= yours. Seems a bit odd but if it's true we might as well spec it. Can you double-check me?
There was a problem hiding this comment.
https://github.com/matrix-org/synapse/blob/master/synapse/event_auth.py#L320 seems to suggest you need a PL >= ban to unban?
There was a problem hiding this comment.
Right, apparently I misread the code. Let me try again.
It looks like you have to have PL >= ban and PL >= kick and PL >= the target to unban someone, otherwise you'll get caught at https://github.com/matrix-org/synapse/blob/master/synapse/event_auth.py#L327. Right?
There was a problem hiding this comment.
Right, one more go in 6d038e1. PTAL?
|
There's also some checks to ensure that the right signatures are there: https://github.com/matrix-org/synapse/blob/master/synapse/event_auth.py#L47-L68, not sure if they should be included here or not |
| result in the user being considered joined. | ||
|
|
||
| 1. If type is ``m.room.create``, allow if and only if has depth 0 and it has no | ||
| previous events - *i.e.* it is the first event in the room. |
There was a problem hiding this comment.
There's an assertion for that room_id domain matches sender domain
There was a problem hiding this comment.
yeah. I think there's a whole class of checks like this and the signatures which I want to keep separately from the auth rules, because they don't really play a part in state resolution. The line's a bit fuzzy, but I want to punt this one and the signatures to a separate section and a separate PR.
Use dome definitions to avoid so much repetition, and hopefully make things clearer.
specification/server_server_api.rst
Outdated
|
|
||
| #. If the ``join_rule`` is ``public``, allow. | ||
|
|
||
| #. Otherwise, reject. |
There was a problem hiding this comment.
Don't we need to handle invites?
|
<3 |
|
that was harder work than it should have been. thanks! |
These are a necessary precursor to state resolution.