Support MSC3667 in a new room version #11885
Conversation
| @@ -137,6 +137,22 @@ def check_auth_rules_for_event( | |||
| Raises: | |||
| AuthError if the checks fail | |||
| """ | |||
| # Before we get too far into event auth, validate that the event is even | |||
| # valid enough to be used | |||
| if event.type == EventTypes.PowerLevels: | |||
There was a problem hiding this comment.
this might be in the wrong place, but it's highly convenient to put it here
There was a problem hiding this comment.
It seems like for similar code we usually do it in EventValidator.validate_new + event_from_pdu_json, but I'm unsure if that makes sense or not. (I was looking at where we call validate_canonicaljson)
There was a problem hiding this comment.
We should really add a function to the Validator for inbound federation events, I guess
turt2live
force-pushed
the
travis/msc3667
branch
from
4a36426
to
0e55160
Compare
| if room_version_obj.msc3667_int_only_power_levels: | ||
| for k, v in event.content.items(): | ||
| if k in ["events", "notifications", "users"]: | ||
| if type(v) is not dict: |
There was a problem hiding this comment.
One usually does isinstance(v, dict), but it doesn't really matter in this case (isinstance correctly handles subclasses and the like)
| @@ -137,6 +137,22 @@ def check_auth_rules_for_event( | |||
| Raises: | |||
| AuthError if the checks fail | |||
| """ | |||
| # Before we get too far into event auth, validate that the event is even | |||
| # valid enough to be used | |||
| if event.type == EventTypes.PowerLevels: | |||
There was a problem hiding this comment.
We should really add a function to the Validator for inbound federation events, I guess
| # If applicable, validate that the known power levels are integers | ||
| if room_version_obj.msc3667_int_only_power_levels: | ||
| for k, v in event.content.items(): | ||
| if k in ["events", "notifications", "users"]: |
There was a problem hiding this comment.
I am somewhat tempted to just recursively check that all values are either dicts or ints? That way we don't need to remember to update this set for new fields. That would break experimental non-int fields, so maybe we could only do that on the redacted form of the power level?
There was a problem hiding this comment.
I'm a little bit worried that'd treat ban: {} as valid :(
erikjohnston
added
X-Awaiting-Changes
|
Edit: wrong PR :| |
|
@turt2live what is the state of this PR? |
|
Needs someone who isn't me to take it to merge. I can probably address some of the code quality issues, but tests are well beyond my capability. |
|
Have modernized this to present day, though it still needs someone to take a proper crack at it. |
| if k in ["events", "notifications", "users"]: | ||
| if type(v) is not dict: | ||
| raise AuthError(403, "Not a valid object: %s" % (k,)) | ||
| for v2 in v.values(): |
There was a problem hiding this comment.
this check won't work because of how the auth rules are written: we have to check the keys explicitly.
|
superseded by #13220 |
Includes MSC3604's representation for testing.MSC: matrix-org/matrix-spec-proposals#3667
Pull Request Checklist
EventStoretoEventWorkerStore.".code blocks.(run the linters)