BroadcastChannel : messages same-origin et limites de confidentialité
Coordonnez des contextes navigateur de même origine avec BroadcastChannel en gardant des replis et des limites de cycle de vie.
BotBrowser Team
Vous voulez la documentation structurée pour Plateforme ?
Cet article fait partie de la bibliothèque éditoriale. Pour les étapes de configuration, la référence et les mises à jour continues, passez directement à la section docs.
BroadcastChannel permet à des onglets, fenêtres, workers ou cadres de même origine d'échanger une notification courte. Ce n'est ni un bus général, ni un signal d'authentification, ni une preuve qu'un même utilisateur possède deux contextes. La livraison dépend du modèle d'origine du navigateur et un message manquant ou tardif a de nombreuses causes normales. BotBrowser peut rejouer une fixture autorisée de même origine et consigner les résultats visibles de livraison, fermeture et réouverture, mais ne peut pas livrer entre origines, assouplir la politique same-origin ni garantir le timing entre versions.
TL;DR
- Utilisez BroadcastChannel pour coordonner des contextes de même origine.
- Fermez les canaux à la fin et traitez rechargement, suspension et fermeture comme des états normaux.
- Détectez l'API et gardez un repli comme
storage, un worker ou une actualisation serveur. - Une portée same-origin ne prouve ni authentification, ni identité, ni localisation, ni confiance.
- BotBrowser rejoue des fixtures autorisées, sans traverser les origines ni garantir le timing.
Sommaire
- Ce que fournit BroadcastChannel
- Limites d'origine et de confidentialité
- Cycle de vie et repli
- Tests avec BotBrowser
- Conclusion
Ce que fournit BroadcastChannel
new BroadcastChannel(name) crée un canal pour l'origine et le groupe de contexte courants. postMessage() utilise structured clone pour les autres contextes éligibles ayant le même nom. L'émetteur ne reçoit pas son propre message. Le canal ne fournit ni file durable ni accusé de livraison.
Choisissez un nom stable et une charge courte, par exemple {version: 3, type: 'cart-changed', key: 'cart'}. N'y placez pas de jetons, de dossiers complets ou de texte privé. Le canal doit inviter à relire un état autoritaire, pas remplacer une transaction. Écrivez d'abord l'état, puis publiez l'avis, et retirez les écouteurs avant close().
La livraison est au mieux. Un contexte peut être fermé, gelé ou créé après l'envoi. Une valeur non clonable peut aussi échouer. Un handler doit tolérer les doublons et les événements anciens en comparant une révision avant de modifier l'interface.
Limites d'origine et de confidentialité
Le navigateur compare schéma, hôte et port. Deux sous-domaines ou ports distincts ne partagent pas le canal, même sous la même organisation. Un cadre sandbox peut recevoir une origine opaque, et une partition de stockage peut modifier l'éligibilité.
La portée same-origin n'établit pas une identité. Un message absent ne prouve pas un défaut d'isolation : vérifiez origine, nom, moment d'inscription, cycle de vie et clonabilité. Consultez la section web messaging de WHATWG, le guide MDN BroadcastChannel et la politique same-origin.
Conservez les noms et charges loin des comptes, paiements et localisations précises. Un événement draft-updated ne dit ni qui a écrit, ni où, ni quel appareil fait autorité. Les principes de confidentialité du W3C soutiennent la limitation des finalités et la minimisation.
Cycle de vie et repli
Commencez par une base fonctionnelle sans l'API. Détectez BroadcastChannel, créez-le au besoin et gardez la page utilisable si la construction échoue. storage, un worker partagé ou une actualisation serveur peuvent servir de replis différents, avec des garanties différentes.
À la navigation, fermez l'ancien canal. Après rechargement, relisez l'état avant d'attendre un avis. Au retour d'une page cachée, actualisez si la donnée est importante. Débouclez les rafales, bornez la file et gardez un contrôle de reprise. Testez API absente, mauvais nom, mauvaise origine, fermeture, récepteur tardif, erreur de clone, suspension et terminaison.
Tests avec BotBrowser
BotBrowser permet d'exécuter une fixture autorisée multi-contexte de même origine, d'enregistrer les livraisons visibles et les résultats de fermeture ou réouverture, puis de comparer des versions déclarées. Il ne peut pas livrer entre origines, contourner la politique same-origin, garantir le timing entre versions ni faire de la portée du canal une preuve d'identité. Utilisez des données synthétiques et conservez une trace bornée du navigateur, de l'origine de test, de l'état du listener et du repli.
Conclusion
BroadcastChannel est une indication de coordination pour des contextes de même origine. Gardez l'état autoritaire dans un stockage validé, fermez les canaux lors des transitions, rendez les handlers idempotents et fournissez un repli de première classe. BotBrowser rend la comparaison autorisée répétable, tandis que l'origine, l'autorisation, le cycle de vie et la confidentialité restent sous la responsabilité des systèmes concernés.
À lire aussi
- Recherche sur la confidentialité avec des spécifications publiques
- Prise en charge et qualité des fonctions navigateur
- Fixtures d'automatisation et isolation
Sources
Articles Connexes
Faites passer BotBrowser de la recherche à la production
Utilisez ces guides pour comprendre le modèle, puis passez à la validation multi-plateforme, aux contextes isolés et au déploiement navigateur prêt pour l'échelle.