In questa pagina viene descritto in che modo Identity-Aware Proxy (IAP) gestisce una richiesta con una sessione scaduta e come assicurarsi che le richieste dell'app AJAX abbiano esito positivo.
Flusso di sessione IAP
Quando utilizza il flusso di accesso standard IAP, l'utente riceve un cookie di sessione che fa riferimento alla sua sessione di accesso di Google. IAP utilizza questo cookie per confermare che l'utente sia ancora connesso. IAP richiede all'utente di eseguire l'accesso prima di poter accedere a un'app protetta da IAP.
Le sessioni IAP vengono aggiornate periodicamente. Tuttavia, se l'utente utilizza un Account Google per accedere, anche le sessioni IAP sono legate alla sessione di accesso di Google dell'utente. In questo caso, IAP richiederà all'utente di accedere di nuovo solo in una delle seguenti situazioni:
- L'utente è uscito dal proprio account
- Il suo account è stato sospeso
- L'account richiede la reimpostazione della password
Se un utente è disconnesso, IAP rileva una modifica dello stato dell'Account Google entro un paio di minuti. Una volta rilevato, IAP annulla la sessione.
IAP controlla di nuovo l'autorizzazione IAM (Gestione di identità e accessi) per tutte le richieste durante le sessioni valide. Gli aggiornamenti a un criterio di accesso IAM di un'app protetta da IAP potrebbero richiedere alcuni minuti per diventare effettivi.
Scadenza sessione IAP
Per il flusso di accesso IAP degli Account Google, la sessione IAP è associata alla sessione di accesso Google sottostante e scade solo alla scadenza di tale sessione.
Per l'autenticazione programmatica, IAP rispetta la rivendicazione exp
del 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 è ancora connesso, il reindirizzamento è trasparente.
Richieste AJAX
IAP utilizza i cookie per gestire le sessioni degli utenti. Si basa anche su una sequenza di reindirizzamenti per stabilire una sessione come parte di un flusso di accesso. Non è sempre possibile stabilire una sessione se l'applicazione utilizza la condivisione multiorigine (CORS) per effettuare richieste AJAX a un'applicazione protetta da IAP.
Per effettuare correttamente una richiesta CORS a un'applicazione protetta da IAP, è necessario stabilire una sessione IAP al di fuori della 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 protetta da IAP, deve essere stabilita
una sessione su target_domain
. Non è possibile 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 allegano 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 per le richieste inviate con l'oggetto Fetch API
è necessaria l'opzione credentials
impostata su include
o same-origin
.
La seguente guida suggerisce un pattern con cui gli sviluppatori web possono 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 alla perfezione. Se ricevi una risposta del codice di stato 302
anziché un codice di stato 401
alle richieste AJAX, puoi aggiungere un'intestazione X-Requested-With
con valore "XMLHttpRequest"
alle richieste AJAX. Questo indica all'IAP che la richiesta proviene da JavaScript.
Gestione di una risposta AJAX 401
HTTP
Per stabilire una sessione IAP dopo che l'applicazione riceve
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 come aperta, continuerà ad aggiornare la sessione periodicamente, chiedendo l'input dell'utente in base alle necessità.
Facoltativamente, l'utente può scegliere di chiudere la finestra e il gestore per lo stato HTTP 401
nel codice sviluppatore dovrebbe visualizzare di nuovo una finestra popup per l'aggiornamento della sessione, come richiesto.
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 un link di aggiornamento alla sessione per l'utente:
Passaggio 2: installa un gestore onclick
Il seguente codice di esempio installa un gestore onclick che chiude la finestra dopo che la sessione è stata aggiornata: