diff options
author | erikjohnston <erikjohnston@users.noreply.github.com> | 2022-05-31 13:48:55 +0000 |
---|---|---|
committer | erikjohnston <erikjohnston@users.noreply.github.com> | 2022-05-31 13:48:55 +0000 |
commit | 25eebe534e5fd4fe5ecd2947dde386549c3313ec (patch) | |
tree | fba491865f3150f11a911e2dafc82e53ce704039 /develop/print.html | |
parent | deploy: b2b5279a3f1b4012de664b424f9e9db13ce3c774 (diff) | |
download | synapse-25eebe534e5fd4fe5ecd2947dde386549c3313ec.tar.xz |
deploy: 3594f6c1f340f12bfcb2fec9e99ac108a714b508
Diffstat (limited to 'develop/print.html')
-rw-r--r-- | develop/print.html | 44 |
1 files changed, 21 insertions, 23 deletions
diff --git a/develop/print.html b/develop/print.html index 85b445f567..08a9f31b87 100644 --- a/develop/print.html +++ b/develop/print.html @@ -1694,9 +1694,9 @@ COMMIT; <p><a href="https://github.com/matrix-org/synapse/issues/11779#issuecomment-1131545970">This comment on issue 11779</a> has queries that can be used to check a database for this problem in advance.</p> </details> -<h2 id="spamchecker-apis-check_event_for_spam-has-a-new-signature"><a class="header" href="#spamchecker-apis-check_event_for_spam-has-a-new-signature">SpamChecker API's <code>check_event_for_spam</code> has a new signature.</a></h2> +<h2 id="new-signature-for-the-spam-checker-callback-check_event_for_spam"><a class="header" href="#new-signature-for-the-spam-checker-callback-check_event_for_spam">New signature for the spam checker callback <code>check_event_for_spam</code></a></h2> <p>The previous signature has been deprecated.</p> -<p>Whereas <code>check_event_for_spam</code> callbacks used to return <code>Union[str, bool]</code>, they should now return <code>Union["synapse.module_api.Allow", "synapse.module_api.errors.Codes"]</code>.</p> +<p>Whereas <code>check_event_for_spam</code> callbacks used to return <code>Union[str, bool]</code>, they should now return <code>Union["synapse.module_api.NOT_SPAM", "synapse.module_api.errors.Codes"]</code>.</p> <p>This is part of an ongoing refactoring of the SpamChecker API to make it less ambiguous and more powerful.</p> <p>If your module implements <code>check_event_for_spam</code> as follows:</p> <pre><code class="language-python">async def check_event_for_spam(event): @@ -1712,8 +1712,8 @@ has queries that can be used to check a database for this problem in advance.</p # Event is spam, mark it as forbidden (you may use some more precise error # code if it is useful). return synapse.module_api.errors.Codes.FORBIDDEN - # Event is not spam, mark it as `ALLOW`. - return synapse.module_api.ALLOW + # Event is not spam, mark it as such. + return synapse.module_api.NOT_SPAM </code></pre> <h1 id="upgrading-to-v1590"><a class="header" href="#upgrading-to-v1590">Upgrading to v1.59.0</a></h1> <h2 id="device-name-lookup-over-federation-has-been-disabled-by-default"><a class="header" href="#device-name-lookup-over-federation-has-been-disabled-by-default">Device name lookup over federation has been disabled by default</a></h2> @@ -11213,28 +11213,26 @@ Synapse instances. Spam checker callbacks can be registered using the module API <h2 id="callbacks"><a class="header" href="#callbacks">Callbacks</a></h2> <p>The available spam checker callbacks are:</p> <h3 id="check_event_for_spam"><a class="header" href="#check_event_for_spam"><code>check_event_for_spam</code></a></h3> -<p><em>First introduced in Synapse v1.37.0</em> -<em>Signature extended to support Allow and Code in Synapse v1.60.0</em> -<em>Boolean and string return value types deprecated in Synapse v1.60.0</em></p> -<pre><code class="language-python">async def check_event_for_spam(event: "synapse.module_api.EventBase") -> Union["synapse.module_api.ALLOW", "synapse.module_api.error.Codes", str, bool] -</code></pre> -<p>Called when receiving an event from a client or via federation. The callback must return either:</p> -<ul> -<li><code>synapse.module_api.ALLOW</code>, to allow the operation. Other callbacks -may still decide to reject it.</li> -<li><code>synapse.api.Codes</code> to reject the operation with an error code. In case -of doubt, <code>synapse.api.error.Codes.FORBIDDEN</code> is a good error code.</li> -<li>(deprecated) a <code>str</code> to reject the operation and specify an error message. Note that clients +<p><em>First introduced in Synapse v1.37.0</em></p> +<p><em>Changed in Synapse v1.60.0: <code>synapse.module_api.NOT_SPAM</code> and <code>synapse.module_api.errors.Codes</code> can be returned by this callback. Returning a boolean or a string is now deprecated.</em> </p> +<pre><code class="language-python">async def check_event_for_spam(event: "synapse.module_api.EventBase") -> Union["synapse.module_api.NOT_SPAM", "synapse.module_api.errors.Codes", str, bool] +</code></pre> +<p>Called when receiving an event from a client or via federation. The callback must return one of:</p> +<ul> +<li><code>synapse.module_api.NOT_SPAM</code>, to allow the operation. Other callbacks may still +decide to reject it.</li> +<li><code>synapse.module_api.errors.Codes</code> to reject the operation with an error code. In case +of doubt, <code>synapse.module_api.errors.Codes.FORBIDDEN</code> is a good error code.</li> +<li>(deprecated) a non-<code>Codes</code> <code>str</code> to reject the operation and specify an error message. Note that clients typically will not localize the error message to the user's preferred locale.</li> -<li>(deprecated) on <code>False</code>, behave as <code>ALLOW</code>. Deprecated as confusing, as some -callbacks in expect <code>True</code> to allow and others <code>True</code> to reject.</li> -<li>(deprecated) on <code>True</code>, behave as <code>synapse.api.error.Codes.FORBIDDEN</code>. Deprecated as confusing, as -some callbacks in expect <code>True</code> to allow and others <code>True</code> to reject.</li> +<li>(deprecated) <code>False</code>, which is the same as returning <code>synapse.module_api.NOT_SPAM</code>.</li> +<li>(deprecated) <code>True</code>, which is the same as returning <code>synapse.module_api.errors.Codes.FORBIDDEN</code>.</li> </ul> <p>If multiple modules implement this callback, they will be considered in order. If a -callback returns <code>synapse.module_api.ALLOW</code>, Synapse falls through to the next one. The value of the -first callback that does not return <code>synapse.module_api.ALLOW</code> will be used. If this happens, Synapse -will not call any of the subsequent implementations of this callback.</p> +callback returns <code>synapse.module_api.NOT_SPAM</code>, Synapse falls through to the next one. +The value of the first callback that does not return <code>synapse.module_api.NOT_SPAM</code> will +be used. If this happens, Synapse will not call any of the subsequent implementations of +this callback.</p> <h3 id="user_may_join_room"><a class="header" href="#user_may_join_room"><code>user_may_join_room</code></a></h3> <p><em>First introduced in Synapse v1.37.0</em></p> <pre><code class="language-python">async def user_may_join_room(user: str, room: str, is_invited: bool) -> bool |