NgSysV.A Serious Svelte InfoSys: Firebase D/b-Regeln und Login

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

Letzte Bewertung: 24. November

1. Einführung

Als Sie mit Hilfe von Beitrag 2.3 Ihre erste Firestore-Datenbank erstellt haben, erinnern Sie sich vielleicht daran, dass Sie gefragt wurden, ob Sie „Produktions“- oder „Test“-Regeln anwenden möchten. Damals wurde vorgeschlagen, „Test“-Regeln auszuwählen. Wenn Sie zu diesem Zeitpunkt die Registerkarte „Regeln“ auf der Firestore-Seite in der Firebase-Konsole verwendet hätten, hätten Sie festgestellt, dass Ihre Regeln auf etwa Folgendes eingestellt waren:

match /{document=**} {
  allow read, write: if request.time < timestamp.date(2024, 10, 31);
}

Hier hat Google eine Standardregel erstellt, die einen Zeitstempel verwendet, um ab dem Tag, an dem Sie sie erstellt haben, 30 Tage lang Lese- und Schreibzugriff auf Ihre Datenbank zu ermöglichen. Es ist unwahrscheinlich, dass das jetzt das ist, was Sie wollen (und Google wird Sie sowieso dazu auffordern, es zu ändern). Jetzt ist es an der Zeit, mehr über Firestore-Regeln zu erfahren und wie Sie sie verwenden können, um Ihre Datenbank sicher zu machen.

Datenbankregeln

Mit Firestore-„Regeln“ können Sie den Lese- und Schreibzugriff auf Datenbanksammlungen einschränken, indem Sie auf ein Firebase-Anforderungsobjekt verweisen, das bei jedem Datenbankaufruf an einen Firestore-„Regelhandler“ übergeben wird. Dieses Objekt enthält unter anderem Angaben zum anfragenden Benutzer, zur Art des ausgeführten Vorgangs und zur aktuellen Uhrzeit. Wenn Sie die vollständige Liste der Eigenschaften sehen möchten, stellt Ihnen chatGPT diese gerne zur Verfügung.

Um einen vollständigen Überblick über die Syntax der Firestore-Regeln zu erhalten, verweise ich Sie wahrscheinlich am besten auf die eigenen Dokumente von Google unter „Erste Schritte mit Firestore-Regeln“. Im Moment werde ich mich auf die unmittelbaren Anforderungen an die Standarddatenbank konzentrieren, die in dieser Beitragsreihe erstellt wurde.

Um eine Datenbankregel in Aktion zu sehen, versuchen Sie, die Registerkarte „Regeln“ auf der Firestore-Seite in Ihrer Firebase-Konsole zu verwenden, um Ihre Regeln wie folgt zu ändern:

    match /{document=**} {
      allow read: if true;
      allow write: if request.time < timestamp.date(2000, 01, 01);
    }

Diese Regel erlaubt nur Schreibzugriff auf die Dokumente in Ihrer Datenbank, wenn die Zeit vor dem 1. Januar 2000 liegt. Wenn Sie also nicht gerade in einer Zeitmaschine arbeiten, können Sie jetzt keine neue erstellen Dokument.

Klicken Sie auf die Schaltfläche „Veröffentlichen“, um die neue Regel live zu schalten (Sie können die Meldung ignorieren, dass die Veröffentlichung einige Zeit dauern kann, bis sie wirksam wird – in der Praxis scheint die Verzögerung minimal zu sein) und sehen Sie, wie Ihre Webanwendung reagiert

Starten Sie Ihren Entwicklungsserver und starten Sie die Webanwendung unter http://localhost:5173. Wenn Sie versuchen, ein neues Produkt hinzuzufügen, sollten Sie nicht allzu überrascht sein, wenn Sie die Seite „500: Interner Fehler“ erhalten. Wenn Sie zu Ihrer Terminalsitzung gehen, um die Ursache zu untersuchen, wird die folgende Meldung angezeigt:

match /{document=**} {
  allow read, write: if request.time < timestamp.date(2024, 10, 31);
}

Da Sie nun ein Gefühl dafür haben, wie Firestore-Regeln funktionieren, können Sie darüber nachdenken, wie Sie diese auf den Produktanzeige- und Produktwartungsseiten verwenden könnten, die Sie in Beitrag 3.1 erstellt haben.

Wie Sie sich erinnern werden, boten diese zwei Routen wie folgt an:

• eine „products-display“-Route unter localhost:5173/products-display, die es Benutzern ermöglicht, alle Dokumente aus der Produktsammlung zu lesen und
• eine „products-maintenance“-Route unter localhost:5173/products-maintenance, die es Benutzern ermöglicht, neue Dokumente in die Sammlung zu schreiben.

Es wird davon ausgegangen, dass Sie jedem gerne gestatten, Produktdokumente über die Route „Produktanzeige“ zu lesen, Sie möchten jedoch, dass dies nur autorisierten Personen gestattet ist Sie können neue Produkte über die Route „Produkte-Wartung“ hinzufügen.

Einzelpersonen werden autorisiert, indem ihnen eine „Benutzer-ID/Passwort“-Kombination zugewiesen wird, mit der sie sich bei der Webanwendung „anmelden“ können. Durch dieses Verfahren wird ein dauerhafter „Authentifizierungs“-Status auf dem Clientgerät des Benutzers erstellt, der Teil des Firebase-Anforderungsobjekts wird, das an die Firestore-Regelverarbeitung übergeben wird, wenn der Benutzer versucht, auf eine Datenbank zuzugreifen.

Wenn Sie dann die Firestore-Regeln wie folgt festlegen:

    match /{document=**} {
      allow read: if true;
      allow write: if request.time < timestamp.date(2000, 01, 01);
    }

Nur ​​„eingeloggte“ Benutzer können auf der Seite „Produkte“ schreiben.

Jetzt müssen Sie nur noch wissen, wie Sie eine „Anmeldeseite“ schreiben, um einen Authentifizierungsstatus zu erstellen. Bitte lesen Sie weiter!

2. Firebase-Anmeldung

In einem Anmeldebildschirm werden potenzielle Systembenutzer aufgefordert, eine persönliche Kennung (normalerweise eine E-Mail-Adresse) und ein zugehöriges Passwort anzugeben.

Das System vergleicht dann die Kennung und das Passwort des Benutzers mit einer sicheren Liste bekannter Anmeldeinformationen. In Firebase finden Sie diese Liste in der Firebase-Konsole Ihres Projekts auf der Registerkarte „Build –> Authentifizierung –> Benutzer“. Schauen Sie sich das an. Nutzen Sie die Gelegenheit, eine Test-E-Mail-Adresse und ein Passwort zu registrieren (eine programmatische Registrierung ist ebenfalls möglich, wird hier aber nicht behandelt). Beachten Sie das „Benutzer-UID-Feld“, das Firebase der Registrierung zuordnet. Dabei handelt es sich um eine eindeutige, verschlüsselte Version der E-Mail-Adresse. Wie Sie gleich sehen werden, ist dies ein wichtiges Element des Firebase-Sicherheitsmechanismus. Beachten Sie auch, dass der Bildschirm Funktionen zum Löschen von Konten und zum Ändern von Passwörtern bietet.

Während Sie hier sind, sehen Sie sich die Registerkarte „Anmeldemethode“ auf dem Bildschirm „Authentifizierung“ an. Es werden E-Mail-/Passwort-Kombinationen oder Google-Konten angeboten. Ich empfehle, dass Sie zu diesem Zeitpunkt nur die E-Mail-/Passwort-Option aktivieren.

Erstellen Sie nun einen Anmeldebildschirm. Der unten gezeigte Beispielcode ist überraschend kurz (und das meiste davon ist Styling!):

[FirebaseError: Missing or insufficient permissions.] {
  code: 'permission-denied',
  customData: undefined,
  toString: [Function (anonymous)]
}

Erstellen Sie neue Routenordner und page.svelte-Dateien für die Anmelde- und Abmeldeskripte. Aber versuchen Sie es noch nicht, sie auszuführen, denn ich muss Ihnen noch ein paar Kleinigkeiten erzählen!

Beachten Sie, dass diese Dateien jetzt ihre Authentifizierungsvariable aus einer zentralen src/lib/utilities/firebase-client.js-Datei importieren. Darin präsentiert die Webanwendung ihre Firebase-Konfigurationsschlüssel, um Firebase zu versichern, dass es berechtigt ist, ein Authentifizierungsobjekt zu erstellen. Hier ist die aktualisierte Version von src/lib/utilities/firebase-client.js, die dies tut.

match /{document=**} {
  allow read, write: if request.time < timestamp.date(2024, 10, 31);
}

Da die hier exportierten App-, Authentifizierungs- und Datenbankvariablen in einer Webanwendung häufig benötigt werden, wird viel Code eingespart, indem sie an einem zentralen Ort generiert werden.

Aber ein paar „Bling“-Teile hier bedürfen einer Erklärung.

Zunächst werden Sie feststellen, dass ich FirebaseConfig-Eigenschaften wie apiKey nicht mehr direkt im Code codiere, sondern auf Vite-Parameter verweise, die ich in der .env-Datei des Projekts definiert habe (eine Datei oder Ordner mit einem „.“ bedeutet, dass es sich um „System“-Daten handelt). Hier ist es:

    match /{document=**} {
      allow read: if true;
      allow write: if request.time < timestamp.date(2000, 01, 01);
    }

Der Sinn der .env-Datei besteht darin, Ihre firebaseConfig-Schlüssel in einer Datei abzulegen, die keinen Anwendungscode enthält. Dies erleichtert Ihnen die Verwaltung ihrer Sicherheit erheblich. Aber lassen wir das zunächst beiseite, damit Sie sich auf wichtigere Dinge konzentrieren können. Ich habe am Ende dieses Beitrags eine Notiz hinzugefügt, die hoffentlich alles erklärt.

Eine zweite Funktion, die Sie vielleicht verwirren könnte, ist die const app = !getApps().length ? initializeApp(firebaseConfig) : getApp(); Linie. Dies ist ein Beispiel für eine „ternäre“ Javascript-Anweisung (holen Sie sich chatGPT, um zu erklären, wie es funktioniert, falls Sie das noch nicht kennen). Seine Wirkung ist:

• Initialisieren Sie eine Firebase-App nur, wenn derzeit keine App in der Firebase-Umgebung vorhanden ist. Die Webanwendung referenziert während einer Benutzersitzung häufig auf firebase-client.js und initializeApp() schlägt fehl, wenn bereits eine App vorhanden ist
• Andernfalls rufen Sie die vorhandene App ab.

Zurück im Mainstream hat das alles zur Folge, dass Firebase bei erfolgreicher Anmeldung ein „Authentifizierungs“-Objekt für den authentifizierten Benutzer erstellt und dieses sicher in der Browserumgebung ablegt. Firebase kann somit automatisch jedem Anforderungsobjekt, das an eine FireStore-Datenbankdienstanfrage übergeben wird, ein daraus generiertes Authentifizierungstoken hinzufügen. Zu den Informationen im Token gehören Eigenschaften wie die „Benutzer-uID“-ID, die Sie zuvor auf der Registerkarte „Firebase-Authentifizierung“ gesehen haben. Folglich kann Firestore entscheiden, wie eine Regel wie „allow write: if request.auth != null“ angewendet wird.

Das alles bedeutet, dass die clientseitige Firestore-Aktivität wie am Schnürchen funktioniert – sobald Sie angemeldet sind, kümmern sich die Firestore-Regeln um alle Ihre Bedenken hinsichtlich der Datenbanksicherheit.

Aber es gibt einen Haken – einen riesigen Haken sogar. Das „Auth“-Objekt, das Firebase in die Browserumgebung eingefügt hat, ist für serverseitige Seiten wie inventory-maintenance/page.server.js nicht verfügbar.

Sie können dies leicht demonstrieren.

1. Veröffentlichen Sie neue Firestore-Regeln, die es jedem ermöglichen, alles in der Produktsammlung zu lesen, aber sicherstellen, dass nur authentifizierte Personen Dokumente schreiben können
   

   match /{document=**} {
     allow read, write: if request.time < timestamp.date(2024, 10, 31);
   }
   

2. Melden Sie sich über die Route /login an und erhalten Sie die Meldung „Sie sind mit Google angemeldet“.

3. Starten Sie die Seite /products-display. Denn die Firestore-Regeln erlauben jedem, alles zu lesen. Auf der Seite wird somit wie bisher die aktuelle Liste der registrierten Produkte angezeigt.

4. Versuchen Sie, über die Produktwartungsseite ein neues Produkt hinzuzufügen. Ach! Fehler!
   

    match /{document=**} {
      allow read: if true;
      allow write: if request.time < timestamp.date(2000, 01, 01);
    }

Was hier passiert ist, ist, dass die „verdrehte“ Authentifizierungsvariable des Browsers und der Rest seiner übergeordneten Firebase-Sitzungsinformationen für Firestore auf dem Server nicht verfügbar sind. Folglich ist request.auth dort undefiniert und daher schlägt die Firestore-Regel fehl.

Der Standpunkt ist, dass Google es abgelehnt hat, Firebase eine serverseitige Version der hervorragenden Sitzungsverwaltungsfunktion zur Verfügung zu stellen, die das Leben auf der Clientseite so angenehm macht. Derzeit verwendet Ihr Code die Firestore-API Client. Auf dem Server, auf dem eine Firestore-Datenbank „Regeln“ für eine Sammlung festgelegt hat, die auf Firebase-Authentifizierungssitzungsvariablen verweist, müssen Sie die Firestore-API Admin anstelle der Client-API verwenden. Aufrufe in der Admin-API überprüfen die Firestore-Regeln nicht, schlagen also nicht fehl, wenn die Authentifizierung nicht definiert ist. Die Verwendung der Admin-API hat jedoch mehrere Konsequenzen:

• Die Admin-API verwendet verschiedene „Anrufsignaturen“. Die Abfolge der Admin-API-Funktionen, die Sie zum serverseitigen Lesen/Schreiben von Datenbankvorgängen verwenden, ähnelt im Großen und Ganzen der Client-Version, verwendet jedoch eine andere Syntax.
• Für die Admin-API müssen Sie alle Benutzerdaten abrufen, die Sie möglicherweise benötigen, indem Sie Code verwenden, den Sie selbst schreiben. Die clientseitige Firebase-Sitzung, die praktischerweise das unschätzbare auth.currentUser-Objekt zur Bereitstellung von uID, Benutzername usw. bereitgestellt hat, ist serverseitig nicht mehr verfügbar. Sie müssen selbst für einen Ersatz sorgen.

Stöhnen. Gibt es eine Alternative? Die nächsten beiden Beiträge zeigen:

1. Wie Sie das Problem umgehen können, indem Sie eine „regelfreundliche“ Version Ihrer Webanwendung entwickeln. Die Folge davon ist eine schlechtere Leistung (da serverseitiger Code schneller läuft), eine geringere Sicherheit (da die clientseitige Formularvalidierung unsicher ist) und geringere SEO-Aussichten (da Webspider weniger Begeisterung für die Indizierung von clientseitigem Code haben)
2. Alternativ, wie Sie weitermachen und eine vollständige „Client-Server“-Version Ihrer Webanwendung entwickeln können. Dadurch erhalten Sie Top-Leistung, Sicherheit und SEO, müssen aber eine weitere Technologiewelle verhandeln, um die Funktionslücken zu schließen, die durch den Verlust der Firebase-Benutzersitzungsvereinbarung entstanden sind

3. Fazit

Das war eine harte Fahrt mit einem unglücklichen Ende. Ich hoffe jedoch, dass Sie die Energie haben, weiterzulesen.

Aus Ihrer Sicht als Entwickler wird regelfreundlicher Code eine wahre Freude sein, da Sie ihn vollständig mit dem Inspector-Tool des Browsers debuggen können. Obwohl es, wie bereits erwähnt, Einschränkungen aufweist, könnte es für viele einfache Anwendungen vollkommen zufriedenstellend sein.

Alternativ stellt die Client-Server-Version zwar einige neue Herausforderungen dar, vermittelt Ihnen aber wertvolle Erfahrungen in gängigen Entwicklungspraktiken und liefert eine wirklich bemerkenswerte Leistung.

Nachtrag – worum geht es in diesem „.env“-Geschäft?

So bizarr es auch klingen mag, alles beginnt mit der Versionskontrollsoftware „Github“ von Microsoft. Dies ist eine kostenlose Webanwendung, mit der Sie Quellkopien in ein persönliches webbasiertes Repository kopieren können. Es ist zu einem Industriestandard geworden und Sie können mehr darüber unter „Eine sanfte Einführung in Git und Github“ erfahren.

Der Hauptzweck besteht darin, die Aktivitäten von Entwicklerteams zu integrieren, die parallel am selben Projekt arbeiten. Aber Sie könnten durchaus daran interessiert sein, es zu verwenden, denn während der Entwicklung und fortlaufenden Verbesserung Ihrer persönlichen Projekte wird es Zeiten geben, in denen Sie einen „Checkpoint“-Snapshot Ihres Codes an einem sicheren Ort platzieren möchten. .

Das Problem besteht darin, dass im Quellcode eingebettete sensible Schlüssel allzu leicht versehentlich in einem Git-Repository gespeichert werden. Obwohl Repositorys als „privat“ markiert werden können, ist die Sicherheit nicht garantiert.

Ein Teil der Antwort besteht darin, die Dinge so zu arrangieren, dass Projektschlüssel getrennt von Codedateien gespeichert werden. Auf diese Weise müssen sie nicht nach Git kopiert werden. Das Platzieren Ihrer Firebase-Schlüssel in Ihrer libutilitiesfirebase-client.js-Datei hat hier geholfen, da dadurch Schlüssel nicht mehr in mehreren page.server.js-Dateien codiert wurden. Aber es gab immer noch Code in der zentralen Datei firebase-client.js, den Sie in Ihrem Repo speichern möchten. Durch die Verwendung der env-Datei können Sie Code endlich von Schlüsseln trennen. Obwohl Ihre .env-Schlüssel in Ihrem Projekt verbleiben, muss diese Datei nicht mehr in das Code-Repository kopiert werden. Es kann daher zur Datei .gitignore hinzugefügt werden, die Git mitteilt, welche Dateien ausgeschlossen werden sollen.

Sie werden feststellen, dass Svelte bei der Initialisierung Ihres Projekts eine .gitignore-Datei erstellt hat und dass diese bereits Details zu Vite-Systemordnern enthält, die keinen Platz in einem Quellcode-Prüfpunkt haben. Um sicherzustellen, dass eine „.env“-Datei (und jeglicher Bearbeitungsverlauf für die Datei) von allen Git-Commits ausgeschlossen ist, würden Sie die folgenden Einträge hinzufügen:

match /{document=**} {
  allow read, write: if request.time < timestamp.date(2024, 10, 31);
}

Beachten Sie, dass die Zeile /.env in Ihrem VSCode Workspace-Verzeichnis „ausgegraut“ wird, sobald Sie dies getan haben. Dies bietet visuelle Sicherheit, dass diese Datei nicht durch einen Git-Commit im Web offengelegt wird.

Das obige ist der detaillierte Inhalt vonNgSysV.A Serious Svelte InfoSys: Firebase D/b-Regeln und Login. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!