Suas regras de sessão decidem quem pode se inscrever.

Não há modelo de permissão para configurar no Bird. Uma inscrição privada ou de presença é aprovada por um endpoint que você escreve, usando a sessão que você já tem, e assinada com um segredo que só os seus servidores possuem. Bird verifica a assinatura; você decide a política.

Comece agora Fale com vendas

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 },
      }),
    }),
  );
});

Uma chave é pública. A outra não.

Tudo decorre dessa separação.

Cada app no Bird Realtime API tem uma chave e um segredo. A chave é feita para ser incluída no código do cliente; o segredo autentica as chamadas do seu servidor e assina inscrições, e ele é exibido uma única vez, na criação. Qualquer pessoa que o possua pode publicar no seu app e forjar uma identidade de presença, então trate-o como uma senha de banco de dados. A rotação é aditiva e não disruptiva: crie uma segunda chave, faça o deploy e depois revogue a antiga.

Quatro controles, quatro perguntas

Quem pode se inscrever, quem pode manter uma conexão, quem pode ler um payload e quem ainda tem permissão.

01
Inscrições assinadas.
O cliente envia o id de conexão e o nome do canal para o seu endpoint. Você verifica quem chamou, recusa com um 403 se não puder entrar, ou retorna uma assinatura HMAC-SHA256 sobre o id de conexão e o nome do canal, prefixada com a chave do app. Como o id de conexão está na assinatura, uma aprovação cobre uma única conexão e não pode ser reproduzida em outra. Um canal de presença também assina a identidade do membro, e ela deve ser exatamente a string que você retorna: resserializar o mesmo objeto pode reordenar chaves e invalidar a assinatura.
02
Conexões autorizadas.
A chave do app é pública, então qualquer pessoa que consiga carregar sua página pode abrir um socket com ela. Ative conexões autorizadas e cada nova conexão terá 30 segundos para provar que algo com o segredo a autorizou, por meio de uma inscrição privada ou um sign-in. Conexões que não provarem são encerradas com o código 4009, e conexões não autorizadas nunca contam na sua cota. Inscrever-se em um canal público não prova nada e não autoriza uma conexão.
03
Criptografia de ponta a ponta.
Um canal private-encrypted- é selado pelo seu servidor antes que a solicitação saia do seu processo, com uma chave mestra de 32 bytes que nunca aparece em uma solicitação à Realtime API. Cada canal deriva sua própria chave, então autorizar um cliente em um canal criptografado não permite que ele leia outro. Bird não pode recuperar uma chave perdida, e a rotação protege payloads futuros, não os anteriores.
04
Revogando o acesso agora.
Um usuário deslogado, uma senha alterada, uma conta banida: desconecte o membro e cada conexão que essa identidade possui é encerrada, em todos os dispositivos. Os clientes tratam esse encerramento como definitivo em vez de tentar novamente, e seus próprios endpoints param de assinar para eles, então não podem voltar.

Canais criptografados

Payloads que Bird não consegue ler, em infraestrutura que Bird opera.

Leia o guia de criptografia

O SDK do servidor detecta o prefixo do canal, deriva a chave daquele canal a partir da sua chave mestra e sela o payload localmente. O edge encaminha o texto cifrado e seu endpoint de autorização entrega a chave derivada apenas aos clientes que aprovar. Dois limites para considerar no design: nomes de canal e evento trafegam em texto aberto, então escolha nomes que não revelem o que você está protegendo, e a criptografia não pode ser combinada com presença ou com eventos do cliente. O cache funciona: um canal private-encrypted-cache- armazena seu evento em cache já selado.

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" },
});

O que a autorização não faz.

Exigir conexões autorizadas controla quem pode manter um socket aberto. Isso não muda quem pode ler um canal: um canal público continua legível por toda conexão autorizada, então eventos que pertencem a um cliente devem ficar em um canal privado cujo nome seu endpoint verifica. E como seus endpoints são a autoridade, um endpoint permissivo distribui acesso tão livremente quanto uma chave vazada faria. A mesma honestidade se aplica a eventos do cliente, que o edge não valida: use-os para sinais e encaminhe qualquer coisa autoritativa pelo seu servidor.

Onde os dados ficam.

Um app escolhe sua região quando você o cria e a mantém para sempre, então escolha a mais próxima dos seus usuários. A região de um app pode ser diferente da região base do seu espaço de trabalho. Apps também são o limite de isolamento: dois apps nunca veem os canais um do outro, e é isso que faz um app por ambiente ser a forma certa de manter o tráfego de staging fora da produção.

Aprofunde-se na documentação.

Autorizando canais traz o contrato de solicitação e resposta e a string exata a assinar. Exigindo conexões autorizadas cobre a janela de 30 segundos e o código 4009, canais criptografados cobre geração e rotação de chaves, e encerrando conexões de membros é o fluxo de sign-in e desconexão.

O restante do Realtime

Um app, um par de chaves. Explore as outras funcionalidades.

CanaisPúblico, privado, presença, criptografado e em cache, todos definidos pelo nome.PresençaQuem está na sala, quem acabou de sair e como alcançar uma pessoa diretamente.WebhooksSeu servidor é notificado quando um canal enche, esvazia ou perde seu cache.PreçosConexões e mensagens por plano, do nível gratuito em diante.Primeiros passosDo cadastro ao seu primeiro evento publicado.Visão geral do Realtime APIO produto completo: canais, presença, segurança, webhooks e os clientes.

Escale sem
perder o controle.

Organize equipes em espaços de trabalho, controle o acesso à API e rastreie alterações nos logs de auditoria.

HarborOrganização

Espaços de trabalhoProduçãoSandbox

Agente de envio

Chave de API · Equipe de operações do cliente

Ativo

PermissõesAcesso

EmailLeitura e escrita

SMSLeitura e escrita

ALAlex Lee AdministradorPermissões atualizadas

Registo de auditoria

Produção

Espaço de trabalho: Produção
Recurso: Agente de envio
WhatsApp: Acesso de leituraLeitura e escrita

Concluído com sucesso

Explore o Enterprise

Comece com Realtime.
Construa em vários canais com a Bird.