获取我们在 Firebase 峰会上发布的所有信息,了解 Firebase 可如何帮助您加快应用开发速度并满怀信心地运行应用。了解详情

Utenti nei progetti Firebase

L'oggetto utente Firebase rappresenta un account utente che si è registrato per un'app nel tuo progetto. Le app di solito hanno molti utenti registrati e ogni app in un progetto condivide un database utente.

Le istanze utente sono indipendenti dalle istanze Firebase Authentication, quindi puoi avere diversi riferimenti a utenti diversi all'interno dello stesso contesto e chiamare comunque uno qualsiasi dei loro metodi.

Proprietà utente

Gli utenti di Firebase hanno un insieme fisso di proprietà di base (un ID univoco, un indirizzo email principale, un nome e un URL della foto) memorizzate nel database utente del progetto, che può essere aggiornato dall'utente ( iOS , Android , web ). Non è possibile aggiungere direttamente altre proprietà all'oggetto utente; invece, puoi 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 profilo dell'utente vengono compilati utilizzando le informazioni disponibili:

  • Se l'utente si è registrato con un indirizzo e-mail e una password, viene popolata solo la proprietà dell'indirizzo e-mail principale
  • Se l'utente si è registrato con un provider di identità federato, come Google o Facebook, le informazioni sull'account rese disponibili dal provider vengono utilizzate per popolare il profilo dell'utente
  • Se l'utente si è registrato con il tuo sistema di autenticazione personalizzato, devi aggiungere esplicitamente le informazioni che desideri al profilo dell'utente

Una volta creato un account utente, puoi ricaricare le informazioni dell'utente per incorporare eventuali modifiche che l'utente potrebbe aver apportato su un altro dispositivo.

Provider di accesso

Puoi far accedere gli utenti alle tue app utilizzando diversi metodi: indirizzo e-mail 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 e-mail e una password oppure utilizzando Accedi con Google.

Le istanze utente tengono traccia di ogni provider collegato all'utente. Ciò consente di aggiornare le proprietà del profilo vuoto utilizzando le informazioni fornite da un provider. Vedere Gestione degli utenti ( iOS , Android , Web ).

L'utente corrente

Quando un utente si registra o accede, tale utente diventa l'utente corrente dell'istanza di Auth. L'istanza mantiene lo stato dell'utente, in modo che l'aggiornamento della pagina (in un browser) o il riavvio dell'applicazione non perdano le informazioni dell'utente.

Quando l'utente si disconnette, l'istanza Auth smette di mantenere un riferimento all'oggetto utente e non mantiene più il suo stato; non c'è nessun utente attuale. Tuttavia, l'istanza utente continua a essere completamente funzionante: se mantieni un riferimento ad essa, puoi comunque accedere e aggiornare i dati dell'utente.

Il ciclo di vita dell'utente

Il modo consigliato per tenere traccia dello stato corrente dell'istanza Auth consiste nell'utilizzare i listener (chiamati anche "osservatori" in JavaScript). Un ascoltatore Auth riceve una notifica ogni volta che accade qualcosa di rilevante all'oggetto Auth. Vedere Gestione degli utenti ( iOS , Android , Web ).

Un ascoltatore Auth riceve una notifica nelle seguenti situazioni:

  • L'oggetto Auth termina l'inizializzazione e un utente ha già effettuato l'accesso da una sessione precedente o è stato reindirizzato dal flusso di accesso di un provider di identità
  • Un utente effettua l'accesso (l'utente corrente è impostato)
  • Un utente si disconnette (l'utente corrente diventa nullo)
  • Il token di accesso dell'utente corrente viene aggiornato. Questo caso può verificarsi nelle seguenti condizioni:
    • Il token di accesso scade: questa è una situazione comune. Il token di aggiornamento viene utilizzato per ottenere un nuovo set di token valido.
    • L'utente cambia la propria password: Firebase emette nuovi token di accesso e aggiornamento e rende scaduti i vecchi token. Questo fa scadere automaticamente il token dell'utente e/o disconnette l'utente su ogni dispositivo, per motivi di sicurezza.
    • L'utente si autentica di nuovo: alcune azioni richiedono che le credenziali dell'utente siano state rilasciate di recente; tali azioni includono l'eliminazione di un account, l'impostazione di un indirizzo e-mail principale e la modifica di una password. Invece di disconnettere l'utente e quindi eseguire nuovamente l'accesso dell'utente, ottenere nuove credenziali dall'utente e passare le nuove credenziali al metodo di riautenticazione dell'oggetto utente.

Self-service dell'utente

Per impostazione predefinita, Firebase consente agli utenti di registrarsi ed eliminare i propri account senza intervento amministrativo. In molte circostanze, ciò consente agli utenti finali di scoprire la tua applicazione o il tuo servizio e inserirli (o disattivarli) con il minimo attrito.

Ci sono situazioni, tuttavia, in cui desideri che gli utenti vengano creati manualmente o in modo programmatico da un amministratore, utilizzando Admin SDK o la console Firebase. In questi casi, puoi disabilitare le azioni dell'utente dalla pagina Impostazioni di autenticazione Firebase , che impedisce la creazione e l'eliminazione dell'account da parte degli utenti finali. Se utilizzi la multi-tenancy, dovrai effettuare una richiesta HTTP per disabilitare queste funzionalità in base al tenant.

Se un utente finale tenta di creare o eliminare un account all'interno del tuo 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 gestire con garbo l'errore sul tuo front-end chiedendo all'utente di intraprendere le azioni appropriate per il tuo servizio.

Token di autenticazione

Quando esegui l'autenticazione con Firebase, ci sono tre tipi di token di autenticazione che potresti incontrare:

Token ID Firebase Creato da Firebase quando un utente accede a un'app. Questi token sono JWT firmati che identificano in modo sicuro un utente in un 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 può essere verificata , puoi inviarli a un server back-end per identificare l'utente attualmente connesso.
Token del provider di identità Creato da provider di identità federati, come Google e Facebook. Questi token possono avere formati diversi, ma spesso sono token di accesso OAuth 2.0. Le app utilizzano questi token per verificare che gli utenti si siano autenticati correttamente con il provider di identità, quindi li convertono in credenziali utilizzabili dai servizi Firebase.
Token personalizzati Firebase Creato dal tuo sistema di autenticazione personalizzato per consentire agli utenti di accedere a un'app utilizzando il tuo sistema di autenticazione. I token personalizzati sono JWT firmati utilizzando la chiave privata di un account di servizio . Le app utilizzano questi token in modo molto simile a quelli restituiti dai provider di identità federati.

Indirizzi email verificati

Firebase considera un'email verificata se soddisfa due condizioni:

  1. L'utente completa il flusso di verifica di Firebase
  2. L'e-mail viene verificata da un provider di identità affidabile, o IdP in breve.

Gli IdP che verificano l'e-mail una volta, ma poi consentono agli utenti di modificare gli indirizzi e-mail senza richiedere una nuova verifica, non sono attendibili. Gli IdP proprietari del dominio o che richiedono sempre la verifica sono considerati attendibili.

Fornitori affidabili:

  • Google (per 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)

Fornitori non affidabili:

  • Facebook
  • Cinguettio
  • Git Hub
  • Google, Yahoo e Microsoft per i domini non emessi da quel provider di identità
  • E-mail/password senza verifica e-mail

In alcune situazioni, Firebase collegherà automaticamente gli account quando un utente accede con provider diversi utilizzando lo stesso indirizzo email. Tuttavia, ciò può accadere solo quando vengono soddisfatti criteri specifici. Per comprenderne il motivo, considera la seguente situazione: un utente accede utilizzando Google con un account @gmail.com e un malintenzionato crea un account utilizzando lo stesso indirizzo @gmail.com, ma accedendo tramite Facebook. Se questi due account fossero collegati automaticamente, l'attore malintenzionato otterrebbe l'accesso all'account dell'utente.

I seguenti casi descrivono quando colleghiamo automaticamente gli account e quando generiamo un errore che richiede l'intervento dell'utente o dello sviluppatore:

  • L'utente accede con un provider non attendibile, quindi accede con un altro provider non attendibile con la stessa e-mail (ad esempio, Facebook seguito da GitHub). Questo genera un errore che richiede il collegamento dell'account.
  • L'utente accede con un provider attendibile, quindi accede con un provider non attendibile con la stessa email (ad esempio, Google seguito da Facebook). Questo genera un errore che richiede il collegamento dell'account.
  • L'utente accede con un provider non attendibile, quindi accede con un provider attendibile con la stessa email (ad esempio, Facebook seguito da Google). Il provider attendibile sovrascrive il provider non attendibile. Se l'utente tenta di accedere nuovamente con Facebook, causerà un errore che richiede il collegamento dell'account.
  • L'utente accede con un provider attendibile, quindi accede con un altro provider attendibile con la stessa email (ad esempio, Apple seguita da Google). Entrambi i fornitori saranno collegati senza errori.

Puoi impostare manualmente un'email come verificata utilizzando l'Admin SDK, ma ti consigliamo di farlo solo se sai che l'utente possiede effettivamente l'email.