Autorisierte Verbindungen voraussetzen
Der App-Key ist öffentlich. Jeder, der Ihre Seite laden kann, kann damit eine Verbindung öffnen und öffentliche Channels abonnieren.
Autorisierte Verbindungen verlangen von jeder neuen Verbindung, dass sie sich innerhalb von 30 Sekunden als autorisiert ausweist. Die Realtime-Edge schließt Verbindungen, die sich nicht rechtzeitig autorisieren.
Autorisierte Verbindungen aktivieren
Aktivieren Sie Authorized connections für die App auf der Seite Realtime-Apps. Sie können auch authorized_connections über die Realtime-API auf true setzen. Die Einstellung gilt für jede Verbindung, die einen der App-Keys verwendet.
Aktualisieren Sie Clients zur Autorisierung, bevor Sie die Einstellung in der Produktion aktivieren. Verbindungen, die vor der Aktivierung bestanden, bleiben offen, aber spätere Verbindungen von älteren Clients scheitern nach dem Autorisierungs-Timeout.
Was als autorisiert gilt
Eine neue Verbindung startet unautorisiert. Eine der folgenden Aktionen autorisiert sie:
- Ein Private- oder Presence-Abonnement ist erfolgreich. Der Client sendet die Connection-ID an Ihren authEndpoint, Ihr Backend signiert sie, und die Edge verifiziert die Signatur. Siehe Channels autorisieren.
- signin() ist erfolgreich. Der Client sendet die Connection-ID an Ihren memberAuthEndpoint und erhält eine signierte Member-Identität. Siehe Member-Verbindungen beenden für den vollständigen Anmeldeablauf.
Beide Wege beweisen dasselbe: Etwas, das das App-Secret besitzt, hat für diese Verbindung gebürgt. Das Abonnieren eines öffentlichen Channels beweist nichts und autorisiert nichts.
Der Fall reiner Public-Channels
Ein Client, der nur öffentliche Channels abonniert, kontaktiert Ihr Backend normalerweise nicht. Nachdem Sie autorisierte Verbindungen voraussetzen, rufen Sie signin() auf, damit sich die Verbindung ohne ein privates Abonnement autorisieren kann:
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)
}Rufen Sie signin() einmal auf. Der Client meldet sich nach jedem Reconnect erneut an, weil die Identität zur Verbindung gehört. Geben Sie 403 Forbidden von Ihrem Member-Autorisierungsendpoint zurück, wenn sich der Aufrufer nicht verbinden darf.
Wenn die App beim Laden einen Private- oder Presence-Channel abonniert, autorisiert das erfolgreiche Abonnement die Verbindung bereits.
Was der Client sieht, wenn er sich nicht autorisiert
Die Edge schließt die Verbindung mit Code 4009 und dem Grund Connection not authorized within timeout. Die Clients wiederholen Codes in diesem Bereich nicht, sodass die Verbindung in den Zustand failed übergeht.
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)
}Code 4009 identifiziert auch einen Member, dessen Verbindungen Ihr Backend beendet hat. Prüfen Sie den Grund, bevor Sie einen Anmelde- oder Abmeldezustand wählen. Siehe Member-Verbindungen beenden und Verbindungslebenszyklus und Reconnection.
Verbindungen zählen erst dann zum Verbindungskontingent der App, wenn sie sich autorisieren.
Autorisierungsumfang
Autorisierte Verbindungen vorauszusetzen steuert, wer eine Verbindung offen halten kann. Es ersetzt keine Autorisierungsprüfungen und ändert nicht, wer einen Channel lesen kann:
- Ein öffentlicher Channel bleibt für jede autorisierte Verbindung öffentlich. Wenn die Events einem bestimmten Kunden gehören, verwenden Sie einen privaten Channel und prüfen Sie den Channel-Namen in Ihrem Endpoint.
- Jeder, für den Ihre eigenen Auth-Endpoints signieren, ist autorisiert. Ein zu freizügiger Endpoint verteilt die Autorisierung also genauso uneingeschränkt wie der App-Key.
Nächste Schritte
- Channels autorisieren beschreibt die Signatur, die Ihr Backend für Private- und Presence-Abonnements berechnet.
- Private Channels sind das richtige Mittel, wenn die Events selbst jemandem gehören.
- Member-Verbindungen beenden behandelt signin() und die andere Verwendung von 4009.
- Events an einen Member senden adressiert ein Event an eine angemeldete Identität statt an einen Channel.
- Verbindungslebenszyklus und Reconnection erklärt, warum 4009 terminal ist.
Related resources
Continue with the documentation, guides and examples for this topic. Resources are in English.
Explore the capabilityRealtimeFollow the learning pathBuild your first integrationImplementation guideSend your first realtime event
Try the practice and get an implementation brief