Segurança em tempo real

As suas regras de sessão decidem quem pode subscrever.

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

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 aplicação na 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 subscrições, e é mostrado uma vez, na criação. Qualquer pessoa que o tenha pode publicar na sua aplicação e forjar uma identidade de presença, por isso trate-o como uma palavra-passe de base de dados. A rotação é aditiva e não disruptiva: crie uma segunda chave, implemente-a e depois revogue a antiga.

Quatro controlos, quatro perguntas

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

01
Subscrições assinadas.
O cliente envia o id da conexão e o nome do canal para o seu endpoint. Você verifica o autor da chamada, recusa com um 403 se não puder participar, ou devolve uma assinatura HMAC-SHA256 sobre o id da conexão e o nome do canal, prefixada com a chave da aplicação. Como o id da conexão está na assinatura, uma aprovação cobre uma conexão e não pode ser reproduzida noutra. Um canal de presença também assina a identidade do membro, e tem de ser exatamente a string que você devolve: re-serializar o mesmo objeto pode reordenar chaves e invalidar a assinatura.
02
Conexões autorizadas.
A chave da aplicação é pública, por isso qualquer pessoa que consiga carregar a sua página pode abrir um socket com ela. Ative conexões autorizadas e cada nova conexão tem 30 segundos para provar que algo com o segredo a validou, através de uma subscrição privada ou um sign-in. Qualquer conexão que não o faça é encerrada com o código 4009, e conexões não autorizadas nunca contam para a sua quota. Subscrever um canal público não prova nada e não autoriza uma conexão.
03
Encriptação ponta a ponta.
Um canal private-encrypted- é selado pelo seu servidor antes de o pedido sair do seu processo, com uma chave mestra de 32 bytes que nunca aparece num pedido à Realtime API. Cada canal deriva a sua própria chave, por isso autorizar um cliente para um canal encriptado não lhe permite ler outro. Bird não consegue recuperar uma chave perdida, e a rotação protege payloads futuros em vez dos passados.
04
Revogar o acesso agora.
Um utilizador que fez logout, uma palavra-passe alterada, uma conta banida: desconecte o membro e todas as conexões dessa identidade são encerradas, em todos os dispositivos. Os clientes tratam esse encerramento como terminal em vez de retentar, e os seus próprios endpoints deixam de assinar por eles, por isso não conseguem voltar.

Canais encriptados

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

Leia o guia de encriptação

O SDK do servidor deteta o prefixo do canal, deriva a chave desse canal a partir da sua chave mestra e sela o payload localmente. O edge reencaminha o texto cifrado e o seu endpoint de autorização entrega a chave derivada apenas aos clientes que aprova. Dois limites a ter em conta no design: os nomes dos canais e dos eventos viajam em texto aberto, por isso escolha nomes que não revelem o que está a proteger, e a encriptação não pode ser combinada com presença ou com eventos do cliente. O caching pode ser: um canal private-encrypted-cache- armazena o seu evento em cache 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. Não altera quem pode ler um canal: um canal público continua legível por todas as conexões autorizadas, por isso eventos que pertencem a um cliente devem estar num canal privado cujo nome o seu endpoint verifica. E como os seus endpoints são a autoridade, um endpoint permissivo distribui acesso tão livremente como uma chave comprometida. A mesma honestidade aplica-se aos eventos do cliente, que o edge não valida: use-os para sinais e encaminhe tudo o que é autoritativo pelo seu servidor.

Onde os dados residem.

Uma aplicação escolhe a sua região quando a cria e mantém-na para sempre, para que escolha a mais próxima dos seus utilizadores, e a região de uma aplicação pode diferir da região principal do seu workspace. As aplicações são também o limite de isolamento: duas aplicações nunca veem os canais uma da outra, o que torna uma aplicação por ambiente a forma correta de manter o tráfego de staging fora da produção.

Aprofunde na documentação.

Autorizar canais tem o contrato de pedido e resposta e a string exata a assinar. Exigir conexões autorizadas cobre a janela de 30 segundos e o código 4009, canais encriptados cobre a geração e rotação de chaves, e terminar conexões de membros é o fluxo de sign-in e desconexão.