1
00:00:02,140 --> 00:00:08,590
Wie können wir diesen Authentifizierungsbildschirm jetzt verlassen, wenn wir angemeldet sind oder wenn wir uns erfolgreich angemeldet haben?

2
00:00:09,520 --> 00:00:11,130
Das ist nicht allzu schwierig.

3
00:00:11,380 --> 00:00:16,690
Wenn wir es hier über diese Versendung hinaus schaffen, ohne im Fangblock zu landen,

4
00:00:16,720 --> 00:00:18,730
also immer noch hier

5
00:00:19,090 --> 00:00:26,560
im Versuchsblock, können wir einfach Requisiten anrufen. Navigation. Navigieren Sie wie immer und

6
00:00:26,560 --> 00:00:29,470
navigieren Sie zu dem anderen Bildschirm, den wir

7
00:00:29,470 --> 00:00:37,500
in unserem Switch-Navigator eingerichtet haben, also in diesem Fall zum Shop-Bildschirm. Also lass uns das machen, lass uns einfach einkaufen gehen und

8
00:00:37,500 --> 00:00:42,950
erstmal dort, sobald wir uns erfolgreich angemeldet haben, was ich jetzt mache, dies wird geladen und

9
00:00:43,030 --> 00:00:45,300
wir sind hier. Jetzt erhalte ich

10
00:00:45,330 --> 00:00:49,300
hier eine Warnung bezüglich einer Statusaktualisierung, die nicht durchgeführt werden konnte. Das heißt, dieser

11
00:00:49,300 --> 00:00:55,450
Satz lädt den Status, der jetzt fehlschlägt, wenn wir weg navigieren. Die Lösung ist einfach, dass wir nicht versuchen sollten, den Status auf diesem

12
00:00:55,450 --> 00:01:01,000
Bildschirm zu aktualisieren, wenn wir nicht mehr auf dem Bildschirm sind. Wir können ihn also einfach in den catch-Block verschieben, da wir

13
00:01:01,000 --> 00:01:05,560
das Laden nur zurücksetzen müssen, wenn ein Fehler auftritt weil dies der einzige Fall ist, wenn wir auf

14
00:01:05,560 --> 00:01:07,600
dem Authentifizierungsbildschirm bleiben, andernfalls müssen wir den

15
00:01:07,600 --> 00:01:12,190
Ladezustand nicht ändern, da wir den Bildschirm sowieso verlassen. Damit werden wir auch das

16
00:01:12,190 --> 00:01:13,780
los, wenn ich

17
00:01:13,780 --> 00:01:17,080
es jetzt noch einmal versuche, los geht's und

18
00:01:17,300 --> 00:01:18,170
jetzt

19
00:01:18,170 --> 00:01:22,730
sind wir in unserem Hauptgeschäft. Jetzt verwenden wir das Token natürlich immer

20
00:01:22,730 --> 00:01:24,620
noch nicht, also stellen

21
00:01:24,740 --> 00:01:31,550
wir sicher, dass wir das auch tun, und gehen wir dazu zum Auth-Reduzierer und fügen dort einen Anfangszustand hinzu, der

22
00:01:31,640 --> 00:01:35,850
im Grunde beschreibt, mit welchem Zustand wir beginnen möchten und was unser

23
00:01:36,230 --> 00:01:41,960
General ist Zustandsform ist und dort möchte ich das Token speichern, das anfänglich null ist, und ich

24
00:01:41,960 --> 00:01:45,980
möchte die Benutzer-ID speichern, die anfänglich null ist, also sehr grundlegender Anfangszustand.

25
00:01:45,980 --> 00:01:51,230
Dann können wir die Reduzierungsfunktion exportieren, die diesen Anfangszustand annimmt und die natürlich

26
00:01:52,010 --> 00:01:57,430
auch eine Aktion empfängt. Hier möchte ich wie immer den Aktionstyp einschalten und habe

27
00:01:57,430 --> 00:01:59,960
zwei Fälle, die mich gerade interessieren.

28
00:01:59,980 --> 00:02:08,190
Eine ist die Anmeldeaktion, daher müssen Sie diesen Bezeichner aus dem Aktionsordner und der dortigen Authentifizierungsdatei importieren, und

29
00:02:08,190 --> 00:02:12,530
der andere Fall ist die Anmeldeaktion. Sie müssen also

30
00:02:12,580 --> 00:02:14,680
auch diesen Bezeichner importieren,

31
00:02:15,820 --> 00:02:25,400
in anderen Fällen möchte ich nur gib meinen Staat zurück. Wenn wir uns also anmelden, möchte ich einen neuen Status zurückgeben, in

32
00:02:25,400 --> 00:02:33,400
dem das Token "Aktion" sein soll. Token und Benutzer-ID sollten Aktion sein. userId und das ist das gleiche Update,

33
00:02:33,940 --> 00:02:38,530
das ich bei der Anmeldung benötige, damit wir es einfach dort kopieren können.

34
00:02:39,220 --> 00:02:44,530
Jetzt müssen wir natürlich sicherstellen, dass unsere Aktion Token und Benutzer-ID enthält.

35
00:02:44,530 --> 00:02:51,970
Wenn wir also am Ende der Anmeldung hier beim Erstellen der Anmeldeaktion im Aktionsersteller ein Token-Feld

36
00:02:51,970 --> 00:02:55,300
hinzufügen und eine Benutzer-ID hinzufügen Feld.

37
00:02:55,470 --> 00:03:03,670
Jetzt kann das Token aus den Antwortdaten abgerufen werden. Dort befindet sich das ID-Token und hier das gleiche. ResData ist kein ID-Token, sondern die

38
00:03:03,670 --> 00:03:09,250
lokale ID. Hier im Protokoll sehen Sie die lokale ID. Dies ist die Benutzer-ID. Wenn Sie

39
00:03:09,280 --> 00:03:16,530
nach oben scrollen , ID-Token, das ist das Token. Das ist es, was ich hier versende, und

40
00:03:17,070 --> 00:03:21,140
wir können das einfach kopieren und dasselbe verwenden, fast dasselbe für

41
00:03:21,150 --> 00:03:28,140
die Anmeldung. Das einzige, was geändert werden muss, ist diese Kennung. Sie können sogar die Anmeldung vereinen und

42
00:03:28,140 --> 00:03:34,800
sich bei einer kombinierten Authentifizierungskennung anmelden, sagen wir denn in einem Reduzierer machen wir sowieso das Gleiche.

43
00:03:34,920 --> 00:03:40,200
Ich habe es hier nur aufgeteilt, um klar zu sein, dass wir am Ende zwei verschiedene Dinge haben,

44
00:03:40,200 --> 00:03:44,420
aber das Update ist das gleiche, sodass wir diese beiden Aktionstypen definitiv kombinieren können.

45
00:03:45,250 --> 00:03:48,970
Damit speichern wir jetzt den Token und das ist schön,

46
00:03:49,330 --> 00:03:51,990
aber wofür brauchen wir diesen Token wieder?

47
00:03:52,150 --> 00:03:59,700
Wir benötigen das Token, das wir jetzt speichern, um auf unsere API zugreifen zu können. Gehen wir dazu zu Firebase

48
00:03:59,700 --> 00:04:00,870
und zur Datenbank.

49
00:04:00,870 --> 00:04:05,940
Denken Sie daran, dass wir beim Einrichten dieser Datenbank erwähnt haben, dass Sie in diesem

50
00:04:05,940 --> 00:04:11,370
Testmodus starten sollten, wenn Sie sich erinnern. Dies hat dazu geführt, dass bestimmte Regeln eingerichtet wurden und Sie diese

51
00:04:11,370 --> 00:04:15,810
überprüfen können, wenn Sie auf die Registerkarte Regeln klicken. Dies steuert, wer in Ihre Datenbank lesen und

52
00:04:15,810 --> 00:04:20,730
schreiben kann, und im Moment ist dies beide auf true gesetzt, was bedeutet, dass jeder alles lesen und

53
00:04:20,820 --> 00:04:21,930
jeder alles schreiben kann.

54
00:04:22,230 --> 00:04:32,630
Das ist natürlich normalerweise nicht das, was Sie wollen, stattdessen setze ich hier beide auf auth ungleich null, was seltsam aussehen könnte, und dies sollte

55
00:04:32,630 --> 00:04:39,200
hier übrigens in doppelte Anführungszeichen stehen, aber dies ist die Firebase-Syntax, und Sie können hier mehr

56
00:04:39,200 --> 00:04:44,480
über die Regeln erfahren Klicken Sie auf Weitere Informationen oder googeln Sie einfach

57
00:04:44,480 --> 00:04:46,960
nach den Sicherheitsregeln für Firebase-Echtzeitdatenbanken.

58
00:04:47,000 --> 00:04:53,000
Dies sagt Firebase, dass nur authentifizierte Benutzer lesen und schreiben können, sodass nur Benutzer, die

59
00:04:53,000 --> 00:04:57,400
die Anforderung mit einem gültigen Token senden, lesen und schreiben können.

60
00:04:57,560 --> 00:05:00,080
Jetzt könnten Sie sogar argumentieren, dass Redux immer erlaubt

61
00:05:00,110 --> 00:05:06,710
sein sollte, wir könnten dies auf true setzen und Sie könnten sogar spezifischer in Bezug auf die Regeln sein, so dass Sie sagen,

62
00:05:06,710 --> 00:05:07,970
Redux von Produkten

63
00:05:07,970 --> 00:05:09,770
ist erlaubt, Redux von Bestellungen ist

64
00:05:09,800 --> 00:05:13,200
nicht, aber auch dies können Sie überprüfen mit den offiziellen Dokumenten.

65
00:05:13,370 --> 00:05:18,950
Ich werde mit dem Setup fortfahren, bei dem Redux immer erlaubt ist, das Schreiben jedoch nicht.

66
00:05:19,010 --> 00:05:22,160
Zum Schreiben brauchen wir jetzt

67
00:05:22,160 --> 00:05:28,640
einen Token, sonst haben wir ein Problem. Wenn wir uns hier anmelden und das Token speichern, es

68
00:05:28,640 --> 00:05:30,440
aber derzeit nicht an

69
00:05:30,650 --> 00:05:33,060
Anforderungen anhängen, können wir alle Daten laden.

70
00:05:33,320 --> 00:05:38,510
Das ist in Ordnung, aber Sie werden auch feststellen, dass ich versuche, dies zu bearbeiten und

71
00:05:38,510 --> 00:05:45,420
ein paar zu entfernen von Ausrufezeichen hier, am Ende bekomme ich einen Fehler und dieser Fehler wird ausgelöst, weil ich nicht

72
00:05:45,420 --> 00:05:49,190
schreiben darf und Firebase daher den Zugriff blockiert und eine Fehlerantwort zurückgibt.

73
00:05:49,190 --> 00:05:54,890
Jetzt müssen wir das in einem Reduzierer gespeicherte Token nutzen und es tatsächlich an unsere

74
00:05:54,890 --> 00:05:56,360
ausgehenden Anforderungen anhängen.

75
00:05:56,360 --> 00:06:00,940
Dazu müssen wir diesen Reduzierer zunächst in unserem

76
00:06:00,950 --> 00:06:08,300
Root-Reduzierer, also in der App, registrieren. js Datei, wir müssen es importieren, wir müssen den Auth Reducer aus dem Store

77
00:06:08,300 --> 00:06:14,780
importieren und dort den Reducer Ordner und dort die Auth Datei und sie zu kombinierten Reducern hinzufügen, vielleicht hier mit dem Auth Key, aber

78
00:06:14,780 --> 00:06:20,030
natürlich können Sie verwenden jeder Schlüssel, den Sie wollen. Auf diese Weise können wir dies

79
00:06:20,240 --> 00:06:26,360
nutzen und auf dieses Token zugreifen. Jetzt müssen wir es an die ausgehenden Anforderungen anhängen, z. B. für

80
00:06:26,360 --> 00:06:29,450
Produkte, die wir an die Anforderung anhängen müssen, die

81
00:06:29,510 --> 00:06:38,090
wir zum Aktualisieren von Produkten senden. Dies wäre also diese Anforderung hier. Die Art und Weise, wie Sie eine Anfrage in Firebase

82
00:06:38,090 --> 00:06:44,570
anhängen, finden Sie in den offiziellen Firebase-Dokumenten für die Echtzeitauthentifizierung von Datenbankbenutzern. Am Ende haben

83
00:06:44,570 --> 00:06:52,640
Sie gelernt, dass Sie ein Token an Ihre ausgehende Anfrage anhängen können, indem Sie einfach diese Authentifizierungsabfrage hinzufügen

84
00:06:52,760 --> 00:06:55,540
Parameter am Ende Ihrer Anforderungs-URL.

85
00:06:55,790 --> 00:06:59,690
Hier müssen wir also am Ende ein Fragezeichen hinzufügen, das gleich

86
00:07:00,080 --> 00:07:06,160
ist, und hier müssen wir unser Token haben. Wie können wir nun hier auf das Token zugreifen?

87
00:07:06,180 --> 00:07:12,790
Wir sind im Action Creator, was bedeutet, dass wir hier keinen einfachen Zugang zum

88
00:07:13,070 --> 00:07:20,390
Store haben, zum Redux Store oder nicht? Redux Thunk, dieses nette Paket, mit dem wir diese Syntax mit

89
00:07:20,390 --> 00:07:24,720
der Funktion schreiben können, die die Versandfunktion empfängt, die uns tatsächlich etwas Süßes gibt.

90
00:07:24,800 --> 00:07:30,860
Wir können diese Funktion auch ein wenig ändern und nicht nur den Versand erhalten, sondern auch ein zweites

91
00:07:30,860 --> 00:07:35,250
Argument. Dies ist eine weitere Funktion, die uns den Zugriff auf den Redux-Status

92
00:07:35,510 --> 00:07:43,230
ermöglicht, sodass wir Zugriff auf den aktuellen Status unseres Redux-Speichers erhalten. Wenn ich also das Ergebnis von get state hier auf der Konsole protokolliere,

93
00:07:43,230 --> 00:07:45,300
wollen wir sehen, was uns das

94
00:07:45,300 --> 00:07:51,860
bringt, und um Fehler zu vermeiden, füge ich hier im Moment einfach eine leere Zeichenfolge hinzu, damit wir diesen Code testen können.

95
00:07:51,870 --> 00:07:56,400
Natürlich wird dies nicht funktionieren, aber wir werden es bald beheben. Lassen Sie uns also sehen, was sich in diesem Zustand befindet, wenn wir dies

96
00:07:56,400 --> 00:07:56,700
ausführen.

97
00:08:00,000 --> 00:08:00,540
Also

98
00:08:00,570 --> 00:08:03,660
Zeit, sich ganz schnell wieder anzumelden und dann zum

99
00:08:04,550 --> 00:08:09,010
Admin-Bildschirm zu gehen und zu versuchen, dies zu bearbeiten, was natürlich immer noch fehlschlägt,

100
00:08:09,970 --> 00:08:13,300
aber das spielt keine Rolle, denn jetzt, wenn ich hier

101
00:08:13,420 --> 00:08:19,690
klicke, schlägt es fehl, aber was Sie sehen werden, ist das hier Im Protokoll erhalten wir eine vollständige Ausgabe

102
00:08:19,780 --> 00:08:22,270
unseres gesamten Redux-Stores. Dies ist

103
00:08:22,270 --> 00:08:28,570
unser Redux-Shop. Wir erhalten ein Objekt mit unserem Auth-Status-Slice, das ein weiteres Objekt

104
00:08:28,570 --> 00:08:34,880
mit unserem Token und der Benutzer-ID, unserem Karten-Status-Slice, unserem Bestell-Status-Slice und unserem Produkt-Status-Slice enthält.

105
00:08:34,960 --> 00:08:40,540
Auf diese Weise kann ich auf meinen Redux-Speicher zugreifen und auf das Token zugreifen, sodass das Token

106
00:08:40,540 --> 00:08:48,060
durch Ausführen von getState abgerufen werden kann. auth. Token, da dies uns Zugriff

107
00:08:48,070 --> 00:08:53,890
auf unseren vollständigen Redux-Speicher ermöglicht, erhalten wir dann Zugriff auf das Auth-Slice und dies auf

108
00:08:53,890 --> 00:08:59,810
die Token-Eigenschaft, die wir in diesem Auth-Slice verwalten. Und jetzt können wir

109
00:09:00,090 --> 00:09:09,440
im Produktaktionsersteller dieses Token hier am Ende hinzufügen. Hier können wir diesen String also einfach durch die Token-Variable ersetzen, die

110
00:09:09,440 --> 00:09:11,600
unser Token enthält. Wenn

111
00:09:11,600 --> 00:09:17,330
wir dies jetzt speichern, mit dieser kleinen Änderung, wenn wir uns jetzt erneut anmelden

112
00:09:17,390 --> 00:09:20,000
und später, ändern wir dies auch so,

113
00:09:20,000 --> 00:09:27,490
dass wir es nicht ständig brauchen Relogin, keine Sorge. Wenn wir uns erneut anmelden, gehen wir zu admin, klicken hier auf Hinzufügen und

114
00:09:27,710 --> 00:09:33,800
jetzt versuchen wir dies. Dies funktioniert erneut, da das Token jetzt angehängt wird. Firebase überprüft es und stellt fest, dass es gültig ist,

115
00:09:33,830 --> 00:09:35,890
da wir uns natürlich nicht damit vermischt

116
00:09:35,900 --> 00:09:39,170
haben , es ist ein gültiges Token und daher funktioniert dies einfach.

117
00:09:39,200 --> 00:09:43,190
Jetzt brauchen wir das Token nicht nur, wenn wir unsere Produkte aktualisieren, sondern

118
00:09:43,190 --> 00:09:48,410
auch, wenn wir ein neues Produkt hinzufügen. Also kopiere ich diese Logik und füge hier

119
00:09:48,410 --> 00:09:54,310
dieselbe Logik hinzu. Wenn wir ein Produkt erstellen, erhalte ich mein Token mit Hilfe des zweiten Arguments,

120
00:09:54,310 --> 00:09:56,330
das wir hier erhalten können,

121
00:09:56,440 --> 00:10:03,320
wenn wir es brauchen, der Funktion get state und dies ermöglicht es mir Ändern Sie diese einfachen Anführungszeichen in Back-Ticks, damit

122
00:10:03,320 --> 00:10:09,530
ich diesen Abfrageparameter hier am Ende mit einem Fragezeichen von gleich und gleich meinem Token bequem hinzufügen kann.

123
00:10:09,530 --> 00:10:15,300
Jetzt können wir ein Produkt erstellen und ein Produkt aktualisieren. Das Löschen ist natürlich auch

124
00:10:15,410 --> 00:10:22,430
eine Schreibanforderung. Zum Löschen von Produkten mache ich genau das Gleiche, erhalte hier Zugriff auf meinen Shop mit der Funktion

125
00:10:22,430 --> 00:10:29,130
"Status abrufen" und füge dann auch ein Fragezeichen hinzu von hier am Ende und fügen Sie den Token hinzu.

126
00:10:29,300 --> 00:10:30,290
Das ist also eine Sache.

127
00:10:30,320 --> 00:10:36,260
In den Bestellungen ist es ähnlich. Zum Abrufen benötigen wir es nicht, aber zum Hinzufügen tun wir es, weil

128
00:10:36,290 --> 00:10:38,260
das Hinzufügen eine Schreiboperation ist.

129
00:10:38,480 --> 00:10:45,110
Dort erhalten wir den Status, wenn wir möchten, wir können das Token mit dem gleichen Ansatz wie zuvor von dort extrahieren

130
00:10:45,110 --> 00:10:52,880
und wir können dies hier und da anhängen. Wir werden tatsächlich bald auch die Benutzer-ID benötigen, also werden wir uns darum kümmern Darüber in der

131
00:10:52,880 --> 00:10:54,860
nächsten Vorlesung, aber stellen Sie vorerst

132
00:10:54,860 --> 00:10:57,810
sicher, dass Sie den Token überall anhängen, und lassen

133
00:10:57,890 --> 00:11:02,570
Sie uns nun sehen, wie wir auch sicherstellen können, dass Bestellungen tatsächlich unserem Benutzer gehören.