Mercurial > prosody-modules
view mod_spam_report_forwarder/README.markdown @ 5511:0860497152af
mod_http_oauth2: Record hash of client_id to allow future verification
RFC 6819 section 5.2.2.2 states that refresh tokens MUST be bound to the
client. In order to do that, we must record something that can
definitely tie the client to the grant. Since the full client_id is so
large (why we have this client_subset function), a hash is stored
instead.
author | Kim Alvefur <zash@zash.se> |
---|---|
date | Fri, 02 Jun 2023 10:14:16 +0200 |
parents | 94472eb41d0a |
children |
line wrap: on
line source
--- labels: - 'Stage-Beta' summary: 'Forward spam/abuse reports to a JID' --- This module forwards spam/abuse reports (e.g. those submitted by users via XEP-0377 via mod_spam_reporting) to one or more JIDs. ## Configuration Install and enable the module the same as any other. There is a single option, `spam_report_destinations` which accepts a list of JIDs to send reports to. For example: ```lua modules_enabled = { --- "spam_reporting"; "spam_report_forwarder"; --- } spam_report_destinations = { "antispam.example.com" } ``` ## Protocol This section is intended for developers. XEP-0377 assumes the report is embedded within another protocol such as XEP-0191, and doesn't specify a format for communicating "standalone" reports. This module transmits them inside a `<message>` stanza, and adds a `<jid/>` element (borrowed from XEP-0268): ```xml <message from="prosody.example" to="destination.example"> <report xmlns="urn:xmpp:reporting:1" reason="urn:xmpp:reporting:spam"> <jid xmlns="urn:xmpp:jid:0">spammer@bad.example</jid> <text> Never came trouble to my house like this. </text> </report> </message> ```