Le tue regole di sessione decidono chi può sottoscriversi.
Non c'è un modello di permessi da configurare in Bird. Una sottoscrizione privata o di presenza viene approvata da un endpoint che scrivi tu, usando la sessione che hai già, e firmata con un segreto che solo i tuoi server possiedono. Bird verifica la firma; tu decidi la policy.
// 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 },
}),
}),
);
});
Una chiave è pubblica. L'altra no.
Tutto discende da questa separazione.
Ogni app sulla Bird Realtime API ha una chiave e un segreto. La chiave è pensata per essere inclusa nel codice client; il segreto autentica le chiamate del tuo server e firma le sottoscrizioni, e viene mostrato una sola volta, alla creazione. Chiunque lo possieda può pubblicare sulla tua app e falsificare un'identità di presenza, quindi trattalo come una password del database. La rotazione è additiva, non distruttiva: crea una seconda chiave, distribuiscila, poi revoca quella vecchia.
Quattro controlli, quattro domande
Chi può sottoscrivere, chi può mantenere una connessione, chi può leggere un payload e chi è ancora autorizzato.
- 01
Sottoscrizioni firmate.
Il client invia il proprio connection id e il nome del canale al tuo endpoint. Tu verifichi il chiamante, rispondi con un 403 se non può unirsi, oppure restituisci una firma HMAC-SHA256 su connection id e nome del canale, con prefisso la app key. Poiché il connection id è nella firma, un'approvazione copre una sola connessione e non può essere riprodotta su un'altra. Un canale di presenza firma anche l'identità del membro, che deve essere esattamente la stringa che restituisci: ri-serializzare lo stesso oggetto può riordinare le chiavi e invalidare la firma.
- 02
Connessioni autorizzate.
La app key è pubblica, quindi chiunque possa caricare la tua pagina può aprire un socket con essa. Attiva le connessioni autorizzate e ogni nuova connessione ha 30 secondi per dimostrare che qualcosa in possesso del segreto l'ha garantita, tramite una sottoscrizione privata o un sign-in. Qualsiasi connessione che non lo fa viene chiusa con codice 4009, e le connessioni non autorizzate non contano mai nella tua quota. Sottoscrivere un canale pubblico non dimostra nulla e non autorizza una connessione.
- 03
Crittografia end-to-end.
Un canale private-encrypted- è sigillato dal tuo server prima che la richiesta lasci il tuo processo, con una master key da 32 byte che non compare mai in una richiesta Realtime API. Ogni canale deriva la propria chiave, quindi autorizzare un client per un canale crittografato non gli consente di leggerne un altro. Bird non può recuperare una chiave persa, e la rotazione protegge i payload futuri, non quelli passati.
- 04
Revocare l'accesso adesso.
Un utente disconnesso, una password cambiata, un account bannato: disconnetti il membro e ogni connessione associata a quell'identità si chiude, su ogni dispositivo. I client trattano quella chiusura come definitiva e non riprovano, e i tuoi endpoint smettono di firmare per loro, quindi non possono tornare.
Canali crittografati
Payload che Bird non può leggere, su un'infrastruttura gestita da Bird.
L'SDK server riconosce il prefisso del canale, deriva la chiave di quel canale dalla tua master key e sigilla il payload localmente. L'edge inoltra il testo cifrato e il tuo endpoint di autorizzazione consegna la chiave derivata solo ai client che approva. Due limiti da considerare nel design: i nomi di canali ed eventi viaggiano in chiaro, quindi scegli nomi che non rivelino ciò che stai proteggendo, e la crittografia non può essere combinata con la presenza o con gli eventi client. Il caching è possibile: un canale private-encrypted-cache- memorizza il suo evento in cache sigillato.
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" },
});
Cosa non fa l'autorizzazione.
Richiedere connessioni autorizzate controlla chi può mantenere un socket aperto. Non cambia chi può leggere un canale: un canale pubblico resta leggibile da ogni connessione autorizzata, quindi gli eventi che appartengono a un cliente vanno su un canale privato il cui nome viene verificato dal tuo endpoint. E poiché i tuoi endpoint sono l'autorità, un endpoint permissivo concede accesso con la stessa libertà di una chiave trapelata. La stessa onestà si applica agli eventi client, che l'edge non valida: usali per segnali e instradi tutto ciò che è autorevole attraverso il tuo server.
Dove risiedono i dati.
Un'app sceglie la propria regione al momento della creazione e la mantiene per sempre, quindi scegli quella più vicina ai tuoi utenti; la regione di un'app può differire dalla regione di appartenenza del tuo spazio di lavoro. Le app sono anche il confine di isolamento: due app non vedono mai i canali l'una dell'altra, ed è per questo che un'app per ambiente è il modo giusto per tenere il traffico di staging fuori dalla produzione.
Approfondisci nella documentazione.
Autorizzazione dei canali contiene il contratto di richiesta e risposta e la stringa esatta da firmare. Richiedere connessioni autorizzate copre la finestra di 30 secondi e il codice 4009, canali crittografati copre la generazione e la rotazione delle chiavi, e terminare le connessioni dei membri è il flusso di sign-in e disconnessione.
Il resto di Realtime
Un'app, una coppia di chiavi. Esplora le altre funzionalità.
Scala senza
perdere il controllo.
Organizza i team in spazi di lavoro, controlla l'accesso alle API e traccia le modifiche tramite log di audit.
Registro di audit
Produzione- Workspace
- Produzione
- Risorsa
- Agente di invio
- Accesso in letturaLettura e scrittura