Compatibilité Jitsi (compat-jitsi)

Le module compat-jitsi rend Vuisio compatible avec l’écosystème Jitsi Meet. Une application qui intègre déjà Jitsi (Moodle, Rocket.Chat, Mattermost, Element…) peut pointer sur Vuisio en changeant simplement son nom de domaine et en réutilisant son identifiant et son secret d’application. Aucune modification de code n’est nécessaire côté application.

Contrairement à BigBlueButton, Jitsi n’a pas d’API REST de gestion de réunions. Une conférence est créée implicitement à la première arrivée, et les intégrations reposent sur deux choses : le script external_api.js (qui embarque une iframe) et un jeton JWT signé avec un secret partagé. Le module fournit exactement cette surface.

Installation

vuisio module add compat-jitsi

Disponible en runtime Docker comme en natif. Gratuit, aucun jeton d’accès requis.

Migrer depuis Jitsi

Deux réglages suffisent :

1. Dans votre application, remplacez le domaine Jitsi par celui de votre instance Vuisio (le premier argument de JitsiMeetExternalAPI, ou le domaine de vos liens https://<domaine>/<salle>).

2. Renseignez les mêmes identifiants d’application que ceux avec lesquels votre application signe déjà ses jetons Jitsi :

   • COMPAT_JITSI_APP_ID : l’identifiant d’application (le iss du JWT, votre ancien JWT_APP_ID) ;
   • COMPAT_JITSI_APP_SECRET : le secret partagé HS256 (votre ancien JWT_APP_SECRET).

Vos jetons existants sont alors acceptés tels quels : rien à re-signer.

Embarquer une réunion (External API)

Le module sert un external_api.js compatible. Le code d’intégration est identique à Jitsi :

<script src="https://votre-domaine/external_api.js"></script>
<script>
  const api = new JitsiMeetExternalAPI("votre-domaine", {
    roomName: "MaSalle",
    jwt: "<jeton signé par votre application>",
    parentNode: document.querySelector("#meet"),
  });

  // Commandes et évènements Jitsi habituels :
  api.executeCommand("toggleAudio");
  api.addListener("videoConferenceJoined", (e) => console.log(e.roomName));
</script>

Le shim injecte l’iframe, l’authentifie via le module, puis relaie les commandes et les évènements. Le sous-ensemble pris en charge couvre l’usage courant :

• Commandes : toggleAudio, toggleVideo, toggleShareScreen, hangup, sendChatMessage, setDisplayName.
• Évènements : videoConferenceJoined, videoConferenceLeft, readyToClose, participantJoined, participantLeft, audioMuteStatusChanged, videoMuteStatusChanged, screenSharingStatusChanged, dominantSpeakerChanged, incomingMessage, outgoingMessage.
• Accesseurs (promesses) : getNumberOfParticipants, getParticipantsInfo, isAudioMuted, isVideoMuted, getDisplayName, isSharingScreen.

Autoriser l’embarquement inter-domaine

Par défaut, le client web refuse d’être embarqué dans une iframe d’une autre origine (en-tête X-Frame-Options et CSP frame-ancestors 'self'). Pour qu’une application externe puisse l’embarquer, il faut lister explicitement ses origines (séparées par des espaces ou des virgules), par exemple https://mon-lms.example.edu.

L’installateur le demande à l’installation, à l’étape « Origins allowed to embed the web client » (laissée vide, la posture sécurisée par défaut reste inchangée). Pour le régler après coup, par exemple une fois compat-jitsi ajouté, relancez vuisio reconfigure : la valeur est mémorisée puis livrée au client web sous VUISIO_EMBED_ANCESTORS. En installation non interactive, renseignez embed_ancestors dans le fichier de réponses.

Le jeton JWT

Le module valide des jetons HS256 au format Jitsi. Sont vérifiés la signature, exp/nbf, la présence de sub, l’émetteur iss, l’audience aud et la salle room (* ou correspondance insensible à la casse). L’identité est lue dans context.user :

• context.user.name : le nom affiché ;
• context.user.moderator ("true"/"false" ou booléen) : détermine le rôle. Un participant marqué modérateur reçoit un jeton de rôle signé que le SFU vérifie, si bien qu’on ne peut pas se promouvoir en modifiant l’URL ;
• context.features.recording : autorise l’enregistrement de la salle.

Seul l’algorithme HS256 est accepté (l’en-tête alg est verrouillé : none et RS256 sont refusés).

Salles ouvertes (sans jeton)

Par défaut, un jeton valide est requis. Pour reproduire un Jitsi ouvert de type meet.jit.si, activez COMPAT_JITSI_ALLOW_ANONYMOUS : les arrivées sans jeton sont admises comme simples participants, et la première personne dans la salle en devient modératrice.

Configuration

Variable	Défaut	Rôle
COMPAT_JITSI_APP_ID	(vide)	Identifiant d’application (JWT iss).
COMPAT_JITSI_APP_SECRET	(requis)	Secret HS256 de validation des jetons.
COMPAT_JITSI_ACCEPTED_ISSUERS	= app_id	Émetteurs acceptés (liste, * = tous).
COMPAT_JITSI_ACCEPTED_AUDIENCES	jitsi	Audiences acceptées (liste, * = toutes).
COMPAT_JITSI_ALLOW_ANONYMOUS	false	Autoriser les arrivées sans jeton.
VUISIO_EMBED_ANCESTORS	(vide)	Origines autorisées à embarquer le client web.

Le secret et le domaine public sont renseignés à l’installation. L’option « salles ouvertes » est demandée à l’ajout du module.

Ce qui n’est pas fourni

Il n’y a pas d’API REST de gestion de réunions : Jitsi n’en expose pas, donc il n’y a rien à imiter côté serveur. Les jetons RS256 (offre cloud JaaS de 8x8) et la pile protocolaire XMPP/Prosody/Jicofo ne sont pas pris en charge : aucune intégration tierce ne les cible.