Vos règles de session décident qui peut s'abonner.

Il n'y a pas de modèle de permissions à configurer dans Bird. Un abonnement privé ou de présence est approuvé par un endpoint que vous écrivez, à partir de la session que vous possédez déjà, et signé avec un secret que seuls vos serveurs détiennent. Bird vérifie la signature ; vous décidez de la politique.

Commencer Contacter l’équipe commerciale

auth.ts

200 · signed

// Your endpoint. The only place the app secret lives.
app.post("/bird/auth", async (req, res) => {
  const { connection_id, channel_name } = req.body;
  const user = await session(req);

  if (!mayJoin(user, channel_name)) return res.sendStatus(403);

  // Signs <connection_id>:<channel_name>[:<member_data>] with the app
  // secret, and adds shared_secret on an encrypted channel.
  res.json(
    await bird.realtime.authorizeChannel({
      connectionId: connection_id,
      channelName: channel_name,
      memberData: JSON.stringify({
        member_id: user.id,
        member_info: { name: user.name },
      }),
    }),
  );
});

auth.ts

200 · signed

// Your endpoint. The only place the app secret lives.
app.post("/bird/auth", async (req, res) => {
  const { connection_id, channel_name } = req.body;
  const user = await session(req);

  if (!mayJoin(user, channel_name)) return res.sendStatus(403);

  // Signs <connection_id>:<channel_name>[:<member_data>] with the app
  // secret, and adds shared_secret on an encrypted channel.
  res.json(
    await bird.realtime.authorizeChannel({
      connectionId: connection_id,
      channelName: channel_name,
      memberData: JSON.stringify({
        member_id: user.id,
        member_info: { name: user.name },
      }),
    }),
  );
});

Une clé est publique. L'autre non.

Tout découle de cette séparation.

Chaque application sur le Bird Realtime API possède une clé et un secret. La clé est destinée à être intégrée dans le code client ; le secret authentifie les appels de votre serveur et signe les abonnements, et il n'est affiché qu'une seule fois, à la création. Quiconque le détient peut publier dans votre application et usurper une identité de présence : traitez-le comme un mot de passe de base de données. La rotation est additive plutôt que perturbatrice : créez une deuxième clé, déployez-la, puis révoquez l'ancienne.

Quatre contrôles, quatre questions

Qui peut s'abonner, qui peut maintenir une connexion, qui peut lire un payload, et qui est encore autorisé.

01
Abonnements signés.
Le client envoie son identifiant de connexion et le nom du canal à votre endpoint. Vous vérifiez l'appelant, refusez avec un 403 s'il ne peut pas rejoindre, ou renvoyez une signature HMAC-SHA256 sur l'identifiant de connexion et le nom du canal, préfixée par la clé de l'application. Comme l'identifiant de connexion fait partie de la signature, une approbation couvre une seule connexion et ne peut pas être rejouée sur une autre. Un canal de présence signe aussi l'identité du membre, et ce doit être exactement la chaîne que vous renvoyez : resérialiser le même objet peut réordonner les clés et invalider la signature.
02
Connexions autorisées.
La clé de l'application est publique, donc quiconque peut charger votre page peut ouvrir un socket avec elle. Activez les connexions autorisées et chaque nouvelle connexion dispose de 30 secondes pour prouver qu'un détenteur du secret s'est porté garant, via un abonnement privé ou une connexion signée. Toute connexion qui ne le fait pas est fermée avec le code 4009, et les connexions non autorisées ne comptent jamais dans votre quota. S'abonner à un canal public ne prouve rien et n'autorise pas une connexion.
03
Chiffrement de bout en bout.
Un canal private-encrypted- est scellé par votre serveur avant que la requête ne quitte votre processus, avec une clé maître de 32 octets qui n'apparaît jamais dans une requête Realtime API. Chaque canal dérive sa propre clé, donc autoriser un client sur un canal chiffré ne lui permet pas de lire un autre canal. Bird ne peut pas récupérer une clé perdue, et la rotation protège les payloads futurs, pas les passés.
04
Révoquer l'accès immédiatement.
Un utilisateur déconnecté, un mot de passe modifié, un compte banni : déconnectez le membre et chaque connexion associée à cette identité se ferme, sur tous les appareils. Les clients traitent cette fermeture comme définitive au lieu de réessayer, et vos propres endpoints cessent de signer pour eux, donc ils ne peuvent pas revenir.

Canaux chiffrés

Des payloads que Bird ne peut pas lire, sur une infrastructure que Bird exploite.

Lire le guide du chiffrement

Le SDK serveur détecte le préfixe du canal, dérive la clé de ce canal à partir de votre clé maître et scelle le payload localement. L'edge transmet le texte chiffré et votre endpoint d'autorisation remet la clé dérivée uniquement aux clients qu'il approuve. Deux limites à prendre en compte : les noms de canaux et d'événements circulent en clair, donc choisissez des noms qui ne révèlent pas ce que vous protégez, et le chiffrement ne peut pas être combiné avec la présence ou les événements client. La mise en cache reste possible : un canal private-encrypted-cache- stocke son événement mis en cache sous forme scellée.

encrypted.ts

sealed locally

const bird = new BirdClient({
  apiKey: process.env.BIRD_API_KEY!,
  realtime: {
    key: process.env.BIRD_REALTIME_KEY,
    secret: process.env.BIRD_REALTIME_SECRET,
    // 32 random bytes, yours alone. Never sent to Bird.
    encryptionMasterKey: process.env.BIRD_REALTIME_MASTER_KEY,
  },
});

// Sealed in your process. The edge forwards ciphertext.
await bird.realtime.publish(APP_ID, {
  event: "order.updated",
  channels: ["private-encrypted-orders"],
  data: { order_id: "ord_123", status: "shipped" },
});

Ce que l'autorisation ne fait pas.

Exiger des connexions autorisées contrôle qui peut maintenir un socket ouvert. Cela ne change pas qui peut lire un canal : un canal public reste lisible par toute connexion autorisée, donc les événements destinés à un seul client doivent être placés sur un canal privé dont votre endpoint vérifie le nom. Et puisque vos endpoints font autorité, un endpoint permissif distribue l'accès aussi librement qu'une clé divulguée. La même rigueur s'applique aux événements client, que l'edge ne valide pas : utilisez-les pour des signaux, et faites transiter tout ce qui fait autorité par votre serveur.

Où se trouvent les données.

Une application choisit sa région à la création et la conserve définitivement, vous sélectionnez donc celle la plus proche de vos utilisateurs, et la région d'une application peut différer de la région d'origine de votre espace de travail. Les applications sont aussi la frontière d'isolation : deux applications ne voient jamais les canaux l'une de l'autre, c'est pourquoi une application par environnement est la bonne approche pour isoler le trafic de staging de la production.

Approfondir dans la documentation.

Autoriser les canaux décrit le contrat requête-réponse et la chaîne exacte à signer. Exiger des connexions autorisées couvre la fenêtre de 30 secondes et le code 4009, les canaux chiffrés couvrent la génération et la rotation des clés, et terminer les connexions d'un membre décrit le flux de connexion et de déconnexion.

Le reste de Realtime

Une application, une paire de clés. Explorez les autres fonctionnalités.

CanauxPublic, privé, présence, chiffré et mis en cache, tous sélectionnés par le nom.PrésenceQui est dans la salle, qui vient de partir, et comment joindre une personne directement.WebhooksVotre serveur est notifié quand un canal se remplit, se vide ou manque son cache.TarifsConnexions et messages par forfait, à partir du niveau gratuit.Premiers pasDe l'inscription à votre premier événement publié.Vue d'ensemble de Realtime APILe produit complet : canaux, présence, sécurité, webhooks et les clients.

Évoluez sans
perdre le contrôle.

Organisez vos équipes en espaces de travail, contrôlez l'accès à l'API et tracez les modifications via les journaux d'audit.

HarborOrganisation

Espaces de travailProductionBac à sable

Agent d’envoi

Clé API · Équipe Opérations clients

Actif

AutorisationsAccès

EmailLecture et écriture

SMSLecture et écriture

ALAlex Lee AdministrateurAutorisations mises à jour

Journal d'audit

Production

Espace de travail: Production
Ressource: Agent d’envoi
WhatsApp: Accès en lectureLecture et écriture

Réussi

Découvrez Enterprise

Commencez avec Realtime.
Développez sur tous les canaux avec Bird.