Twoje reguły sesji decydują, kto może subskrybować.

W Bird nie ma modelu uprawnień do konfiguracji. Subskrypcję prywatną lub obecnościową zatwierdza endpoint, który sam napiszesz, na podstawie sesji, którą już posiadasz, i podpisu złożonego sekretem dostępnym tylko Twoim serwerom. Bird weryfikuje podpis — Ty decydujesz o polityce.

Rozpocznij Skontaktuj się z działem sprzedaży

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

Jeden klucz jest publiczny. Drugi nie.

Wszystko wynika z tego podziału.

Każda aplikacja w Bird Realtime API ma klucz i sekret. Klucz jest przeznaczony do umieszczenia w kodzie klienta; sekret uwierzytelnia wywołania Twojego serwera i podpisuje subskrypcje — jest pokazywany tylko raz, przy tworzeniu. Każdy, kto go posiada, może publikować w Twojej aplikacji i podszywać się pod tożsamość obecnościową, więc traktuj go jak hasło do bazy danych. Rotacja jest addytywna, nie destrukcyjna: utwórz drugi klucz, wdróż go, a potem unieważnij stary.

Cztery mechanizmy, cztery pytania

Kto może subskrybować, kto może utrzymywać połączenie, kto może odczytać dane i kto wciąż ma dostęp.

01
Podpisane subskrypcje.
Klient wysyła identyfikator połączenia i nazwę kanału do Twojego endpointu. Sprawdzasz wywołującego, odrzucasz z kodem 403, jeśli nie ma prawa dołączyć, albo zwracasz podpis HMAC-SHA256 nad identyfikatorem połączenia i nazwą kanału, poprzedzony kluczem aplikacji. Ponieważ identyfikator połączenia jest częścią podpisu, zatwierdzenie dotyczy jednego połączenia i nie może zostać odtworzone na innym. Kanał obecnościowy podpisuje też tożsamość członka i musi to być dokładnie taki sam ciąg, jaki zwracasz: ponowna serializacja tego samego obiektu może zmienić kolejność kluczy i unieważnić podpis.
02
Autoryzowane połączenia.
Klucz aplikacji jest publiczny, więc każdy, kto może załadować Twoją stronę, może otworzyć z nim socket. Włącz autoryzowane połączenia, a każde nowe połączenie będzie miało 30 sekund, żeby udowodnić, że coś posiadającego sekret za nie poręczyło — poprzez prywatną subskrypcję lub logowanie. Połączenia, które tego nie zrobią, są zamykane z kodem 4009, a nieautoryzowane połączenia nigdy nie wliczają się do Twojego limitu. Subskrypcja kanału publicznego niczego nie dowodzi i nie autoryzuje połączenia.
03
Szyfrowanie end-to-end.
Kanał private-encrypted- jest szyfrowany przez Twój serwer, zanim żądanie opuści Twój proces, za pomocą 32-bajtowego klucza głównego, który nigdy nie pojawia się w żądaniu do Realtime API. Każdy kanał wyprowadza własny klucz, więc autoryzacja klienta dla jednego zaszyfrowanego kanału nie daje mu dostępu do innego. Bird nie może odzyskać utraconego klucza, a rotacja chroni przyszłe dane, nie przeszłe.
04
Natychmiastowe cofnięcie dostępu.
Wylogowany użytkownik, zmienione hasło, zablokowane konto: rozłącz członka, a każde połączenie powiązane z tą tożsamością zostanie zamknięte, na każdym urządzeniu. Klienci traktują to zamknięcie jako ostateczne i nie ponawiają połączenia, a Twoje endpointy przestają dla nich podpisywać, więc nie mogą wrócić.

Szyfrowane kanały

Dane, których Bird nie może odczytać, na infrastrukturze, którą Bird obsługuje.

Przeczytaj przewodnik po szyfrowaniu

Serwer SDK rozpoznaje prefiks kanału, wyprowadza klucz tego kanału z Twojego klucza głównego i szyfruje dane lokalnie. Węzeł brzegowy przekazuje szyfrogram, a Twój endpoint autoryzacyjny przekazuje wyprowadzony klucz tylko klientom, których zatwierdzi. Dwa ograniczenia do uwzględnienia w projekcie: nazwy kanałów i zdarzeń przesyłane są jawnie, więc wybieraj nazwy, które nie zdradzają tego, co chronisz, a szyfrowanie nie może być łączone z obecnością ani ze zdarzeniami klienta. Cachowanie jest możliwe: kanał private-encrypted-cache- przechowuje swoje zdarzenie w pamięci podręcznej w postaci zaszyfrowanej.

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

Czego autoryzacja nie robi.

Wymóg autoryzowanych połączeń kontroluje, kto może utrzymywać otwarty socket. Nie zmienia tego, kto może czytać kanał: kanał publiczny pozostaje czytelny dla każdego autoryzowanego połączenia, więc zdarzenia należące do jednego klienta powinny trafiać na kanał prywatny, którego nazwę sprawdza Twój endpoint. A ponieważ to Twoje endpointy są autorytetem, zbyt permisywny endpoint rozdaje dostęp równie swobodnie jak wyciekły klucz. Ta sama zasada dotyczy zdarzeń klienta, których węzeł brzegowy nie waliduje: używaj ich do sygnałów, a wszystko, co ma wartość autoryzacyjną, kieruj przez swój serwer.

Gdzie przechowywane są dane.

Aplikacja wybiera swój region przy tworzeniu i zachowuje go na stałe, więc wybierz ten najbliższy Twoim użytkownikom — region aplikacji może się różnić od regionu macierzystego Twojego obszaru roboczego. Aplikacje stanowią też granicę izolacji: dwie aplikacje nigdy nie widzą swoich kanałów nawzajem, dlatego osobna aplikacja na środowisko to właściwy sposób na oddzielenie ruchu testowego od produkcyjnego.

Dowiedz się więcej w dokumentacji.

Autoryzacja kanałów opisuje kontrakt żądania i odpowiedzi oraz dokładny ciąg do podpisania. Wymóg autoryzowanych połączeń omawia 30-sekundowe okno i kod 4009, szyfrowane kanały obejmują generowanie i rotację kluczy, a kończenie połączeń członków to przepływ logowania i rozłączania.

Reszta Realtime

Jedna aplikacja, jedna para kluczy. Poznaj pozostałe możliwości.

KanałyPubliczne, prywatne, obecnościowe, szyfrowane i z pamięcią podręczną — wszystko określane przez nazwę.ObecnośćKto jest w pokoju, kto właśnie wyszedł i jak dotrzeć bezpośrednio do jednej osoby.WebhooksTwój serwer otrzymuje powiadomienie, gdy kanał się zapełni, opustoszeje lub nie trafi w pamięć podręczną.CennikPołączenia i wiadomości w każdym planie, od darmowego wzwyż.Pierwsze krokiOd rejestracji do pierwszego opublikowanego zdarzenia.Przegląd Realtime APICały produkt: kanały, obecność, bezpieczeństwo, webhooki i klienty.

Skaluj bez
utraty kontroli.

Organizuj zespoły w obszarach roboczych, kontroluj dostęp do API i śledź zmiany w logach audytu.

HarborOrganizacja

Przestrzenie roboczeProdukcjaSandbox

Agent wysyłki

Klucz API · Zespół operacji klienta

Aktywne

UprawnieniaDostęp

EmailOdczyt i zapis

SMSOdczyt i zapis

ALAlex Lee AdministratorZaktualizowano uprawnienia

Dziennik audytu

Produkcja

Przestrzeń robocza: Produkcja
Zasób: Agent wysyłki
WhatsApp: Dostęp do odczytuOdczyt i zapis

Powodzenie

Poznaj Enterprise

Zacznij z Realtime.
Twórz na wielu kanałach z Bird.