slidge.plugins.signal.gateway
#
Module Contents#
Classes#
Abstract base class to implement gateway commands (chatbot and ad-hoc) |
|
Abstract base class to implement gateway commands (chatbot and ad-hoc) |
|
Abstract base class to implement gateway commands (chatbot and ad-hoc) |
|
Abstract base class to implement gateway commands (chatbot and ad-hoc) |
|
Must be subclassed by a plugin to set up various aspects of the XMPP |
|
Extends |
Functions#
|
Attributes#
- class slidge.plugins.signal.gateway.Link(xmpp)[source]#
Bases:
slidge.core.command.Command
Abstract base class to implement gateway commands (chatbot and ad-hoc)
- Parameters:
xmpp (slidge.core.gateway.BaseGateway) –
- HELP = "Use an existing signal account with slidge as a 'secondary device'. You will need to keep your..."[source]#
- async run(_session, ifrom, *args)[source]#
Entry point of the command
- Parameters:
session – If triggered by a registered user, its slidge Session
ifrom (slixmpp.JID) – JID of the command-triggering entity
args – When triggered via chatbot type message, additional words after the CHAT_COMMAND string was passed
- Returns:
Either a TableResult, a Form, a Confirmation, a text, or None
- class slidge.plugins.signal.gateway.LinkedDevices(xmpp)[source]#
Bases:
slidge.core.command.Command
Abstract base class to implement gateway commands (chatbot and ad-hoc)
- Parameters:
xmpp (slidge.core.gateway.BaseGateway) –
- async run(session, ifrom, *args)[source]#
Entry point of the command
- Parameters:
session – If triggered by a registered user, its slidge Session
ifrom (slixmpp.JID) – JID of the command-triggering entity
args – When triggered via chatbot type message, additional words after the CHAT_COMMAND string was passed
- Returns:
Either a TableResult, a Form, a Confirmation, a text, or None
- class slidge.plugins.signal.gateway.LinkDevice(xmpp)[source]#
Bases:
slidge.core.command.Command
Abstract base class to implement gateway commands (chatbot and ad-hoc)
- Parameters:
xmpp (slidge.core.gateway.BaseGateway) –
- async run(session, ifrom, *args)[source]#
Entry point of the command
- Parameters:
session – If triggered by a registered user, its slidge Session
ifrom (slixmpp.JID) – JID of the command-triggering entity
args – When triggered via chatbot type message, additional words after the CHAT_COMMAND string was passed
- Returns:
Either a TableResult, a Form, a Confirmation, a text, or None
- async finish(form_values, session, _ifrom)[source]#
- Parameters:
session (slidge.plugins.signal.session.Session) –
- class slidge.plugins.signal.gateway.ChangeContactName(xmpp)[source]#
Bases:
slidge.core.command.Command
Abstract base class to implement gateway commands (chatbot and ad-hoc)
- Parameters:
xmpp (slidge.core.gateway.BaseGateway) –
- HELP = 'Change the contact_name of a signal contact. This is stored on your signal account only.'[source]#
- async run(session, ifrom, *args)[source]#
Entry point of the command
- Parameters:
session – If triggered by a registered user, its slidge Session
ifrom (slixmpp.JID) – JID of the command-triggering entity
args – When triggered via chatbot type message, additional words after the CHAT_COMMAND string was passed
- Returns:
Either a TableResult, a Form, a Confirmation, a text, or None
- async finish(form_values, session, _ifrom)[source]#
- Parameters:
session (slidge.plugins.signal.session.Session) –
- class slidge.plugins.signal.gateway.Gateway[source]#
Bases:
slidge.BaseGateway
Must be subclassed by a plugin to set up various aspects of the XMPP component behaviour, such as its display name or its registration process.
On slidge launch, a singleton is instantiated, and it will be made available to public classes such
LegacyContact
orBaseSession
as the.xmpp
attribute. Since it inherits fromslixmpp.componentxmpp.ComponentXMPP
, this gives you a hand on low-level XMPP interactions via slixmpp plugins, e.g.:self.send_presence( pfrom="somebody@component.example.com", pto="someonwelse@anotherexample.com", )
However, you should not need to do so often since the classes of the plugin API provides higher level abstractions around most commonly needed use-cases, such as sending messages, or displaying a custom status.
- signal: asyncio.Future[Signal][source]#
- sessions_by_phone: dict[str, slidge.plugins.signal.session.Session][source]#
- async connect_signal(socket)[source]#
Establish connection to the signald socker
- Parameters:
socket (pathlib.Path) –
- async validate(user_jid, registration_form)[source]#
Validate a registration form from a user.
Since XEP-0077 is pretty limited in terms of validation, it is OK to validate anything that looks good here and continue the legacy auth process via direct messages to the user (using
BaseGateway.input()
for instance).- Parameters:
user_jid (slixmpp.JID) – JID of the user that has just registered
registration_form (dict[str, Optional[str]]) – A dict where keys are the
FormField.var
attributes of theBaseGateway.REGISTRATION_FIELDS
iterable
- async validate_two_factor_code(user, code)[source]#
Called when the user enters their 2FA code.
Should raise the appropriate
XMPPError
if the login fails- Parameters:
user (slidge.GatewayUser) – The gateway user whose registration is pending Use their
.bare_jid
and/or``.registration_form`` attributes to get what you needcode (str) – The code they entered, either via “chatbot” message or adhoc command
- async unregister(user)[source]#
Optionally override this if you need to clean additional stuff after a user has been removed from the permanent user_store.
You may need to manually logout the legacy session in here,
Session.logout()
will not be called automatically.- Parameters:
user (slidge.GatewayUser) –
- class slidge.plugins.signal.gateway.Signal(xmpp)[source]#
Bases:
aiosignald.SignaldAPI
Extends
SignaldAPI
with handlers for events we are interested in.- Parameters:
on_con_lost – its result will be set to True once the connection is lost If not given, will be automatically generated.
xmpp (Gateway) –
- async handle_WebSocketConnectionState(state, payload)[source]#
We should not care much about this since
- Parameters:
payload –
- async handle_ListenerState(state, payload)[source]#
Deprecated in signald and replaced by WebSocketConnectionState Just here to avoid cluttering logs with unhandled events warnings
- Parameters:
state (aiosignald.generated.ListenerStatev1) –
payload –
- async handle_IncomingMessage(msg, _payload)[source]#
Dispatch a signald message to the proper session.
Can be a lot of other things than an actual message, still need to figure things out to cover all cases.
- Parameters:
msg (aiosignald.generated.IncomingMessagev1) – the data!
_payload –