1 00:00:02,200 --> 00:00:08,050 Jetzt ist es wichtig zu verstehen, wie die Authentifizierung funktioniert, denn wenn Sie einen Webentwicklungshintergrund haben, 2 00:00:08,050 --> 00:00:12,100 sind Sie möglicherweise daran gewöhnt, dass die Authentifizierung etwas anders funktioniert. 3 00:00:12,100 --> 00:00:17,910 Wir haben also einen Server, in unserem Fall Firebase, aber das kann jeder Server sein, mit dem wir 4 00:00:17,920 --> 00:00:19,570 über unsere mobile React 5 00:00:19,570 --> 00:00:25,330 Native-App sprechen. Dies ist der Server, der uns normalerweise auch authentifiziert, sodass wir die E-Mail und das 6 00:00:25,330 --> 00:00:30,030 vom Benutzer eingegebene Passwort senden können Um einen neuen Benutzer zu erstellen oder einen 7 00:00:30,040 --> 00:00:32,940 Benutzer anzumelden, senden wir diese Authentifizierungsdaten an den Server. 8 00:00:32,940 --> 00:00:39,880 Jetzt antwortet der Server mit etwas, zum Beispiel mit einem Fehler, wenn die Anmeldeinformationen falsch sind, oder 9 00:00:39,880 --> 00:00:46,870 mit einer Erfolgsantwort, wenn sie korrekt sind. In einer herkömmlichen Webanwendung würde ein Server dann auch eine 10 00:00:46,870 --> 00:00:53,550 sogenannte Sitzung auf dem Server speichern und zurückkehren Ein Sitzungsschlüssel für das Front-End, also beispielsweise für den 11 00:00:53,560 --> 00:00:59,620 Browser, mit dem der Browser im Grunde feststellen kann, dass der Benutzer, der diese App 12 00:00:59,620 --> 00:01:02,580 in diesem Browser verwendet, authentifiziert ist. 13 00:01:02,590 --> 00:01:08,820 Dies funktioniert für mobile Apps etwas anders, da Sie dort mit zustandslosen Servern kommunizieren, 14 00:01:08,840 --> 00:01:13,640 z. B. RESTful-APIs oder GraphQL-APIs, und dort keine Sitzung haben, 15 00:01:13,930 --> 00:01:19,360 da sich der Server nicht um die einzelnen Clients kümmert speichert keine 16 00:01:19,420 --> 00:01:23,680 Daten darüber, ob Sie authentifiziert sind oder nicht, 17 00:01:24,280 --> 00:01:27,010 sondern arbeitet mit sogenannten Token. 18 00:01:27,010 --> 00:01:30,780 Die Idee ist nicht zu weit von der Sitzungsidee entfernt. 19 00:01:31,030 --> 00:01:36,250 Wenn Sie sich anmelden und der Server die E-Mail und das Kennwort überprüft und feststellt, dass beide korrekt sind, erstellt der 20 00:01:36,850 --> 00:01:38,680 Server ein Token, verwendet dafür einen bestimmten 21 00:01:38,680 --> 00:01:45,430 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 22 00:01:45,430 --> 00:01:47,530 Ihre App, z. B. 23 00:01:47,530 --> 00:01:53,470 an React Native Mobile App, und dort können Sie das Token in einem Speicher speichern, 24 00:01:53,860 --> 00:01:56,010 z. B. im Redux-Speicher. Verwalten Sie 25 00:01:56,020 --> 00:02:00,700 es also im Speicher mit Redux im Speicher, während Sie App läuft. 26 00:02:00,910 --> 00:02:08,260 Warum brauchen wir diesen Token? Zum einen können wir, solange wir über dieses Token verfügen, in 27 00:02:08,290 --> 00:02:13,780 der mobilen App feststellen, dass der Benutzer wahrscheinlich angemeldet ist, und den Benutzer daher vom Authentifizierungsbildschirm an 28 00:02:13,780 --> 00:02:19,450 unseren Haupt-App-Bildschirm usw. weiterleiten. Wenn der Benutzer auf Abmelden klickt, werden wir würde dieses Token einfach löschen, aber 29 00:02:20,110 --> 00:02:25,630 wir brauchen dieses Token auch für etwas anderes. Wie bereits erwähnt, verfügen wir auf dem 30 00:02:25,690 --> 00:02:31,600 Server normalerweise über bestimmte Ressourcen, bestimmte URLs, die nur angemeldeten Benutzern zugänglich sind. In unserer App sollte 31 00:02:31,690 --> 00:02:37,860 das Erstellen von Produkten wahrscheinlich nicht von jedem Benutzer ausgeführt werden können, und wenn Sie dies möchten Wenn 32 00:02:37,910 --> 00:02:43,720 Sie die Anforderung an eine solche geschützte Ressource senden, müssen Sie dieses Token an die Anforderung anhängen, 33 00:02:43,720 --> 00:02:50,500 damit der Server, der das Token erstellt hat und daher mit diesem privaten Schlüssel prüfen kann, ob das Token gültig 34 00:02:50,500 --> 00:02:55,580 ist, damit der Server feststellen kann, ob dies der Fall ist Zugang oder nicht. 35 00:02:55,660 --> 00:03:02,620 Wenn Sie ein falsches Token oder ein ungültiges Token oder gar kein Token senden, wird der Zugriff verweigert und Sie erhalten 36 00:03:02,620 --> 00:03:05,090 eine Fehlermeldung zurück. Wenn Sie ein gültiges 37 00:03:05,110 --> 00:03:11,050 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 38 00:03:11,050 --> 00:03:14,970 können dann auf die Ressourcen zugreifen und Daten schreiben, was auch immer es ist. 39 00:03:15,070 --> 00:03:17,430 So funktioniert die Authentifizierung und so 40 00:03:17,560 --> 00:03:19,560 werden wir sie hier implementieren. 41 00:03:19,570 --> 00:03:25,390 Das Gute ist, dass Firebase, das wir als Dummy-Backend verwenden, bereits alle Funktionen zur Benutzerverwaltung für die Token-Erstellung 42 00:03:25,390 --> 00:03:29,460 integriert hat. Wir müssen uns also keine Sorgen machen, sondern nur die 43 00:03:29,560 --> 00:03:34,210 richtigen Anforderungen senden und dann verwalten dieses Zeichen und wir sind gut zu gehen.