This repository has been archived by the owner on Apr 26, 2024. It is now read-only.
-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
* Split up the documentation in several files rather than one huge one * Add examples for each callback category * Other niceties like fixing #10632 * Add titles to callbacks so they're easier to find in the navigation panels and link to
- Loading branch information
1 parent
01df612
commit 03caba6
Showing
10 changed files
with
537 additions
and
404 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
Split up the modules documentation and add examples for module developers. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file was deleted.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,33 @@ | ||
# Account validity callbacks | ||
|
||
Account validity callbacks allow module developers to add extra steps to verify the | ||
validity on an account, i.e. see if a user can be granted access to their account on the | ||
Synapse instance. Account validity callbacks can be registered using the module API's | ||
`register_account_validity_callbacks` method. | ||
|
||
The available account validity callbacks are: | ||
|
||
### `is_user_expired` | ||
|
||
```python | ||
async def is_user_expired(user: str) -> Optional[bool] | ||
``` | ||
|
||
Called when processing any authenticated request (except for logout requests). The module | ||
can return a `bool` to indicate whether the user has expired and should be locked out of | ||
their account, or `None` if the module wasn't able to figure it out. The user is | ||
represented by their Matrix user ID (e.g. `@alice:example.com`). | ||
|
||
If the module returns `True`, the current request will be denied with the error code | ||
`ORG_MATRIX_EXPIRED_ACCOUNT` and the HTTP status code 403. Note that this doesn't | ||
invalidate the user's access token. | ||
|
||
### `on_user_registration` | ||
|
||
```python | ||
async def on_user_registration(user: str) -> None | ||
``` | ||
|
||
Called after successfully registering a user, in case the module needs to perform extra | ||
operations to keep track of them. (e.g. add them to a database table). The user is | ||
represented by their Matrix user ID. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,34 @@ | ||
# Modules | ||
|
||
Synapse supports extending its functionality by configuring external modules. | ||
|
||
## Using modules | ||
|
||
To use a module on Synapse, add it to the `modules` section of the configuration file: | ||
|
||
```yaml | ||
modules: | ||
- module: my_super_module.MySuperClass | ||
config: | ||
do_thing: true | ||
- module: my_other_super_module.SomeClass | ||
config: {} | ||
``` | ||
Each module is defined by a path to a Python class as well as a configuration. This | ||
information for a given module should be available in the module's own documentation. | ||
**Note**: When using third-party modules, you effectively allow someone else to run | ||
custom code on your Synapse homeserver. Server admins are encouraged to verify the | ||
provenance of the modules they use on their homeserver and make sure the modules aren't | ||
running malicious code on their instance. | ||
Also note that we are currently in the process of migrating module interfaces to this | ||
system. While some interfaces might be compatible with it, others still require | ||
configuring modules in another part of Synapse's configuration file. | ||
Currently, only the following pre-existing interfaces are compatible with this new system: | ||
* spam checker | ||
* third-party rules | ||
* presence router |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,17 @@ | ||
# Porting an existing module that uses the old interface | ||
|
||
In order to port a module that uses Synapse's old module interface, its author needs to: | ||
|
||
* ensure the module's callbacks are all asynchronous. | ||
* register their callbacks using one or more of the `register_[...]_callbacks` methods | ||
from the `ModuleApi` class in the module's `__init__` method (see [this section](writing_a_module.html#registering-a-callback) | ||
for more info). | ||
|
||
Additionally, if the module is packaged with an additional web resource, the module | ||
should register this resource in its `__init__` method using the `register_web_resource` | ||
method from the `ModuleApi` class (see [this section](writing_a_module.html#registering-a-web-resource) for | ||
more info). | ||
|
||
The module's author should also update any example in the module's configuration to only | ||
use the new `modules` section in Synapse's configuration file (see [this section](index.html#using-modules) | ||
for more info). |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,90 @@ | ||
# Presence router callbacks | ||
|
||
Presence router callbacks allow module developers to specify additional users (local or remote) | ||
to receive certain presence updates from local users. Presence router callbacks can be | ||
registered using the module API's `register_presence_router_callbacks` method. | ||
|
||
## Callbacks | ||
|
||
The available presence router callbacks are: | ||
|
||
### `get_users_for_states` | ||
|
||
```python | ||
async def get_users_for_states( | ||
state_updates: Iterable["synapse.api.UserPresenceState"], | ||
) -> Dict[str, Set["synapse.api.UserPresenceState"]] | ||
``` | ||
**Requires** `get_interested_users` to also be registered | ||
|
||
Called when processing updates to the presence state of one or more users. This callback can | ||
be used to instruct the server to forward that presence state to specific users. The module | ||
must return a dictionary that maps from Matrix user IDs (which can be local or remote) to the | ||
`UserPresenceState` changes that they should be forwarded. | ||
|
||
Synapse will then attempt to send the specified presence updates to each user when possible. | ||
|
||
### `get_interested_users` | ||
|
||
```python | ||
async def get_interested_users( | ||
user_id: str | ||
) -> Union[Set[str], "synapse.module_api.PRESENCE_ALL_USERS"] | ||
``` | ||
**Requires** `get_users_for_states` to also be registered | ||
|
||
Called when determining which users someone should be able to see the presence state of. This | ||
callback should return complementary results to `get_users_for_state` or the presence information | ||
may not be properly forwarded. | ||
|
||
The callback is given the Matrix user ID for a local user that is requesting presence data and | ||
should return the Matrix user IDs of the users whose presence state they are allowed to | ||
query. The returned users can be local or remote. | ||
|
||
Alternatively the callback can return `synapse.module_api.PRESENCE_ALL_USERS` | ||
to indicate that the user should receive updates from all known users. | ||
|
||
## Example | ||
|
||
The example below is a module that implements both presence router callbacks, and ensures | ||
that `@alice:example.org` receives all presence updates from `@bob:example.com` and | ||
`@charlie:somewhere.org`, regardless of whether Alice shares a room with any of them. | ||
|
||
```python | ||
from typing import Dict, Iterable, Set, Union | ||
|
||
from synapse.module_api import ModuleApi | ||
|
||
|
||
class CustomPresenceRouter: | ||
def __init__(self, config: dict, api: ModuleApi): | ||
self.api = api | ||
|
||
self.api.register_presence_router_callbacks( | ||
get_users_for_states=self.get_users_for_states, | ||
get_interested_users=self.get_interested_users, | ||
) | ||
|
||
async def get_users_for_states( | ||
self, | ||
state_updates: Iterable["synapse.api.UserPresenceState"], | ||
) -> Dict[str, Set["synapse.api.UserPresenceState"]]: | ||
res = {} | ||
for update in state_updates: | ||
if ( | ||
update.user_id == "@bob:example.com" | ||
or update.user_id == "@charlie:somewhere.org" | ||
): | ||
res.setdefault("@alice:example.com", set()).add(update) | ||
|
||
return res | ||
|
||
async def get_interested_users( | ||
self, | ||
user_id: str, | ||
) -> Union[Set[str], "synapse.module_api.PRESENCE_ALL_USERS"]: | ||
if user_id == "@alice:example.com": | ||
return {"@bob:example.com", "@charlie:somewhere.org"} | ||
|
||
return set() | ||
``` |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,160 @@ | ||
# Spam checker callbacks | ||
|
||
Spam checker callbacks allow module developers to implement spam mitigation actions for | ||
Synapse instances. Spam checker callbacks can be registered using the module API's | ||
`register_spam_checker_callbacks` method. | ||
|
||
## Callbacks | ||
|
||
The available spam checker callbacks are: | ||
|
||
### `check_event_for_spam` | ||
|
||
```python | ||
async def check_event_for_spam(event: "synapse.events.EventBase") -> Union[bool, str] | ||
``` | ||
|
||
Called when receiving an event from a client or via federation. The module can return | ||
either a `bool` to indicate whether the event must be rejected because of spam, or a `str` | ||
to indicate the event must be rejected because of spam and to give a rejection reason to | ||
forward to clients. | ||
|
||
### `user_may_invite` | ||
|
||
```python | ||
async def user_may_invite(inviter: str, invitee: str, room_id: str) -> bool | ||
``` | ||
|
||
Called when processing an invitation. The module must return a `bool` indicating whether | ||
the inviter can invite the invitee to the given room. Both inviter and invitee are | ||
represented by their Matrix user ID (e.g. `@alice:example.com`). | ||
|
||
### `user_may_create_room` | ||
|
||
```python | ||
async def user_may_create_room(user: str) -> bool | ||
``` | ||
|
||
Called when processing a room creation request. The module must return a `bool` indicating | ||
whether the given user (represented by their Matrix user ID) is allowed to create a room. | ||
|
||
### `user_may_create_room_alias` | ||
|
||
```python | ||
async def user_may_create_room_alias(user: str, room_alias: "synapse.types.RoomAlias") -> bool | ||
``` | ||
|
||
Called when trying to associate an alias with an existing room. The module must return a | ||
`bool` indicating whether the given user (represented by their Matrix user ID) is allowed | ||
to set the given alias. | ||
|
||
### `user_may_publish_room` | ||
|
||
```python | ||
async def user_may_publish_room(user: str, room_id: str) -> bool | ||
``` | ||
|
||
Called when trying to publish a room to the homeserver's public rooms directory. The | ||
module must return a `bool` indicating whether the given user (represented by their | ||
Matrix user ID) is allowed to publish the given room. | ||
|
||
### `check_username_for_spam` | ||
|
||
```python | ||
async def check_username_for_spam(user_profile: Dict[str, str]) -> bool | ||
``` | ||
|
||
Called when computing search results in the user directory. The module must return a | ||
`bool` indicating whether the given user profile can appear in search results. The profile | ||
is represented as a dictionary with the following keys: | ||
|
||
* `user_id`: The Matrix ID for this user. | ||
* `display_name`: The user's display name. | ||
* `avatar_url`: The `mxc://` URL to the user's avatar. | ||
|
||
The module is given a copy of the original dictionary, so modifying it from within the | ||
module cannot modify a user's profile when included in user directory search results. | ||
|
||
### `check_registration_for_spam` | ||
|
||
```python | ||
async def check_registration_for_spam( | ||
email_threepid: Optional[dict], | ||
username: Optional[str], | ||
request_info: Collection[Tuple[str, str]], | ||
auth_provider_id: Optional[str] = None, | ||
) -> "synapse.spam_checker_api.RegistrationBehaviour" | ||
``` | ||
|
||
Called when registering a new user. The module must return a `RegistrationBehaviour` | ||
indicating whether the registration can go through or must be denied, or whether the user | ||
may be allowed to register but will be shadow banned. | ||
|
||
The arguments passed to this callback are: | ||
|
||
* `email_threepid`: The email address used for registering, if any. | ||
* `username`: The username the user would like to register. Can be `None`, meaning that | ||
Synapse will generate one later. | ||
* `request_info`: A collection of tuples, which first item is a user agent, and which | ||
second item is an IP address. These user agents and IP addresses are the ones that were | ||
used during the registration process. | ||
* `auth_provider_id`: The identifier of the SSO authentication provider, if any. | ||
|
||
### `check_media_file_for_spam` | ||
|
||
```python | ||
async def check_media_file_for_spam( | ||
file_wrapper: "synapse.rest.media.v1.media_storage.ReadableFileWrapper", | ||
file_info: "synapse.rest.media.v1._base.FileInfo", | ||
) -> bool | ||
``` | ||
|
||
Called when storing a local or remote file. The module must return a boolean indicating | ||
whether the given file can be stored in the homeserver's media store. | ||
|
||
## Example | ||
|
||
The example below is a module that implements the spam checker callback | ||
`check_event_for_spam` to deny any message sent by users whose Matrix user IDs are | ||
mentioned in a configured list, and registers a web resource to the path | ||
`/_synapse/client/list_spam_checker/is_evil` that returns a JSON object indicating | ||
whether the provided user appears in that list. | ||
|
||
```python | ||
import json | ||
from typing import Union | ||
|
||
from twisted.web.resource import Resource | ||
from twisted.web.server import Request | ||
|
||
from synapse.module_api import ModuleApi | ||
|
||
|
||
class IsUserEvilResource(Resource): | ||
def __init__(self, config): | ||
super(IsUserEvilResource, self).__init__() | ||
self.evil_users = config.get("evil_users") or [] | ||
|
||
def render_GET(self, request: Request): | ||
user = request.args.get(b"user")[0] | ||
request.setHeader(b"Content-Type", b"application/json") | ||
return json.dumps({"evil": user in self.evil_users}) | ||
|
||
|
||
class ListSpamChecker: | ||
def __init__(self, config: dict, api: ModuleApi): | ||
self.api = api | ||
self.evil_users = config.get("evil_users") or [] | ||
|
||
self.api.register_spam_checker_callbacks( | ||
check_event_for_spam=self.check_event_for_spam, | ||
) | ||
|
||
self.api.register_web_resource( | ||
path="/_synapse/client/list_spam_checker/is_evil", | ||
resource=IsUserEvilResource(config), | ||
) | ||
|
||
async def check_event_for_spam(self, event: "synapse.events.EventBase") -> Union[bool, str]: | ||
return event.sender not in self.evil_users | ||
``` |
Oops, something went wrong.