Jetzt ist es wichtig zu verstehen, wie die Authentifizierung funktioniert, denn wenn Sie einen Webentwicklungshintergrund haben,
sind Sie möglicherweise daran gewöhnt, dass die Authentifizierung etwas anders funktioniert.
Wir haben also einen Server, in unserem Fall Firebase, aber das kann jeder Server sein, mit dem wir
über unsere mobile React
Native-App sprechen. Dies ist der Server, der uns normalerweise auch authentifiziert, sodass wir die E-Mail und das
vom Benutzer eingegebene Passwort senden können Um einen neuen Benutzer zu erstellen oder einen
Benutzer anzumelden, senden wir diese Authentifizierungsdaten an den Server.
Jetzt antwortet der Server mit etwas, zum Beispiel mit einem Fehler, wenn die Anmeldeinformationen falsch sind, oder
mit einer Erfolgsantwort, wenn sie korrekt sind. In einer herkömmlichen Webanwendung würde ein Server dann auch eine
sogenannte Sitzung auf dem Server speichern und zurückkehren Ein Sitzungsschlüssel für das Front-End, also beispielsweise für den
Browser, mit dem der Browser im Grunde feststellen kann, dass der Benutzer, der diese App
in diesem Browser verwendet, authentifiziert ist.
Dies funktioniert für mobile Apps etwas anders, da Sie dort mit zustandslosen Servern kommunizieren,
z. B. RESTful-APIs oder GraphQL-APIs, und dort keine Sitzung haben,
da sich der Server nicht um die einzelnen Clients kümmert speichert keine
Daten darüber, ob Sie authentifiziert sind oder nicht,
sondern arbeitet mit sogenannten Token.
Die Idee ist nicht zu weit von der Sitzungsidee entfernt.
Wenn Sie sich anmelden und der Server die E-Mail und das Kennwort überprüft und feststellt, dass beide korrekt sind, erstellt der
Server ein Token, verwendet dafür einen bestimmten
Algorithmus und verwendet einen Schlüssel, einen privaten Schlüssel, den nur der Server kennt. Dieses Token wird dann an Sie zurückgegeben, also an
Ihre App, z. B.
an React Native Mobile App, und dort können Sie das Token in einem Speicher speichern,
z. B. im Redux-Speicher. Verwalten Sie
es also im Speicher mit Redux im Speicher, während Sie App läuft.
Warum brauchen wir diesen Token? Zum einen können wir, solange wir über dieses Token verfügen, in
der mobilen App feststellen, dass der Benutzer wahrscheinlich angemeldet ist, und den Benutzer daher vom Authentifizierungsbildschirm an
unseren Haupt-App-Bildschirm usw. weiterleiten. Wenn der Benutzer auf Abmelden klickt, werden wir würde dieses Token einfach löschen, aber
wir brauchen dieses Token auch für etwas anderes. Wie bereits erwähnt, verfügen wir auf dem
Server normalerweise über bestimmte Ressourcen, bestimmte URLs, die nur angemeldeten Benutzern zugänglich sind. In unserer App sollte
das Erstellen von Produkten wahrscheinlich nicht von jedem Benutzer ausgeführt werden können, und wenn Sie dies möchten Wenn
Sie die Anforderung an eine solche geschützte Ressource senden, müssen Sie dieses Token an die Anforderung anhängen,
damit der Server, der das Token erstellt hat und daher mit diesem privaten Schlüssel prüfen kann, ob das Token gültig
ist, damit der Server feststellen kann, ob dies der Fall ist Zugang oder nicht.
Wenn Sie ein falsches Token oder ein ungültiges Token oder gar kein Token senden, wird der Zugriff verweigert und Sie erhalten
eine Fehlermeldung zurück. Wenn Sie ein gültiges
Token haben und der Server erneut prüfen kann, ob das Token gültig ist oder nicht, wird Ihnen der Zugriff gewährt, und Sie
können dann auf die Ressourcen zugreifen und Daten schreiben, was auch immer es ist.
So funktioniert die Authentifizierung und so
werden wir sie hier implementieren.
Das Gute ist, dass Firebase, das wir als Dummy-Backend verwenden, bereits alle Funktionen zur Benutzerverwaltung für die Token-Erstellung
integriert hat. Wir müssen uns also keine Sorgen machen, sondern nur die
richtigen Anforderungen senden und dann verwalten dieses Zeichen und wir sind gut zu gehen.