Mercurial > prosody-modules
view mod_client_management/README.md @ 6258:06fbbd45ba75
mod_cloud_notify: Readme: fix links and labels that were removed in the last commit
diff --git a/mod_cloud_notify/README.md b/mod_cloud_notify/README.md
--- a/mod_cloud_notify/README.md
+++ b/mod_cloud_notify/README.md
@@ -1,3 +1,9 @@
+----
+-labels:
+-- 'Stage-Beta'
+-summary: 'XEP-0357: Cloud push notifications'
+----
+
# Introduction
This module enables support for sending "push notifications" to clients
@@ -32,15 +38,15 @@ notification to your device. When your d
it will display it or wake up the app so it can connect to XMPP and
receive any pending messages.
-This protocol is described for developers in \[XEP-0357: Push
-Notifications\].
+This protocol is described for developers in [XEP-0357: Push
+Notifications].
-For this module to work reliably, you must have \[mod_smacks\],
-\[mod_mam\] and \[mod_carbons\] also enabled on your server.
+For this module to work reliably, you must have [mod_smacks],
+[mod_mam] and [mod_carbons] also enabled on your server.
Some clients, notably Siskin and Snikket iOS need some additional
extensions that are not currently defined in a standard XEP. To support
-these clients, see \[mod_cloud_notify_extensions\].
+these clients, see [mod_cloud_notify_extensions].
# Configuration
@@ -58,18 +64,18 @@ these clients, see \[mod_cloud_notify_ex
# Internal design notes
App servers are notified about offline messages, messages stored by
-\[mod_mam\] or messages waiting in the smacks queue. The business rules
+[mod_mam] or messages waiting in the smacks queue. The business rules
outlined
[here](//mail.jabber.org/pipermail/standards/2016-February/030925.html)
are all honored[^2].
-To cooperate with \[mod_smacks\] this module consumes some events:
+To cooperate with [mod_smacks] this module consumes some events:
`smacks-ack-delayed`, `smacks-hibernation-start` and
`smacks-hibernation-end`. These events allow this module to send out
notifications for messages received while the session is hibernated by
-\[mod_smacks\] or even when smacks acknowledgements for messages are
+[mod_smacks] or even when smacks acknowledgements for messages are
delayed by a certain amount of seconds configurable with the
-\[mod_smacks\] setting `smacks_max_ack_delay`.
+[mod_smacks] setting `smacks_max_ack_delay`.
The `smacks_max_ack_delay` setting allows to send out notifications to
clients which aren't already in smacks hibernation state (because the
| author | Menel <menel@snikket.de> |
|---|---|
| date | Fri, 13 Jun 2025 10:44:37 +0200 |
| parents | 96dda21fba75 |
| children |
line wrap: on
line source
--- labels: - Stage-Beta summary: "Manage clients with access to your account" rockspec: dependencies: - mod_sasl2_fast --- This module allows a user to identify what currently has access to their account. This module depends on [mod_sasl2_fast] and mod_tokenauth (bundled with Prosody). Both will be automatically loaded if this module is loaded. ## Configuration | Name | Description | Default | |---------------------------|--------------------------------------------------------|-----------------| | enforce_client_ids | Only allow SASL2-compatible clients | `false` | When `enforce_client_ids` is not enabled, the client listing may be less accurate due to legacy clients, which can only be tracked by their resource, which is public information, not necessarily unique to a client instance, and is also exposed to other XMPP entities the user communicates with. When `enforce_client_ids` is enabled, clients that don't support SASL2 and provide a client id will be denied access. ## Shell usage You can use this module via the Prosody shell. For example, to list a user's clients: ```shell prosodyctl shell user clients user@example.com ``` To revoke access from particular client: ```shell prosodyctl shell user revoke_client user@example.com grant/xxxxx ``` ## Compatibility Requires Prosody 13.0. Not compatible with Prosody 0.12 and earlier. ## Developers ### Protocol #### Listing clients To list clients that have access to the user's account, send the following stanza: ```xml <iq id="p" type="get"> <list xmlns="xmpp:prosody.im/protocol/manage-clients"/> </iq> ``` The server will respond with a list of clients: ```xml <iq id="p" to="mattj-gajim@auth2.superxmpp.com/gajim.UYJKBHKT" type="result" xmlns="jabber:client"> <clients xmlns="xmpp:prosody.im/protocol/manage-clients"> <client connected="true" id="client/zeiP41HLglIu" type="session"> <first-seen>2023-04-06T14:26:08Z</first-seen> <last-seen>2023-04-06T14:37:25Z</last-seen> <auth> <password/> </auth> <user-agent> <software>Gajim</software> <uri>https://gajim.org/</uri> <device>Juliet's laptop</device> </user-agent> </client> <client connected="false" id="grant/HjEEr45_LQr" type="access"> <first-seen>2023-03-27T15:16:09Z</first-seen> <last-seen>2023-03-27T15:37:24Z</last-seen> <user-agent> <software>REST client</software> </user-agent> </client> </clients> </iq> ``` On the `<client/>` tag most things are self-explanatory. The following attributes are defined: - 'connected': a boolean that reflects whether this client has an active session on the server (i.e. this includes connected and "hibernating" sessions). - 'id': an opaque reference for the client, which can be used to revoke access. - 'type': either `"session"` if this client is known to have an active or inactive client session on the server, or "access" if no session has been established (e.g. it may have been granted access to the account, but only used non-XMPP APIs or never logged in). The `<first-seen/>` and `<last-seen/>` elements contain timestamps that reflect when a client was first granted access to the user's account, and when it most recently used that access. For active sessions, it may reflect the current time or the time of the last login. The `<user-agent/>` element contains information about the client software. It may contain any of three optional child elements, each containing text content: - `<software/>` - the name of the software - `<uri/>` - a URI/URL for the client, such as a homepage - `<device/>` - a human-readable identifier/name for the device where the client runs The `<auth/>` element lists the known authentication methods that the client has used to gain access to the account. The following elements are defined: - `<password/>` - the client has presented a valid password - `<grant/>` - the client has a valid authorization grant (e.g. via OAuth) - `<fast/>` - the client has active FAST tokens #### Revoking access To revoke a client's access, send a `<revoke/>` element with an 'id' attribute containing one of the client ids fetched from the list: ```xml <iq id="p" type="set"> <revoke xmlns="xmpp:prosody.im/protocol/manage-clients" id="grant/HjEEr45_LQr" /> </iq> ``` The server will respond with an empty result if the revocation succeeds: ```xml <iq id="p" type="result" /> ``` If the client has previously authenticated with a password, there is no way to revoke access except by changing the user's password. If you request revocation of such a client, the server will respond with a 'service-unavailable' error, with the 'password-reset-required' application error: ```xml <iq id="p" type="error"> <error type="cancel"> <service-unavailable xmlns="xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'"> <password-reset-required xmlns="xmpp:prosody.im/protocol/manage-clients"/> </error> </iq> ```
