1
00:00:02,200 --> 00:00:08,050
Teraz ważne jest, aby zrozumieć, jak działa uwierzytelnianie, ponieważ jeśli masz doświadczenie w tworzeniu stron

2
00:00:08,050 --> 00:00:12,100
internetowych, możesz być przyzwyczajony do uwierzytelniania działającego nieco inaczej.

3
00:00:12,100 --> 00:00:17,910
Mamy więc serwer, w naszym przypadku Firebase, ale może to być dowolny serwer, z którym rozmawiamy

4
00:00:17,920 --> 00:00:19,570
z naszej aplikacji

5
00:00:19,570 --> 00:00:25,330
mobilnej React Native, a ten serwer zazwyczaj nas również uwierzytelnia, więc gdzie możemy wysłać wiadomość

6
00:00:25,330 --> 00:00:30,030
e-mail i hasło, które podał użytkownik aby utworzyć nowego użytkownika lub się

7
00:00:30,040 --> 00:00:32,940
zalogować, więc wysyłamy te dane uwierzytelniające na serwer.

8
00:00:32,940 --> 00:00:39,880
Teraz serwer reaguje czymś, na przykład z błędem, jeśli dane uwierzytelniające są niepoprawne lub z

9
00:00:39,880 --> 00:00:46,870
odpowiedzią powodzenia, jeśli są poprawne, a w tradycyjnej aplikacji internetowej serwer zapisuje również tak zwaną

10
00:00:46,870 --> 00:00:53,550
sesję na serwerze i zwraca klucz sesji do interfejsu, więc na przykład w przeglądarce,

11
00:00:53,560 --> 00:00:59,620
która zasadniczo pozwala przeglądarce dowiedzieć się, że użytkownik korzystający z tej aplikacji

12
00:00:59,620 --> 00:01:02,580
w tej przeglądarce jest uwierzytelniony.

13
00:01:02,590 --> 00:01:08,820
Teraz działa to nieco inaczej w przypadku aplikacji mobilnych, ponieważ tam komunikujesz się z serwerami, które

14
00:01:08,840 --> 00:01:13,640
są bezstanowe, na przykład API RESTful lub API GraphQL, a tam tak

15
00:01:13,930 --> 00:01:19,360
naprawdę nie masz sesji, ponieważ serwer nie dba o poszczególnych klientów, to nie zapisuje

16
00:01:19,420 --> 00:01:23,680
żadnych danych dotyczących tego, czy jesteś uwierzytelniony, czy nie, zamiast

17
00:01:24,280 --> 00:01:27,010
tego pracujesz z tak zwanymi tokenami.

18
00:01:27,010 --> 00:01:30,780
Pomysł nie jest zbyt daleko od idei sesji.

19
00:01:31,030 --> 00:01:36,250
Kiedy się zalogujesz, a serwer sprawdzi adres e-mail i hasło i stwierdzi, że oba są poprawne, serwer

20
00:01:36,850 --> 00:01:38,680
tworzy token, używa do tego

21
00:01:38,680 --> 00:01:45,430
określonego algorytmu i używa klucza, klucza prywatnego, który zna tylko serwer. Ten token jest następnie zwracany, więc do aplikacji,

22
00:01:45,430 --> 00:01:47,530
na przykład do aplikacji

23
00:01:47,530 --> 00:01:53,470
mobilnej React Native, i tam możesz przechowywać token w pewnej pamięci, na przykład w

24
00:01:53,860 --> 00:01:56,010
pamięci Redux, więc w pamięci,

25
00:01:56,020 --> 00:02:00,700
zarządzaj nim za pomocą Redux w pamięci, podczas gdy aplikacja działa.

26
00:02:00,910 --> 00:02:08,260
Dlaczego potrzebujemy tego tokena? Po pierwsze, o ile mamy ten token, możemy ustalić w

27
00:02:08,290 --> 00:02:13,780
aplikacji mobilnej, że użytkownik jest prawdopodobnie zalogowany, a zatem przekierować użytkownika z ekranu uwierzytelnienia na

28
00:02:13,780 --> 00:02:19,450
główny ekran aplikacji itd., A kiedy użytkownik kliknie wylogowanie, my po prostu usunę ten token, ale

29
00:02:20,110 --> 00:02:25,630
potrzebujemy go również do czegoś innego. Na serwerze, jak wspomniałem, zwykle mamy

30
00:02:25,690 --> 00:02:31,600
pewne zasoby, pewne adresy URL, które są widoczne tylko dla zalogowanych użytkowników, więc na przykład

31
00:02:31,690 --> 00:02:37,860
w naszej aplikacji tworzenie produktów prawdopodobnie nie jest czymś, co każdy użytkownik powinien być w

32
00:02:37,910 --> 00:02:43,720
stanie zrobić, a zatem jeśli chcesz wysłać żądanie do takiego chronionego zasobu, musisz dołączyć

33
00:02:43,720 --> 00:02:50,500
ten token do żądania, aby serwer, który utworzył token, a zatem mógł sprawdzić tym kluczem prywatnym, czy

34
00:02:50,500 --> 00:02:55,580
token jest prawidłowy, aby serwer mógł ustalić, czy masz dostęp czy nie.

35
00:02:55,660 --> 00:03:02,620
Jeśli wyślesz zły token lub nieprawidłowy token lub w ogóle go nie masz, dostęp zostanie zablokowany i

36
00:03:02,620 --> 00:03:05,090
otrzymasz błąd. Jeśli masz prawidłowy

37
00:03:05,110 --> 00:03:11,050
token i ponownie serwer jest w stanie sprawdzić, czy token jest ważny, czy nie, otrzymasz dostęp, dzięki

38
00:03:11,050 --> 00:03:14,970
czemu możesz uzyskać dostęp do zasobów, zapisać dane, cokolwiek to jest.

39
00:03:15,070 --> 00:03:17,430
Tak działa uwierzytelnianie i w ten

40
00:03:17,560 --> 00:03:19,560
sposób będziemy go tutaj wdrażać.

41
00:03:19,570 --> 00:03:25,390
Teraz dobrą rzeczą jest to, że Firebase, którego używamy jako sztuczny backend, ma już wbudowane wszystkie funkcje

42
00:03:25,390 --> 00:03:29,460
zarządzania użytkownikami do tworzenia tokenów, więc nie musimy się tym

43
00:03:29,560 --> 00:03:34,210
martwić, wystarczy wysłać odpowiednie żądania, a następnie zarządzać ten żeton i możemy iść.