Wymaganie autoryzowanych połączeń
Klucz aplikacji jest publiczny. Każdy, kto może załadować Twoją stronę, może go użyć do otwarcia połączenia i subskrypcji kanałów publicznych.
Autoryzowane połączenia wymagają, aby każde nowe połączenie udowodniło autoryzację w ciągu 30 sekund. Węzeł brzegowy Realtime zamyka połączenia, które nie autoryzują się na czas.
Wymagaj autoryzowanych połączeń
Włącz Authorized connections dla aplikacji na stronie Realtime apps. Możesz też ustawić authorized_connections na true przez Realtime API. Ustawienie dotyczy każdego połączenia korzystającego z jednego z kluczy aplikacji.
Zaktualizuj klientów, aby autoryzowali się, zanim włączysz to ustawienie w środowisku produkcyjnym. Połączenia nawiązane przed włączeniem ustawienia pozostają otwarte, ale późniejsze połączenia ze starszych klientów kończą się niepowodzeniem po upływie limitu czasu autoryzacji.
Co liczy się jako autoryzacja
Nowe połączenie zaczyna jako nieautoryzowane. Każda z tych akcji je autoryzuje:
- Subskrypcja kanału prywatnego lub presence kończy się powodzeniem. Klient wysyła identyfikator połączenia do Twojego authEndpoint, backend podpisuje go, a węzeł brzegowy weryfikuje podpis. Zobacz Autoryzacja kanałów.
- signin() kończy się powodzeniem. Klient wysyła identyfikator połączenia do Twojego memberAuthEndpoint i otrzymuje podpisaną tożsamość członka. Zobacz Kończenie połączeń członka, aby poznać pełny przebieg logowania.
Obie ścieżki dowodzą tego samego: coś posiadającego sekret aplikacji poręczyło za to połączenie. Subskrypcja kanału publicznego niczego nie dowodzi i niczego nie autoryzuje.
Przypadek samych kanałów publicznych
Klient subskrybujący wyłącznie kanały publiczne normalnie nie kontaktuje się z Twoim backendem. Po włączeniu wymagania autoryzowanych połączeń wywołaj signin(), aby połączenie mogło się autoryzować bez prywatnej subskrypcji:
import { BirdRealtime } from "@messagebird/realtime";
const bird = new BirdRealtime({
appKey: "your-app-key",
region: "us1",
memberAuthEndpoint: "/bird/auth/member",
});
await bird.signin();
const status = bird.subscribe("build-status");
status.bind("build-finished", (data) => render(data));import BirdRealtime
let bird = BirdRealtime(options: .init(
appKey: "your-app-key",
region: "us1",
memberAuthEndpoint: URL(string: "https://your-backend.example.com/bird/auth/member")
))
try await bird.signin()
let status = bird.subscribe("build-status")
status.bind("build-finished") { data in
render(data)
}import com.bird.realtime.BirdRealtime
import com.bird.realtime.BirdRealtimeOptions
val bird = BirdRealtime(
BirdRealtimeOptions(
appKey = "your-app-key",
region = "us1",
memberAuthEndpoint = "https://your-backend.example.com/bird/auth/member",
)
)
bird.signin() // suspending
val status = bird.subscribe("build-status")
status.bind("build-finished") { data ->
render(data)
}Wywołaj signin() raz. Klient loguje się ponownie po każdym ponownym połączeniu, ponieważ tożsamość należy do połączenia. Zwróć 403 Forbidden z endpointu autoryzacji członka, gdy wywołujący nie powinien się połączyć.
Jeśli aplikacja subskrybuje kanał prywatny lub presence przy ładowaniu, udana subskrypcja już autoryzuje połączenie.
Co widzi klient, gdy nie autoryzuje się
Węzeł brzegowy zamyka połączenie z kodem 4009 i powodem Connection not authorized within timeout. Klienty nie ponawiają prób dla kodów z tego zakresu, więc połączenie przechodzi w stan failed.
bird.connection.bind("error", ({ code, message }) => {
if (code === 4009) console.warn(message);
});bird.onError { error in
if error.code == 4009 { print(error.message) }
}bird.onError { error ->
if (error.code == 4009) println(error.message)
}Kod 4009 identyfikuje też członka, którego połączenia zakończył Twój backend. Sprawdź powód przed wyborem stanu zalogowania lub wylogowania. Zobacz Kończenie połączeń członka i Cykl życia połączenia i ponowne łączenie.
Połączenia nie wliczają się do limitu połączeń aplikacji, dopóki się nie autoryzują.
Zakres autoryzacji
Wymaganie autoryzowanych połączeń kontroluje, kto może utrzymywać otwarte połączenie. Nie zastępuje sprawdzania autoryzacji ani nie zmienia tego, kto może czytać kanał:
- Kanał publiczny pozostaje publiczny dla każdego autoryzowanego połączenia. Jeśli zdarzenia należą do jednego klienta, użyj kanału prywatnego i sprawdzaj nazwę kanału w swoim endpoincie.
- Każdy, kogo Twoje endpointy autoryzacji podpiszą, jest autoryzowany, więc zbyt liberalny endpoint rozdaje autoryzacje równie swobodnie, jak robił to klucz aplikacji.
Następne kroki
- Autoryzacja kanałów to podpis, który Twój backend oblicza dla subskrypcji prywatnych i presence.
- Kanały prywatne to właściwe narzędzie, gdy same zdarzenia należą do kogoś.
- Kończenie połączeń członka obejmuje signin() i inne zastosowanie 4009.
- Wysyłanie zdarzeń do członka adresuje zdarzenie do zalogowanej tożsamości zamiast do kanału.
- Cykl życia połączenia i ponowne łączenie wyjaśnia, dlaczego 4009 jest terminalny.
Powiązane zasoby
Kontynuuj z dokumentacją, przewodnikami i przykładami dotyczącymi tego tematu. Zasoby są w języku angielskim.
Poznaj możliwościRealtimePodążaj ścieżką naukiBuild your first integrationPrzewodnik wdrożeniowySend your first realtime event
Wypróbuj ćwiczenie i uzyskaj brief wdrożeniowy