Sessions, mots de passe, relais et modes serveur

Le modèle de connexion

Une source capture un message ou un événement et le publie dans une session Social Stream.
Le dock, l’incrustation Featured, Multi Alerts, Event Flow et d’autres pages rejoignent cette même session.
Si un mot de passe est défini, toutes les pages qui rejoignent la session doivent utiliser le même.
Si le routage par serveur est activé, les pages actives doivent utiliser les URL nouvellement générées avec les paramètres de routage correspondants.

Source → same session ID + password + routing mode → Dock / overlay / API consumer

Identifiant de session et mot de passe

Ouvrir Paramètres et outils globaux → Options de session (Global settings and tools → Session Options) pour consulter l’identifiant de session actuel et définir un mot de passe facultatif.

Options de session Social Stream Ninja affichant le champ d’identifiant de session, le mot de passe facultatif et le contrôle Masquer vos liens — Utilisez une valeur fictive dans la documentation et les captures d’écran. Ne publiez jamais un véritable mot de passe de session ni un lien généré privé.

Valeur	Règle
Identifiant de session	Ne le modifiez que si vous souhaitez remplacer toutes les URL de sources, docks, incrustations et intégrations qui l’utilisent.
Mot de passe	Facultatif, mais doit correspondre partout une fois défini. Copiez les liens nouvellement générés après tout ajout ou changement.
Lien généré	Considérez tout le lien comme privé lorsqu’il contient un mot de passe ou d’autres paramètres sensibles.

Privilégiez la copie des URL générées. Ils comprennent déjà la session actuelle, le mot de passe, la version de la page et les options de routage prises en charge. Les liens modifiés à la main sont une cause fréquente de pages vides.

Activer le repli par serveur pour lire et répondre

Utilisez cette méthode lorsque le dock ou le chat unifié se connecte mais ne reçoit aucun message, ou lorsque les réponses échouent parce que le chemin pair-à-pair habituel est bloqué ou peu fiable.

Les deux contrôles de repli fonctionnent ensemble : Envoyer les messages du chat au serveur API pour les clients externes à l’écoute (Send chat messages to API server (for external listeners)) achemine le chat entrant vers le serveur, tandis que Le Dock envoie ses commandes à l'extension via le serveur ramène les réponses et les commandes du dock.

Méthode rapide

Ouvrez ou rechargez le lien du dock généré.
Envoyez un faux message de test depuis Social Stream Ninja.
Si l’avis Activer le repli serveur apparaît, sélectionnez-le et confirmez. Social Stream Ninja active ensemble les chemins serveur du chat entrant et des commandes de réponse.
Copiez les nouveaux liens du dock et des incrustations. Rouvrez les fenêtres de navigateur ordinaires et remplacez les URL des sources Navigateur enregistrées dans OBS.

Méthode manuelle dans l’application de bureau

Ouvrez l’application de bureau Social Stream. Dans le panneau de droite Sources et paramètres , développez Paramètres et outils globaux.
Développez Mécanismes - Connexions et intégrations (Mechanics - Connections & Integrations).
Activez Envoyer les messages du chat au serveur API pour les clients externes à l’écoute (Send chat messages to API server (for external listeners)). C’est le chemin de réception/lecture du chat.
Activez Le Dock envoie ses commandes à l'extension via le serveur. C’est le chemin des réponses/commandes.
Copiez et rouvrez les liens nouvellement générés. Les anciennes pages ouvertes et les URL enregistrées dans OBS ne se mettent pas à jour automatiquement.

Contrôles Mechanics de Social Stream Ninja affichant l’envoi des messages au serveur API et les commandes du dock via le serveur — Pour le repli normal permettant de lire et répondre, activez l’option du chat entrant et celle des commandes du dock. Les autres contrôles de serveur correspondent à des fonctions distinctes.

N’activez pas toutes les options de serveur. Activer le contrôle distant par API, Autoriser le Dock à utiliser et publier via le serveur API (Enable Dock to use and publish via API server), ainsi que l’option temporaire d’envoi supplémentaire, ne sont pas nécessaires au repli normal pour lire et répondre. L’envoi supplémentaire peut produire des messages en double.

Modes par défaut, relais et serveur API

Contrôle	Effet	Quand l'utiliser
Liens par défaut	Transport pair/session Social Stream normal, sans ajout de paramètre de serveur.	La plupart des installations sur un seul ordinateur et des configurations OBS classiques.
Activer le contrôle distant de l’extension par API	Active le contrôle HTTP/WebSocket de l’extension et le traitement des webhooks entrants.	Applications externes, contrôle par Stream Deck/API ou webhooks de dons entrants pris en charge.
Autoriser le Dock à utiliser et publier via le serveur API (Enable Dock to use and publish via API server)	Ajoute à la page `server` comme routage lorsque c’est pris en charge.	Le fonctionnement du dock/Featured nécessite le contrôle distant par serveur API à la place du chemin habituel.
Envoyer les messages de chat au serveur API	Achemine le chat capturé vers les clients à l’écoute du serveur API et ajoute `server2` aux liens générés pris en charge.	Le dock a besoin du repli par serveur pour le chat entrant, ou un client WebSocket externe en Python, Node ou autre doit recevoir le chat.
Envoyer aussi normalement les messages routés via l’API	Envoi supplémentaire temporaire par les deux chemins.	Uniquement pendant une transition volontaire entre plusieurs modes ; peut produire des doublons.
Commandes du dock via le serveur (Dock commands via server)	Ajoute `server3` lorsque c’est pris en charge, pour que les commandes du dock reviennent par le serveur.	Les connexions entre pairs sont bloquées ou peu fiables et les commandes du dock vers l’extension nécessitent le serveur.

Contrôles Mechanics globaux de Social Stream Ninja pour le contrôle distant par API, la publication du dock sur le serveur API, les clients externes à l’écoute du chat, l’envoi supplémentaire et les commandes du dock via le serveur — Les contrôles de routage actuels. Modifier une option de lien généré ne réécrit ni une page déjà ouverte ni une source Navigateur enregistrée dans OBS.

À propos `localserver`

Certaines pages acceptent localserver et utilisent un point d’accès WebSocket local à ws://127.0.0.1:3000. Ajoutez localserverport=PORT pour choisir un autre port entre 1024 et 65535. Les valeurs invalides ou absentes utilisent sans risque le port 3000. Les nouvelles installations de l’application de bureau Social Stream exécutent leur serveur local sur le port 3003 et ajoutent localserverport=3003 dans les liens qu’elles génèrent ; si vous écrivez une URL à la main pour une nouvelle installation, ajoutez donc ce paramètre vous-même. N’ajoutez ces paramètres que si le serveur local fonctionne effectivement et si la page précise les prend en charge.

Pour des captures d’écran et la configuration détaillée du WebSocket hébergé ou du serveur local avancé, consultez Modes WebSocket hébergé et serveur local.

Les paramètres de routage dépendent de la page. server, server2, server3, localserver, et localserverport n’ont pas un comportement universel sur toutes les incrustations. Utilisez l’URL générée pour la page exacte au lieu de copier les paramètres d’un autre outil.

Après une modification de session ou d’option de routage

Copiez la nouvelle URL du dock ou de l’incrustation.
Fermez puis rouvrez les pages de navigateur actives qui utilisent l’ancienne URL.
Remplacez l’URL des sources Navigateur enregistrées dans OBS et actualisez leur cache.
Rechargez ou réactivez les pages sources si l’identifiant de session ou le mot de passe a changé.
Envoyez un faux message de test et vérifiez qu’il arrive au dock avant de tester l’incrustation finale.

Vérifications en cas de dock ou d’incrustation vide

Comparez la valeur complète de session= sur la source, le dock et l’incrustation.
Vérifiez si une URL ne contient pas le paramètre actuel password=.
Vérifiez si une ancienne URL OBS ne contient pas les paramètres actuels de routage par serveur.
Si les modes ne sont pas clairs, supprimez les paramètres de routage ajoutés manuellement et copiez une nouvelle URL générée.
Testez d’abord le dock. S’il reçoit les messages, vérifiez ensuite les filtres d’événements et les options d’URL de l’incrustation.
Voir Dépannage OBS et le Référence des commandes et de l’API pour des vérifications plus approfondies.