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

Allow verifying room membership against multiple Synapse instances #25

Open
anoadragon453 opened this issue Aug 18, 2021 · 1 comment
Open

Comments

@anoadragon453
Copy link
Member

Currently only a single Synapse homeserver URL and admin access token can be configured per instance of matrix-user-verification-service. However, in a deployment that features multiple, federated homeservers but only a single Jitsi cluster, one would need to verify room membership of users across multiple servers.

As the prosody module is passed the homeserver domain name in each verification request, we could query multiple homeservers, as long as each are configured.

This issue proposes a mechanism for allowing verification of both a user's registration as well as their participation in a room across multiple homeservers with only a single instance of the matrix-user-verification-service.


Currently homeserver credentials are configured through the use of environment variables. UVS_HOMESERVER_URL is the URL of the homeserver to verify against, while UVS_ACCESS_TOKEN is the access token of a Synapse admin user. The matrix-user-verification-service will then call GET {UVS_HOMESERVER_URL}/_synapse/admin/v1/rooms/{ROOM_ID}/state with the admin access token in order to check the state of the room and whether the user is currently present.

There are many ways to alter this configuration to allow multiple homeservers. One such solution is to provide an additional environment variable, i.e:

UVS_VERIFY_ROOM_MEMBERSHIP_HOMESERVERS=domain1.name:admin_access_token1;domain2.name:admin_access_token2...

which the matrix-user-verification-service would then use when fielding POST /verify/user_in_room requests from the mod_matrix_power_sync prosody module.

Note that in the above deployment scenario, one should not set UVS_OPENID_VERIFY_SERVER_NAME. This will cause the matrix-user-verification-service to verify OpenID tokens (ensuring that a user exists on the homeserver) against any requested homeserver, rather than just the one specified by UVS_OPENID_VERIFY_SERVER_NAME.

@anoadragon453
Copy link
Member Author

Note that https://github.com/jkanefendt/prosody-mod-auth-matrix-user-verification-ng is an entirely different approach to this problem which removes the need to use Synapse-specific admin APIs.

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

No branches or pull requests

1 participant