slidgnal.gateway#

Attributes#

log

Classes#

Link

Abstract base class to implement gateway commands (chatbot and ad-hoc)

LinkedDevices

Abstract base class to implement gateway commands (chatbot and ad-hoc)

UnlinkDevice

Abstract base class to implement gateway commands (chatbot and ad-hoc)

LinkDevice

Abstract base class to implement gateway commands (chatbot and ad-hoc)

ChangeContactName

Abstract base class to implement gateway commands (chatbot and ad-hoc)

DeleteAccount

Abstract base class to implement gateway commands (chatbot and ad-hoc)

Gateway

The gateway component, handling registrations and un-registrations.

Signal

Extends SignaldAPI with handlers for events we are interested in.

Functions#

Module Contents#

Bases: slidge.command.Command

Abstract base class to implement gateway commands (chatbot and ad-hoc)

Parameters:

xmpp (slidge.core.gateway.BaseGateway) –

NAME = 'Link your signal account to slidge'[source]#
HELP = "Use an existing signal account with slidge as a 'secondary device'. You will need to keep your...[source]#
ACCESS[source]#
PROPER_RECEIPTS = True[source]#
xmpp: Gateway[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 show_code(form_values, _session, ifrom)[source]#
Parameters:

form_values (dict) –

async finish(_form_values, _session, ifrom, session_id, phone, device)[source]#
class slidgnal.gateway.LinkedDevices(xmpp)[source]#

Bases: slidge.command.Command

Abstract base class to implement gateway commands (chatbot and ad-hoc)

Parameters:

xmpp (slidge.core.gateway.BaseGateway) –

NAME = 'List the devices linked to your signal account'[source]#
HELP = 'List all the devices that have access to your signal account'[source]#
ACCESS[source]#
xmpp: Gateway[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 slidgnal.gateway.UnlinkDevice(xmpp)[source]#

Bases: slidge.command.Command

Abstract base class to implement gateway commands (chatbot and ad-hoc)

Parameters:

xmpp (slidge.core.gateway.BaseGateway) –

NAME = 'Remove a linked device'[source]#
HELP = 'Remove a device from you signal account'[source]#
ACCESS[source]#
xmpp: Gateway[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, _jid)[source]#
Parameters:
class slidgnal.gateway.LinkDevice(xmpp)[source]#

Bases: slidge.command.Command

Abstract base class to implement gateway commands (chatbot and ad-hoc)

Parameters:

xmpp (slidge.core.gateway.BaseGateway) –

NAME = 'Link a new device to your signal account'[source]#
HELP = 'Use slidge to add a device to your signal account'[source]#
ACCESS[source]#
xmpp: Gateway[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 (slidgnal.session.Session) –

class slidgnal.gateway.ChangeContactName(xmpp)[source]#

Bases: slidge.command.Command

Abstract base class to implement gateway commands (chatbot and ad-hoc)

Parameters:

xmpp (slidge.core.gateway.BaseGateway) –

NAME = 'Rename a signal contact'[source]#
HELP = 'Change the contact_name of a signal contact. This is stored on your signal account only.'[source]#
ACCESS[source]#
xmpp: Gateway[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 (slidgnal.session.Session) –

class slidgnal.gateway.DeleteAccount(xmpp)[source]#

Bases: slidge.command.Command

Abstract base class to implement gateway commands (chatbot and ad-hoc)

Parameters:

xmpp (slidge.core.gateway.BaseGateway) –

NAME = 'Delete an account from signald'[source]#
HELP = 'This should only be done if there is a inconsistency between signald accounts slidge knows...[source]#
ACCESS[source]#
xmpp: Gateway[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 (slidgnal.session.Session) –

class slidgnal.gateway.Gateway[source]#

Bases: slidge.BaseGateway

The gateway component, handling registrations and un-registrations.

On slidge launch, a singleton is instantiated, and it will be made available to public classes such LegacyContact or BaseSession as the .xmpp attribute.

Must be subclassed by a legacy module to set up various aspects of the XMPP component behaviour, such as its display name or welcome message, via class attributes COMPONENT_NAME WELCOME_MESSAGE.

Abstract methods related to the registration process must be overriden for a functional Legacy Module:

NB: Not all of these must be overridden, it depends on the REGISTRATION_TYPE.

The other methods, such as send_text() or react() are the same as those of LegacyContact and LegacyParticipant, because the component itself is also a “messaging actor”, ie, an XMPP Entity. For these methods, you need to specify the JID of the recipient with the mto parameter.

Since it inherits from slixmpp.componentxmpp.ComponentXMPP,you also have a hand on low-level XMPP interactions via slixmpp methods, 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.

COMPONENT_NAME = 'Signal (slidge)'[source]#
COMPONENT_TYPE = 'signal'[source]#
COMPONENT_AVATAR = 'https://upload.wikimedia.org/wikipedia/commons/5/56/Logo_Signal..png'[source]#
REGISTRATION_INSTRUCTIONS[source]#
REGISTRATION_FIELDS[source]#
REGISTRATION_TYPE[source]#
ROSTER_GROUP = 'Signal'[source]#
SEARCH_FIELDS[source]#
signal: asyncio.Future[Signal][source]#
sessions_by_phone: dict[str, slidgnal.session.Session][source]#
GROUPS = True[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 user’s initial registration form.

Should raise the appropriate slixmpp.exceptions.XMPPError if the registration does not allow to continue the registration process.

If REGISTRATION_TYPE is a RegistrationType.SINGLE_STEP_FORM, this method should raise something if it wasn’t possible to successfully log in to the legacy service with the registration form content.

It is also used for other types of REGISTRATION_TYPE too, since the first step is always a form. If REGISTRATION_FIELDS is an empty list (ie, it declares no FormField), the “form” is effectively a confirmation dialog displaying REGISTRATION_INSTRUCTIONS.

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 the BaseGateway.REGISTRATION_FIELDS iterable. This dict can be modified and will be accessible as the legacy_module_data of the

:returnA dict that will be stored as the persistent “legacy_module_data”

for this user. If you don’t return anything here, the whole registration_form content will be stored.

async validate_two_factor_code(user, code)[source]#

Called when the user enters their 2FA code.

Should raise the appropriate slixmpp.exceptions.XMPPError if the login fails, and return successfully otherwise.

Only used when REGISTRATION_TYPE is RegistrationType.TWO_FACTOR_CODE.

Parameters:
  • user (slidge.GatewayUser) – The GatewayUser whose registration is pending Use their GatewayUser.bare_jid and/or registration_form attributes to get what you need.

  • code (str) – The code they entered, either via “chatbot” message or adhoc command

:returnA dict which keys and values will be added to the persistent “legacy_module_data”

for this user.

async unregister(user)[source]#

Optionally override this if you need to clean additional stuff after a user has been removed from the persistent user store.

By default, this just calls BaseSession.logout().

Parameters:

user (slidge.GatewayUser) –

class slidgnal.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) –

sessions_by_phone[source]#
async handle_WebSocketConnectionState(state, payload)[source]#

We should not care much about this since

Parameters:
async handle_ListenerState(state, payload)[source]#

Deprecated in signald and replaced by WebSocketConnectionState Just here to avoid cluttering logs with unhandled events warnings

Parameters:
static handle_StorageChange(event, _payload)[source]#
Async:

Parameters:

event (aiosignald.generated.StorageChangev1) –

static handle_InternalError(event, _payload)[source]#
Async:

Parameters:

event (aiosignald.exc.InternalError) –

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:
slidgnal.gateway.fmt_time(t)[source]#
Parameters:

t (Optional[float]) –

slidgnal.gateway.log[source]#