Ora è importante capire come funziona l'autenticazione perché se si dispone di uno sfondo di sviluppo Web, si
potrebbe essere abituati a far funzionare l'autenticazione in modo leggermente diverso.
Quindi abbiamo un server, Firebase nel nostro caso, ma quello può essere qualsiasi server con cui parliamo dalla
nostra app mobile React
Native e questo è il server che in genere ci autentica, quindi dove possiamo inviare l'e-mail e
la password immesse dall'utente per creare un nuovo utente o accedere a un utente,
quindi inviamo tali dati di autenticazione al server.
Ora il server risponde con qualcosa, ad esempio con un errore se le credenziali sono sbagliate o
con una risposta positiva se sono corrette e in un'applicazione Web tradizionale, un server memorizza anche una
cosiddetta sessione sul server e restituisce una chiave di sessione per il front-end, quindi per esempio
al browser che consente sostanzialmente al browser di scoprire che l'utente che utilizza questa
app in questo browser è autenticato.
Ora questo funziona in modo leggermente diverso per le app mobili perché lì, comunichi con server
che sono apolidi, ad esempio API RESTful o API GraphQL e lì non
hai davvero una sessione perché il server non si preoccupa dei singoli client, non
salva alcun dato sul fatto che tu sia autenticato o meno,
invece lavori con i cosiddetti token.
L'idea non è troppo lontana dall'idea della sessione.
Quando si accede e il server controlla l'e-mail e la password e determina che entrambi sono corretti, il server crea
un token, utilizza un certo algoritmo
e utilizza una chiave, una chiave privata che solo il server conosce. Questo token viene quindi restituito all'utente, quindi all'app,
ad esempio all'app mobile
React Native e lì puoi archiviare il token in un archivio, ad esempio nell'archivio
Redux, quindi in memoria, gestiscilo
con Redux in memoria mentre il tuo l'app è in esecuzione.
Ora, perché abbiamo bisogno di quel token? Per uno, finché abbiamo quel token, possiamo determinare nell'app mobile
che l'utente è probabilmente connesso e quindi inoltrarlo dalla schermata di autenticazione alla schermata dell'app principale
e così via e quando l'utente fa clic sul logout, noi eliminerebbe semplicemente quel token ma abbiamo
anche bisogno di quel token per qualcos'altro. Sul server, come ho già detto, in genere
abbiamo determinate risorse, determinati URL che sono esposti solo agli utenti che hanno effettuato l'accesso, quindi ad esempio nella
nostra app, la creazione di prodotti probabilmente non è qualcosa che tutti gli utenti dovrebbero essere in grado di fare
e quindi se si desidera inviare la richiesta a tale risorsa protetta, è necessario collegare quel token alla richiesta
in modo che il server che ha creato il token e che quindi possa verificare con quella chiave privata se il token
sia valido, in modo che il server possa determinare se si dispone di accesso o no.
Se si invia un token errato o un token non valido o nessun token, l'accesso verrà negato e si
riceverà un errore. Se si dispone di
un token valido e nuovamente il server è in grado di verificare se il token è valido o meno, verrà concesso
l'accesso e quindi è possibile accedere alle risorse, scrivere dati, qualunque esso sia.
Ecco come funziona l'autenticazione ed è
così che la implementeremo qui.
Ora la cosa buona è che Firebase che stiamo usando come backend fittizio ha già tutte le cose di gestione
degli utenti di creazione di token integrate, quindi non dobbiamo preoccuparci di ciò,
dobbiamo solo inviare le richieste giuste e quindi gestire quel token e siamo pronti per partire.