Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Run spam checker callbacks for invites early during room creation #14

Draft
wants to merge 9 commits into
base: master
Choose a base branch
from

Conversation

nico-famedly
Copy link
Member

This prevents a partial room from being returned to clients. We can't currently validate all possible failure cases before sending out invites (since invites can fail for arbitrary reasons on the remote side). Additionally there are some other cases that might still create a partial room (alias length, third party callbacks, etc probably), that aren't covered by this change. Third-party invites are ignored as well.

A proper fix to make the room creation atomic will most likely need spec changes.

See also https://github.com/famedly/product-management/issues/2385

jdreichmann and others added 9 commits September 5, 2024 13:18
Co-authored-by: Nicolas Werner <[email protected]>
Co-authored-by: Jan Christian Grünhage <[email protected]>
This allows clients to pass an extra parameter when refreshing a token,
which overrides the configured refresh token timeout in the Synapse
config. This allows a client to opt into a shorter (or longer) lifetime
for their refresh token, which could be used to sign out web sessions
with a specific timeout.

Open questions are mostly if there should be a maximum refresh token
lifetime someone could configure and if this should also be configurable
on login. The latter doesn't seem as necessary, since a client can just
refresh immediately after login (although that is racy).

Once we figure out a nice behaviour for this, we should also write an
MSC. For now this is just an experiment.
This prevents a partial room from being returned to clients. We can't
currently validate all possible failure cases before sending out invites
(since invites can fail for arbitrary reasons on the remote side).
Additionally there are some other cases that might still create a
partial room (alias length, third party callbacks, etc probably), that
aren't covered by this change. Third-party invites are ignored as well.

A proper fix to make the room creation atomic will most likely need spec
changes.

Signed-off-by: Nicolas Werner <[email protected]>
@nico-famedly
Copy link
Member Author

I guess this won't necessarily help, since for remote invites it is usually the remote user, who doesn't have us in their invite allow list... I guess for a single user invite, we could shutdown the room immediately...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants