-
-
Notifications
You must be signed in to change notification settings - Fork 6
Bring spamchecker to parity with mainline #108
Conversation
…vites (#10898) This is in the context of creating new module callbacks that modules in https://github.com/matrix-org/synapse-dinsic can use, in an effort to reconcile the spam checker API in synapse-dinsic with the one in mainline. This adds a callback that's fairly similar to user_may_create_room except it also allows processing based on the invites sent at room creation.
Co-authored-by: Erik Johnston <erik@matrix.org>
This is in the context of creating new module callbacks that modules in https://github.com/matrix-org/synapse-dinsic can use, in an effort to reconcile the spam checker API in synapse-dinsic with the one in mainline. Note that a module callback already exists for 3pid invites (https://matrix-org.github.io/synapse/develop/modules/third_party_rules_callbacks.html#check_threepid_can_be_invited) but it doesn't check whether the sender of the invite is allowed to send it.
Bring other callbacks to party with mainline, and fixup code calling to the various callbacks.
Tests are expected to fail currently, since I haven't updated the |
c82793a
to
23e48a1
Compare
c7552b2
to
81c2455
Compare
Because we already do these checks with RoomAccessRules
81c2455
to
ed31c6b
Compare
Would it be easier to have the commits that are pure cherry-picks a separate PR? Or do the other commits unbreak stuff? |
Definitely possible, I was thinking it would be just as simple to ignore them and review the other commits but now I'm not sure that's the correct approach. I'll close this PR and open two new ones. |
Thanks! |
@erikjohnston Actually, I've tried doing this, and found that things are kind of clashing because of differing signatures for callbacks with the same name between mainline and this repo (e.g. So opening a PR with just the cherry-picks means the So I'm afraid I think I'll have to reopen this PR. To help with review, these are the diffs with actual changes that aren't just cherry-picks and resolved merge conflicts: I've updated the PR description to reflect this. |
@@ -0,0 +1 @@ | |||
Add a `user_may_send_3pid_invite` spam checker callback for modules to allow or deny 3PID invites. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want to keep the changelogs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we care, we don't generate changelogs with towncrier for this repo.
The module has now moved to https://github.com/matrix-org/synapse-domain-rule-checker __Note to ops__: To deploy this change, the module needs to be installed in addition to Synapse (from the aforementioned repo, or the PyPI project mentioned its readme). The configuration doesn't change besides a) `default` is renamed into `can_invite_if_not_in_domain_mapping` and b) the module's configuration has moved to the `modules` section of the configuration file (though that was already the case as of #108).
Note to reviewer:
Apologies for the massive PR size, as splitting turned out to be very non trivial (see #108 (comment))
Can be reviewed commit by commit, or through the following diffs (which exclude cherry picks and merge conflict resolutions):
First 3 commits are
git cherry-pick
s of:The 5th commit is a
git cherry-pick
of matrix-org/synapse#11204.Note to ops:
When deploying a Synapse version including this PR, a Synapse config change is required. All that's needed should be to move the config for the
DomainRuleChecker
from thespam_checker
section to themodules
one of the configuration file, since I also had to port the module to the new system. So this means this bit of configuration:Should become:
Note that this PR also removes support for the now useless
can_only_create_one_to_one_rooms
config option, but Synapse or the module won't fail if this option is kept around.