NgSysV.A Serious Svelte InfoSys: Eine Client-Server-Version

Diese Beitragsserie ist auf NgateSystems.com indiziert. Dort finden Sie auch eine äußerst nützliche Stichwortsuchfunktion.

Letzte Bewertung: 24. November

1. Einführung

Beitrag 3.3 brachte schlechte Nachrichten: Das Firestore-Authentifizierungsobjekt, das clientseitig zur Bereitstellung von Informationen über einen angemeldeten Benutzer verwendet wird, ist serverseitig nicht verfügbar. Dies hat folgende Konsequenzen:

• Serverseitiger Datenbankcode muss die Firestore-API Admin verwenden. Dies liegt daran, dass der Firestore-Client-API-Code, der Aufrufe Datenbank-„Regeln“ unterliegt, die auf die Authentifizierung verweisen, fehlschlägt, wenn die Authentifizierung nicht verfügbar ist. Im Gegensatz dazu kümmern sich Admin-API-Aufrufe nicht um Datenbankregeln. Wenn Sie die Regeln fallen lassen würden, würden Client-API-Aufrufe serverseitig funktionieren, Ihre Datenbank wäre dadurch jedoch anfällig für Cyberangriffe (Sie arbeiten in Ihrer Live-Firestore-Datenbank, seit Sie Ihr lokales VSCode-Terminal verwenden – denken Sie darüber nach). .

• Serverseitiger Code, der von Auth abgeleitete Datenelemente wie Benutzername und Benutzer-E-Mail verwendet, muss einen anderen Weg finden, diese Informationen abzurufen.

In diesem Beitrag wird beschrieben, wie Sie diese Probleme überwinden, um eine leistungsstarke Webanwendung zu erstellen, die serverseitig sicher und effizient läuft.

2. Authentifizierter serverseitiger Svelte-Code in der Praxis

Wenn Sie sich bereits an die Client-Anrufsignaturen gewöhnt haben, ist die Notwendigkeit, zur Firestore-Admin-API zu wechseln, ein Ärgernis. Daran wirst du dich aber schnell gewöhnen, sodass es dich nicht allzu sehr aufhalten sollte.

Benutzerdaten zu erhalten ist jedoch eine andere Sache. Bei vielen Anwendungen ist der Zugriff auf Benutzereigenschaften wie uId für deren Design von entscheidender Bedeutung. Beispielsweise muss eine Webanwendung möglicherweise sicherstellen, dass Benutzer nur ihre eigenen Daten sehen können. Leider ist es ziemlich schwierig, dies zu arrangieren. Los geht's:

1. Zuerst müssen Sie auf dem Client eine Möglichkeit finden, ein „idToken“-Paket zu erstellen, das alles enthält, was Ihr serverseitiger Code möglicherweise über einen Benutzer wissen muss. Google bietet einen getIdToken()-Mechanismus, um dies aus den Authentifizierungssitzungsdaten des Benutzers zu erstellen.
2. Dann müssen Sie eine Möglichkeit finden, dieses Paket an den Server weiterzuleiten. Der hier verwendete Mechanismus registriert dies in einem „Header“, der Client-Aufrufen an den Server hinzugefügt wird.
3. Dann müssen Sie ein Google-„Dienstkonto“ erhalten, mit dem Sie Ihre Nutzung der Firestore Admin API auf einem Google-Server authentifizieren können. Die Schlüssel, die dies definieren, müssen sicher in Ihre Projektdateien eingebettet werden (erinnern Sie sich an die Diskussion zu firebaseConfig.env in Beitrag 3.3.
).
4. Und schließlich muss Ihr serverseitiger Code diese Dienstkontoschlüssel überall dort bereitstellen, wo Sie eine Firestore-Datenbank verwenden müssen.

2.1 Einen idToken erhalten

Sehen Sie sich den folgenden Code aus dem