slidge_whatsapp.gateway#

Attributes#

Classes#

Gateway

The gateway component, handling registrations and un-registrations.

Module Contents#

slidge_whatsapp.gateway.REGISTRATION_INSTRUCTIONS = "Continue and scan the resulting QR codes on your main device, or alternatively, use the...[source]#
slidge_whatsapp.gateway.WELCOME_MESSAGE = "Thank you for registering! Please scan the following QR code on your main device or use the...[source]#
class slidge_whatsapp.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:

  • validate()

  • validate_two_factor_code()

  • get_qr_text()

  • confirm_qr()

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 = 'WhatsApp (slidge)'[source]#

Name of the component, as seen in service discovery by XMPP clients

COMPONENT_TYPE = 'whatsapp'[source]#

Type of the gateway, should follow https://xmpp.org/registrar/disco-categories.html

COMPONENT_AVATAR = 'https://www.whatsapp.com/apple-touch-icon.png'[source]#

Path, bytes or URL used by the component as an avatar.

ROSTER_GROUP = 'WhatsApp'[source]#

Name of the group assigned to a LegacyContact automagically added to the User’s roster with LegacyContact.add_to_roster().

REGISTRATION_INSTRUCTIONS[source]#

The text presented to a user that wants to register (or modify) their legacy account configuration.

WELCOME_MESSAGE[source]#

A welcome message displayed to users on registration. This is useful notably for clients that don’t consider component JIDs as a valid recipient in their UI, yet still open a functional chat window on incoming messages from components.

REGISTRATION_FIELDS = [][source]#

Iterable of fields presented to the gateway user when registering using XEP-0077 extended by XEP-0004.

SEARCH_FIELDS[source]#

Fields used for searching items via the component, through XEP-0055 (jabber search). A common use case is to allow users to search for legacy contacts by something else than their usernames, eg their phone number.

Plugins should implement search by overriding BaseSession.search() (restricted to registered users).

If there is only one field, it can also be used via the jabber:iq:gateway protocol described in XEP-0100. Limitation: this only works if the search request returns one result item, and if this item has a ‘jid’ var.

MARK_ALL_MESSAGES = True[source]#

Set this to True for legacy networks that expects read marks for all messages and not just the latest one that was read (as most XMPP clients will only send a read mark for the latest msg).

GROUPS = True[source]#
PROPER_RECEIPTS = True[source]#

Set this to True if the legacy service provides a real equivalent of message delivery receipts (XEP-0184), meaning that there is an event thrown when the actual device of a contact receives a message. Make sure to call Contact.received() adequately if this is set to True.

whatsapp[source]#
async validate(user_jid, registration_form)[source]#

Validate registration form. A no-op for WhatsApp, as actual registration takes place after in-band registration commands complete; see Session.login() for more.

async unregister(user)[source]#

Logout from the active WhatsApp session. This will also force a remote log-out, and thus require pairing on next login. For simply disconnecting the active session, look at the Session.disconnect() function.

Parameters:

user (slidge.GatewayUser) –

slidge_whatsapp.gateway.log[source]#