Questa pagina descrive in che modo Identity-Aware Proxy (IAP) gestisce un con una sessione scaduta e come assicurarsi che l'applicazione AJAX e richieste WebSocket hanno esito positivo.
Flusso della sessione IAP
Quando utilizzi il flusso di accesso IAP standard, l'utente riceve un cookie di sessione che fa riferimento al suo accesso a Google durante la sessione. IAP utilizza questo cookie per confermare che l'utente è ancora connesso. IAP richiede all'utente di eseguire l'accesso prima di poter accedere a una app protetta da IAP.
Le sessioni IAP vengono aggiornate periodicamente. Tuttavia, se utente utilizza un account Google per accedere, le sessioni IAP sono legate anche alla piattaforma Google sessione di accesso. In questo caso, IAP richiederà solo all'utente di eseguire nuovamente l'accesso 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 non ha eseguito l'accesso, IAP rileva lo stato dell'Account Google modificherà entro un paio di minuti. Una volta rilevato, IAP la sessione viene invalidata.
IAP esegue di nuovo il controllo di Identity and Access Management (IAM) per tutte le richieste durante le sessioni valide. Aggiornamenti a un Criterio di accesso IAM dell'app con protezione IAP potrebbero essere necessari alcuni minuti prima che le modifiche diventino effettive.
Scadenza della sessione IAP
Per un flusso di accesso tramite un Account Google, l'IAP
è collegata alla sessione di accesso a Google sottostante e scade solo quando
la sessione scade indipendentemente dalla richiesta exp
nel JWT inviato
autorizzazione.
Per l'autenticazione programmatica,
IAP rispetta la richiesta di exp
nel JWT inviato
l'intestazione Autorizzazione.
Per il flusso di accesso a Identity Platform, la sessione IAP rimane valida per un massimo di un'ora dopo la disconnessione dell'utente.
Richieste WebSocket
IAP supporta solo WebSocket per le richieste iniziali e non
di controllare continuamente l'autorizzazione. Quando viene ricevuta una richiesta WebSocket,
inizia con una richiesta HTTP Upgrade
.
IAP lo valuta come un
richiesta GET
HTTP standard. Una volta autorizzata la richiesta, IAP
passa la richiesta al server, aprendo una connessione permanente. Dopodiché,
IAP non monitora le richieste né aggiorna la sessione.
Risposte di 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 a aggiorna la sessione. Se l'utente è ancora connesso, il reindirizzamento viene sono trasparenti.
Richieste AJAX
Chrome e altri browser stanno eliminando gradualmente cookie di terze parti. I consigli per effettuare richieste AJAX in questa pagina non funzionano se i cookie di terze parti sono disabilitate. Tuttavia, i consigli forniti rimarranno operativi se sia l'origine che la destinazione delle richieste AJAX provengono dallo stesso sito.
Per istruzioni sulla gestione dei cookie di terze parti in Chrome, consulta Eliminare, consentire e gestire i cookie in Chrome.
IAP si basa sui cookie per gestire le sessioni utente. Inoltre, utilizza una sequenza di reindirizzamenti per stabilire una sessione come parte di un accesso flusso di lavoro. Non è sempre possibile stabilire una sessione se utilizza la condivisione delle risorse tra origini (CORS) per rendere AJAX a un'applicazione protetta da IAP.
Inviare correttamente una richiesta CORS a un server protetto da 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
dove target_domain
ospita
un'applicazione protetta da IAP, deve esserci una sessione
stabilito in data target_domain
. Non è possibile condividere i cookie
tra source_domain
e target_domain
.
Una volta stabilita la sessione su target_domain
, lo sviluppatore deve
abilita l'invio delle credenziali nella richiesta. Per impostazione predefinita, i metodi JavaScript
non associano cookie alle richieste. Per abilitare le credenziali nella richiesta,
inviate con un
XMLHttpRequest
richiede che la proprietà withCredentials
sia impostata su true, mentre le richieste inviate
con
Fetch API
è necessario impostare l'opzione credentials
su include
o same-origin
.
La guida seguente consiglia un pattern per consentire agli sviluppatori web di stabilire e aggiornare una sessione IAP correttamente.
Comprensione della risposta IAP
Per le richieste AJAX, IAP restituisce un URL HTTP 401: Unauthorized
codice di stato. Tieni presente che il rilevamento delle richieste AJAX non può essere eseguito perfettamente. Se
Stai ricevendo una risposta del codice di stato 302
anziché un codice di stato 401
per
Richieste AJAX, un'intestazione X-Requested-With
con valore "XMLHttpRequest"
può essere aggiunto alle richieste AJAX. Questo indica a IAP che
la richiesta proviene da JavaScript.
Gestione di una risposta AJAX HTTP 401
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
. Questo è un
che stabilisce la sessione IAP soltanto su
target_domain
. Se la finestra
viene mantenuto aperto, continuerà ad aggiornare periodicamente la sessione, chiedendo
per input utente, come richiesto.
Facoltativamente, l'utente può scegliere di chiudere la finestra e il gestore
Lo stato HTTP 401
nel codice dello sviluppatore dovrebbe far apparire di nuovo una finestra per
aggiornare la sessione in base alle esigenze.
Passaggio 1: modifica il codice dell'app
L'esempio seguente mostra come modificare il codice dell'app per gestire
Codice di stato HTTP 401
e fornisci all'utente un link di aggiornamento della sessione:
Passaggio 2: installa un gestore src
Il codice campione riportato di seguito installa un gestore clic che chiude la finestra dopo la sessione viene aggiornata: