In questa pagina viene spiegato in che modo Identity-Aware Proxy (IAP) gestisce una richiesta con una sessione scaduta e come assicurarsi che le richieste di app AJAX vengano completate.
Flusso di sessione IAP
Quando utilizza il flusso di accesso IAP standard, l'utente riceve un cookie di sessione che fa riferimento alla sua sessione di accesso a Google. IAP utilizza questo cookie per confermare che l'utente ha ancora eseguito l'accesso. IAP richiede l'accesso prima che l'utente acceda a un'app protetta da IAP.
Le sessioni IAP vengono aggiornate periodicamente. Tuttavia, se l'utente utilizza un Account Google per accedere, le sessioni IAP sono associate anche alla sessione di accesso di Google dell'utente. In questo caso, IAP richiederà all'utente di eseguire nuovamente l'accesso solo in una delle seguenti situazioni:
- L'utente ha disconnesso il proprio account
- Il suo account è stato sospeso
- È necessario reimpostare la password dell'account
Se un utente non ha eseguito l'accesso, IAP rileva una modifica dello stato dell'Account Google entro un paio di minuti. Una volta rilevato, IAP invalida la sessione.
IAP ricontrolla l'autorizzazione di Identity and Access Management (IAM) per tutte le richieste durante le sessioni valide. L'applicazione degli aggiornamenti al criterio di accesso IAM di un'app protetta da IAP potrebbe richiedere alcuni minuti.
Scadenza della sessione IAP
Per un flusso di accesso che utilizza un Account Google, la sessione IAP è associata alla sessione di accesso Google sottostante e scade solo quando la sessione scade indipendentemente dalla rivendicazione exp
nel JWT inviato nell'intestazione dell'autorizzazione.
Per l'autenticazione programmatica, IAP rispetta la rivendicazione exp
nel JWT inviato nell'intestazione Authorization.
Per il flusso di accesso di Identity Platform, la sessione IAP rimane valida per un massimo di un'ora dopo la disconnessione dell'utente.
Risposte sessione scadute
IAP restituisce risposte diverse per le sessioni scadute in base al tipo di richiesta.
Richieste non AJAX
Per le richieste non AJAX, l'utente viene reindirizzato al flusso di accesso per aggiornare la sessione. Se l'utente ha ancora eseguito l'accesso, il reindirizzamento è trasparente.
Richieste AJAX
IAP utilizza i cookie per gestire le sessioni degli utenti. Si basa anche su una sequenza di reindirizzamenti per definire una sessione come parte di un flusso di accesso. Non è sempre possibile stabilire una sessione se l'applicazione utilizza la condivisione delle risorse tra origini (CORS) per inviare richieste AJAX a un'applicazione protetta da IAP.
Per effettuare correttamente una richiesta CORS a un'applicazione con protezione IAP, è necessario stabilire una sessione IAP fuori banda. Tieni presente che per una richiesta AJAX che invia una richiesta CORS da
source_domain->target_domain
in cui target_domain
ospita
l'applicazione con protezione IAP, deve essere stabilita una sessione
su target_domain
. Non c'è modo di condividere cookie
tra source_domain
e target_domain
.
Una volta stabilita la sessione su target_domain
, lo sviluppatore deve abilitare l'invio delle credenziali nella richiesta. Per impostazione predefinita, i metodi JavaScript non collegano i cookie alle richieste. Per abilitare le credenziali nella richiesta, le richieste inviate con un oggetto XMLHttpRequest
devono avere la proprietà withCredentials
impostata su true, mentre le richieste inviate con l'opzione Fetch API
devono avere l'opzione credentials
impostata su include
o same-origin
.
La seguente guida consiglia un pattern per consentire agli sviluppatori web di stabilire e aggiornare correttamente una sessione IAP.
Informazioni sulla risposta IAP
Per le richieste AJAX, IAP restituisce un codice di stato HTTP 401: Unauthorized
. Tieni presente che il rilevamento delle richieste AJAX non può essere eseguito perfettamente. Se ricevi una risposta al codice di stato 302
anziché il codice di stato 401
alle richieste AJAX, puoi aggiungere alle richieste AJAX un'intestazione X-Requested-With
con valore "XMLHttpRequest"
. Questo indica a IAP che la richiesta proviene da JavaScript.
Gestione di una risposta AJAX 401
di HTTP
Per stabilire una sessione IAP dopo che l'applicazione ha ricevuto HTTP 401
, l'applicazione può aprire una nuova finestra per l'URL target_domain
+ ?gcp-iap-mode=DO_SESSION_REFRESH
. Si tratta di un gestore speciale che stabilisce solo la sessione IAP all'indirizzo target_domain
. Se la finestra viene mantenuta aperta, continuerà ad aggiornare la sessione periodicamente, chiedendo l'input dell'utente come richiesto.
Facoltativamente, l'utente può scegliere di chiudere la finestra e il gestore per lo stato HTTP 401
nel codice dello sviluppatore dovrebbe mostrare nuovamente una finestra popup per l'aggiornamento della sessione, in base alle necessità.
Passaggio 1: modifica il codice dell'app
L'esempio seguente mostra come modificare il codice dell'app per gestire il codice di stato HTTP 401
e fornire all'utente un link di aggiornamento della sessione:
Passaggio 2: installa un gestore onclick
Il seguente codice di esempio installa un gestore onclick che chiude la finestra dopo l'aggiornamento della sessione: