Teraz ważne jest, aby zrozumieć, jak działa uwierzytelnianie, ponieważ jeśli masz doświadczenie w tworzeniu stron
internetowych, możesz być przyzwyczajony do uwierzytelniania działającego nieco inaczej.
Mamy więc serwer, w naszym przypadku Firebase, ale może to być dowolny serwer, z którym rozmawiamy
z naszej aplikacji
mobilnej React Native, a ten serwer zazwyczaj nas również uwierzytelnia, więc gdzie możemy wysłać wiadomość
e-mail i hasło, które podał użytkownik aby utworzyć nowego użytkownika lub się
zalogować, więc wysyłamy te dane uwierzytelniające na serwer.
Teraz serwer reaguje czymś, na przykład z błędem, jeśli dane uwierzytelniające są niepoprawne lub z
odpowiedzią powodzenia, jeśli są poprawne, a w tradycyjnej aplikacji internetowej serwer zapisuje również tak zwaną
sesję na serwerze i zwraca klucz sesji do interfejsu, więc na przykład w przeglądarce,
która zasadniczo pozwala przeglądarce dowiedzieć się, że użytkownik korzystający z tej aplikacji
w tej przeglądarce jest uwierzytelniony.
Teraz działa to nieco inaczej w przypadku aplikacji mobilnych, ponieważ tam komunikujesz się z serwerami, które
są bezstanowe, na przykład API RESTful lub API GraphQL, a tam tak
naprawdę nie masz sesji, ponieważ serwer nie dba o poszczególnych klientów, to nie zapisuje
żadnych danych dotyczących tego, czy jesteś uwierzytelniony, czy nie, zamiast
tego pracujesz z tak zwanymi tokenami.
Pomysł nie jest zbyt daleko od idei sesji.
Kiedy się zalogujesz, a serwer sprawdzi adres e-mail i hasło i stwierdzi, że oba są poprawne, serwer
tworzy token, używa do tego
określonego algorytmu i używa klucza, klucza prywatnego, który zna tylko serwer. Ten token jest następnie zwracany, więc do aplikacji,
na przykład do aplikacji
mobilnej React Native, i tam możesz przechowywać token w pewnej pamięci, na przykład w
pamięci Redux, więc w pamięci,
zarządzaj nim za pomocą Redux w pamięci, podczas gdy aplikacja działa.
Dlaczego potrzebujemy tego tokena? Po pierwsze, o ile mamy ten token, możemy ustalić w
aplikacji mobilnej, że użytkownik jest prawdopodobnie zalogowany, a zatem przekierować użytkownika z ekranu uwierzytelnienia na
główny ekran aplikacji itd., A kiedy użytkownik kliknie wylogowanie, my po prostu usunę ten token, ale
potrzebujemy go również do czegoś innego. Na serwerze, jak wspomniałem, zwykle mamy
pewne zasoby, pewne adresy URL, które są widoczne tylko dla zalogowanych użytkowników, więc na przykład
w naszej aplikacji tworzenie produktów prawdopodobnie nie jest czymś, co każdy użytkownik powinien być w
stanie zrobić, a zatem jeśli chcesz wysłać żądanie do takiego chronionego zasobu, musisz dołączyć
ten token do żądania, aby serwer, który utworzył token, a zatem mógł sprawdzić tym kluczem prywatnym, czy
token jest prawidłowy, aby serwer mógł ustalić, czy masz dostęp czy nie.
Jeśli wyślesz zły token lub nieprawidłowy token lub w ogóle go nie masz, dostęp zostanie zablokowany i
otrzymasz błąd. Jeśli masz prawidłowy
token i ponownie serwer jest w stanie sprawdzić, czy token jest ważny, czy nie, otrzymasz dostęp, dzięki
czemu możesz uzyskać dostęp do zasobów, zapisać dane, cokolwiek to jest.
Tak działa uwierzytelnianie i w ten
sposób będziemy go tutaj wdrażać.
Teraz dobrą rzeczą jest to, że Firebase, którego używamy jako sztuczny backend, ma już wbudowane wszystkie funkcje
zarządzania użytkownikami do tworzenia tokenów, więc nie musimy się tym
martwić, wystarczy wysłać odpowiednie żądania, a następnie zarządzać ten żeton i możemy iść.