L'oggetto user Firebase rappresenta un account utente che è stato firmato per un'app nel tuo progetto. In genere le app hanno molti utenti registrati e ogni app condivide un database utente.
Le istanze utente sono indipendenti dalle istanze Firebase Authentication, quindi puoi avere riferimenti a utenti diversi nello stesso contesto e richiamano comunque qualsiasi dei loro metodi.
Proprietà utente
Firebase utenti hanno un insieme fisso di proprietà di base, un valore univoco ID, un indirizzo email principale, un nome e l'URL di una foto, memorizzati nel del progetto, che può essere aggiornato dall'utente (iOS, Android, web). Non puoi aggiungere direttamente altre proprietà all'oggetto utente; puoi invece archiviare le proprietà aggiuntive in qualsiasi altro servizio di archiviazione, come Google Cloud Firestore
La prima volta che un utente si registra alla tua app, i dati del suo profilo vengono compilati utilizzando le informazioni disponibili:
- Se l'utente ha effettuato la registrazione con un indirizzo email e una password, solo l'indirizzo la proprietà dell'indirizzo email è compilata
- Se l'utente ha effettuato la registrazione con un provider di identità federato, come Google o Facebook, le informazioni sugli account rese disponibili dal provider vengono utilizzate per compilare il profilo dell'utente
- Se l'utente ha effettuato la registrazione con il tuo sistema di autenticazione personalizzato, devi aggiungere esplicitamente le informazioni che vuoi che il profilo dell'utente
Una volta creato un account utente, puoi ricaricare le informazioni dell'utente in incorporare eventuali modifiche apportate dall'utente su un altro dispositivo.
Provider di accesso
Puoi consentire agli utenti di accedere alle tue app utilizzando diversi metodi: indirizzo email e password, provider di identità federati e il tuo sistema di autenticazione personalizzato. Puoi associare più di un metodo di accesso a un utente, ad esempio: un utente può accedere allo stesso account utilizzando un indirizzo email e una password oppure usando Accedi con Google.
Le istanze utente monitorano tutti i fornitori collegati all'utente. Questo consente di per aggiornare le proprietà del profilo vuoto utilizzando le informazioni fornite da un provider. Consulta Gestione degli utenti (iOS, Android web).
L'utente corrente
Quando un utente si registra o esegue l'accesso, diventa l'utente corrente della Istanza di autenticazione. L'istanza mantiene lo stato dell'utente, di conseguenza l'aggiornamento pagina (in un browser) o il riavvio dell'applicazione non perde l'interfaccia utente informazioni.
Quando l'utente si disconnette, l'istanza Auth smette di mantenere un riferimento all'oggetto utente e non mantiene più il relativo stato; non è presente alcun utente corrente. Tuttavia, l'istanza utente continua a essere completamente funzionale: se mantieni un riferimento puoi comunque accedere ai dati dell'utente e aggiornarli.
Il ciclo di vita dell'utente
Il modo consigliato per monitorare lo stato corrente dell'istanza Auth è utilizzare gli ascoltatori (chiamati anche "osservatori" in JavaScript). Un listener Auth ottiene notificato ogni volta che accade qualcosa di pertinente all'oggetto Auth. Consulta la sezione Gestione Utenti (iOS, Android web).
Un listener Auth riceve una notifica nelle seguenti situazioni:
- L'oggetto Auth termina l'inizializzazione e un utente ha già eseguito l'accesso da un sessione precedente o che è stato reindirizzato dall'accesso di un provider di identità flusso
- Un utente accede (viene impostato l'utente corrente)
- Un utente si disconnette (l'utente corrente diventa nullo)
- Il token di accesso dell'utente corrente viene aggiornato. Questo caso può verificarsi
le seguenti condizioni:
- Il token di accesso scade. Si tratta di una situazione comune. Il token di aggiornamento viene utilizzato per ottenere un nuovo insieme valido di token.
- L'utente cambia la password: Firebase emette un nuovo accesso di aggiornamento e di aggiornamento, e il rendering dei vecchi token sono scaduti. Questa operazione viene eseguita automaticamente fa scadere il token dell'utente e/o disconnette l'utente su ogni dispositivo, ad per motivi di sicurezza.
- L'utente esegue nuovamente l'autenticazione: alcune azioni richiedono che le credenziali sono state emesse di recente; come l'eliminazione di un account, impostare un indirizzo email principale e cambiare una password. Anziché far uscire l'utente e farlo accedere di nuovo, ottieni nuove credenziali dall'utente e passale al metodo di autenticazione dell'oggetto utente.
Self-service per l'utente
Per impostazione predefinita, Firebase consente agli utenti di registrarsi ed eliminare i propri account senza intervento amministrativo. In molte circostanze, questo consente agli utenti finali di scoprire la tua applicazione o il tuo servizio e di eseguirne l'onboarding (o il logout) con il minimo sforzo.
Esistono però situazioni in cui vuoi che gli utenti vengano creati manualmente o tramite programmazione da un amministratore, utilizzando l'SDK Admin o la console Firebase. In questi casi, puoi disattivare le azioni degli utenti dalle Impostazioni di Firebase Authentication che impedisce la creazione e l'eliminazione di account da parte degli utenti finali. Se utilizzi l'architettura multi-tenancy, dovrai effettuare una richiesta HTTP per disattivare queste funzionalità per tenant.
Se un utente finale tenta di creare o eliminare un account all'interno del sistema,
Il servizio Firebase restituirà un codice di errore:
auth/admin-restricted-operation per le chiamate API web o ERROR_ADMIN_RESTRICTED_OPERATION per Android e iOS. Dovresti con eleganza
a gestire l'errore sul front-end chiedendo all'utente di adottare
azioni per il tuo servizio.
Token di autenticazione
Quando esegui l'autenticazione con Firebase, esistono tre tipi di token di autenticazione che potresti incontrare:
| Firebase token ID | Creato da Firebase quando un utente accede a un'app. Questi sono JWT firmati che identificano in modo sicuro Progetto Firebase. Questi token contengono informazioni di base sul profilo di un utente, inclusa la stringa ID dell'utente, che è univoca per il progetto Firebase. Poiché l'integrità dei token ID verificabili, puoi inviarli a un server di backend per identificare all'utente che ha eseguito l'accesso. |
| Token del provider di identità | Creati da provider di identità federati, come Google e Facebook. Questi token possono avere formati diversi, ma spesso si tratta di un accesso OAuth 2.0 di token. Le app utilizzano questi token per verificare che gli utenti abbiano autenticati con il provider di identità per poi convertirli in credenziali utilizzabili dai servizi Firebase. |
| Firebase token personalizzato | Creato dal tuo sistema di autorizzazione personalizzato per consentire agli utenti di accedere a un'app usando il tuo sistema di autenticazione. I token personalizzati sono JWT firmato utilizzando la chiave privata di un account di servizio. Le app usano questi token in modo molto simile a quelli restituiti dalle app o provider di identità federati. |
Indirizzi email verificati
Firebase considera un'email verificata se soddisfa due condizioni:
- L'utente completa il flusso di verifica Firebase
- L'email viene verificata da un provider di identità (o IdP) affidabile.
Gli IdP che verificano l'email una sola volta, ma poi consentono agli utenti di modificare l'indirizzo email senza richiedere una nuova verifica, non sono considerati attendibili. Gli IdP che possiedono il dominio o che richiedono sempre la verifica sono considerati attendibili.
Provider affidabili:
- Google (per gli indirizzi @gmail.com)
- Yahoo (per indirizzi @yahoo.com)
- Microsoft (per gli indirizzi @outlook.com e @hotmail.com)
- Apple (sempre verificato, perché gli account sono sempre verificati e autenticati a più fattori)
Provider non attendibili:
- GitHub
- Google, Yahoo e Microsoft per i domini non emessi dal provider di identità
- Email / password senza verifica email
In alcuni casi, Firebase collega automaticamente gli account quando un utente accede con provider diversi utilizzando lo stesso indirizzo email. Tuttavia, questo può accadere solo se vengono soddisfatti criteri specifici. Per capire il motivo, considera la seguente situazione: un utente accede utilizzando Google con un account @gmail.com e un utente malintenzionato crea un account utilizzando lo stesso indirizzo @gmail.com, ma accedendo tramite Facebook. Se questi due account venissero collegati automaticamente, il malintenzionato otterrebbe l’accesso all’account dell’utente.
I seguenti casi descrivono i casi in cui colleghiamo automaticamente gli account e quando viene restituito un errore che richiede un'azione da parte dell'utente o dello sviluppatore:
- L'utente accede con un fornitore non attendibile, quindi accede con un altro fornitore non attendibile con lo stesso indirizzo email (ad esempio Facebook seguito da GitHub). Viene visualizzato un errore che richiede il collegamento dell'account.
- L'utente accede con un fornitore attendibile, quindi accede con un fornitore non attendibile con lo stesso indirizzo email (ad esempio, Google seguito da Facebook). Viene visualizzato un errore che richiede il collegamento dell'account.
- L'utente accede con un provider non attendibile, quindi accede con un fornitore attendibile con lo stesso indirizzo email (ad esempio, Facebook seguito da Google). Il provider attendibile sovrascrive il provider non attendibile. Se l'utente tenta di accedere di nuovo con Facebook, verrà visualizzato un errore che richiede il collegamento dell'account.
- L'utente accede con un provider attendibile, quindi accede con un altro fornitore attendibile con lo stesso indirizzo email (ad esempio, Apple seguito da Google). Entrambi i fornitori verranno collegati senza errori.
Puoi impostare manualmente un'email come verificata utilizzando l'SDK Admin, ma ti consigliamo di eseguire questa operazione solo se sai che l'utente è davvero proprietario dell'email.