1
00:00:02,200 --> 00:00:08,050
Ora è importante capire come funziona l'autenticazione perché se si dispone di uno sfondo di sviluppo Web, si

2
00:00:08,050 --> 00:00:12,100
potrebbe essere abituati a far funzionare l'autenticazione in modo leggermente diverso.

3
00:00:12,100 --> 00:00:17,910
Quindi abbiamo un server, Firebase nel nostro caso, ma quello può essere qualsiasi server con cui parliamo dalla

4
00:00:17,920 --> 00:00:19,570
nostra app mobile React

5
00:00:19,570 --> 00:00:25,330
Native e questo è il server che in genere ci autentica, quindi dove possiamo inviare l'e-mail e

6
00:00:25,330 --> 00:00:30,030
la password immesse dall'utente per creare un nuovo utente o accedere a un utente,

7
00:00:30,040 --> 00:00:32,940
quindi inviamo tali dati di autenticazione al server.

8
00:00:32,940 --> 00:00:39,880
Ora il server risponde con qualcosa, ad esempio con un errore se le credenziali sono sbagliate o

9
00:00:39,880 --> 00:00:46,870
con una risposta positiva se sono corrette e in un'applicazione Web tradizionale, un server memorizza anche una

10
00:00:46,870 --> 00:00:53,550
cosiddetta sessione sul server e restituisce una chiave di sessione per il front-end, quindi per esempio

11
00:00:53,560 --> 00:00:59,620
al browser che consente sostanzialmente al browser di scoprire che l'utente che utilizza questa

12
00:00:59,620 --> 00:01:02,580
app in questo browser è autenticato.

13
00:01:02,590 --> 00:01:08,820
Ora questo funziona in modo leggermente diverso per le app mobili perché lì, comunichi con server

14
00:01:08,840 --> 00:01:13,640
che sono apolidi, ad esempio API RESTful o API GraphQL e lì non

15
00:01:13,930 --> 00:01:19,360
hai davvero una sessione perché il server non si preoccupa dei singoli client, non

16
00:01:19,420 --> 00:01:23,680
salva alcun dato sul fatto che tu sia autenticato o meno,

17
00:01:24,280 --> 00:01:27,010
invece lavori con i cosiddetti token.

18
00:01:27,010 --> 00:01:30,780
L'idea non è troppo lontana dall'idea della sessione.

19
00:01:31,030 --> 00:01:36,250
Quando si accede e il server controlla l'e-mail e la password e determina che entrambi sono corretti, il server crea

20
00:01:36,850 --> 00:01:38,680
un token, utilizza un certo algoritmo

21
00:01:38,680 --> 00:01:45,430
e utilizza una chiave, una chiave privata che solo il server conosce. Questo token viene quindi restituito all'utente, quindi all'app,

22
00:01:45,430 --> 00:01:47,530
ad esempio all'app mobile

23
00:01:47,530 --> 00:01:53,470
React Native e lì puoi archiviare il token in un archivio, ad esempio nell'archivio

24
00:01:53,860 --> 00:01:56,010
Redux, quindi in memoria, gestiscilo

25
00:01:56,020 --> 00:02:00,700
con Redux in memoria mentre il tuo l'app è in esecuzione.

26
00:02:00,910 --> 00:02:08,260
Ora, perché abbiamo bisogno di quel token? Per uno, finché abbiamo quel token, possiamo determinare nell'app mobile

27
00:02:08,290 --> 00:02:13,780
che l'utente è probabilmente connesso e quindi inoltrarlo dalla schermata di autenticazione alla schermata dell'app principale

28
00:02:13,780 --> 00:02:19,450
e così via e quando l'utente fa clic sul logout, noi eliminerebbe semplicemente quel token ma abbiamo

29
00:02:20,110 --> 00:02:25,630
anche bisogno di quel token per qualcos'altro. Sul server, come ho già detto, in genere

30
00:02:25,690 --> 00:02:31,600
abbiamo determinate risorse, determinati URL che sono esposti solo agli utenti che hanno effettuato l'accesso, quindi ad esempio nella

31
00:02:31,690 --> 00:02:37,860
nostra app, la creazione di prodotti probabilmente non è qualcosa che tutti gli utenti dovrebbero essere in grado di fare

32
00:02:37,910 --> 00:02:43,720
e quindi se si desidera inviare la richiesta a tale risorsa protetta, è necessario collegare quel token alla richiesta

33
00:02:43,720 --> 00:02:50,500
in modo che il server che ha creato il token e che quindi possa verificare con quella chiave privata se il token

34
00:02:50,500 --> 00:02:55,580
sia valido, in modo che il server possa determinare se si dispone di accesso o no.

35
00:02:55,660 --> 00:03:02,620
Se si invia un token errato o un token non valido o nessun token, l'accesso verrà negato e si

36
00:03:02,620 --> 00:03:05,090
riceverà un errore. Se si dispone di

37
00:03:05,110 --> 00:03:11,050
un token valido e nuovamente il server è in grado di verificare se il token è valido o meno, verrà concesso

38
00:03:11,050 --> 00:03:14,970
l'accesso e quindi è possibile accedere alle risorse, scrivere dati, qualunque esso sia.

39
00:03:15,070 --> 00:03:17,430
Ecco come funziona l'autenticazione ed è

40
00:03:17,560 --> 00:03:19,560
così che la implementeremo qui.

41
00:03:19,570 --> 00:03:25,390
Ora la cosa buona è che Firebase che stiamo usando come backend fittizio ha già tutte le cose di gestione

42
00:03:25,390 --> 00:03:29,460
degli utenti di creazione di token integrate, quindi non dobbiamo preoccuparci di ciò,

43
00:03:29,560 --> 00:03:34,210
dobbiamo solo inviare le richieste giuste e quindi gestire quel token e siamo pronti per partire.