Diese Seite wurde von der Cloud Translation API übersetzt.

IAP-Sitzungen verwalten

Auf dieser Seite wird beschrieben, wie Identity-Aware Proxy (IAP) eine Anfrage mit einer abgelaufenen Sitzung verarbeitet und wie Sie dafür sorgen können, dass AJAX-Anwendungsanfragen und WebSocket-Anfragen erfolgreich ausgeführt werden.

IAP-Sitzungsablauf

Beim standardmäßigen IAP-Anmeldeablauf erhält der Nutzer ein Sitzungscookie, das auf seine Google-Anmeldesitzung verweist. IAP verwendet dieses Cookie, um zu prüfen, ob der Nutzer noch angemeldet ist. IAP erfordert, dass sich ein Nutzer anmeldet, bevor er auf eine mit IAP gesicherte Anwendung zugreift.

IAP-Sitzungen werden regelmäßig aktualisiert. Wenn der Nutzer jedoch ein Google-Konto für die Anmeldung verwendet, sind IAP-Sitzungen auch mit der Google-Anmeldesitzung des Nutzers verknüpft. In diesem Fall muss sich der Nutzer bei IAP nur in einer der folgenden Situationen neu anmelden:

Der Nutzer hat sich von seinem Konto abgemeldet.
Das Konto des Nutzers wurde gesperrt.
Für das Konto ist ein Zurücksetzen des Passworts erforderlich.

Wenn ein Nutzer abgemeldet ist, erfasst IAP innerhalb weniger Minuten den geänderten Status des Google-Kontos. Wenn der Status ermittelt ist, wird die Sitzung durch IAP ungültig gemacht.

IAP überprüft dann noch einmal die Identitäts- und Zugriffsverwaltung (Identity and Access Management, IAM) für alle Anfragen während gültiger Sitzungen. Es kann einige Minuten dauern, bis Änderungen an der IAM-Zugriffsrichtlinie einer mit IAP gesicherten Anwendung wirksam werden.

Abgelaufene IAP-Sitzungen

Bei einer Anmeldung mit einem Google-Konto ist die IAP-Sitzung an die zugrunde liegende Google-Anmeldesitzung gebunden. Sie läuft unabhängig von der exp-Anforderung im JWT, das im Autorisierungsheader gesendet wird, nur ab, wenn diese Sitzung abläuft.

Bei der programmatischen Authentifizierung berücksichtigt IAP die exp-Anforderung im JWT, die im Autorisierungsheader gesendet wird.

Bei der Identity Platform-Anmeldung bleibt die IAP-Sitzung bis zu eine Stunde lang gültig, nachdem der Nutzer sich abgemeldet hat.

WebSocket-Anfragen

IAP unterstützt WebSocket nur für erste Anfragen und prüft die Autorisierung nicht kontinuierlich. Wenn eine WebSocket-Anfrage empfangen wird, beginnt sie mit einer HTTP-Upgrade-Anfrage. IAP wertet dies als standardmäßige HTTP-GET-Anfrage aus. Nachdem die Anfrage autorisiert wurde, leitet IAP sie an den Server weiter und öffnet eine persistente Verbindung. Danach überwacht IAP die Anfragen nicht mehr und aktualisiert die Sitzung nicht.

Antworten bei abgelaufenen Sitzungen

IAP gibt bei abgelaufenen Sitzungen je nach der Art der Anfrage unterschiedliche Antworten zurück.

Nicht-AJAX-Anfragen

Bei Nicht-AJAX-Anfragen wird der Nutzer für das Aktualisieren der Sitzung zur Anmeldung weitergeleitet. Wenn er noch angemeldet ist, ist diese Weiterleitung transparent.

AJAX-Anfragen

In Chrome und anderen Browsern sind Drittanbieter-Cookies deaktiviert. Die Empfehlungen für AJAX-Anfragen auf dieser Seite funktionieren nicht, wenn Drittanbieter-Cookies deaktiviert sind. Die bereitgestellten Empfehlungen funktionieren jedoch weiterhin, wenn sowohl die Quelle als auch das Ziel der AJAX-Anfragen auf der selben Website liegen.

Eine Anleitung zum Verwalten von Drittanbieter-Cookies in Chrome finden Sie unter Cookies in Chrome löschen, zulassen und verwalten.

IAP verwendet Cookies, um Nutzersitzungen zu verwalten. Es basiert außerdem auf einer Reihe von Weiterleitungen, um im Rahmen einer Anmeldung eine Sitzung einzurichten. Das Erstellen einer Sitzung ist nicht immer möglich, wenn die Anwendung Cross-Origin Resource Sharing (CORS) verwendet, um AJAX-Anfragen an eine durch IAP gesicherte Anwendung zu senden.

Für das Senden einer CORS-Anfrage an eine mit IAP gesicherte Anwendung muss eine Out-of-Band-Sitzungseinheit eingerichtet werden. Beachten Sie, dass für eine AJAX-Anfrage, die eine CORS-Anfrage von source_domain->target_domain sendet, in der die target_domain die von IAP geschützte Anwendung hostet, auf der target_domain eine Sitzung eingerichtet sein muss. Es gibt keine Möglichkeit, Cookies zwischen source_domain und target_domain zu teilen.

Sobald die Sitzung auf der target_domain eingerichtet ist, muss der Entwickler die Anmeldedaten aktivieren, die in der Anfrage gesendet werden sollen. Bei JavaScript-Methoden werden Anfragen standardmäßig keine Cookies angehängt. Für die Aktivierung von Anmeldedaten in der Anfrage muss bei Anfragen, die mit einem XMLHttpRequest-Objekt gesendet werden, das Attribut withCredentials auf "true" gesetzt sein. Bei Anfragen, die hingegen mit der Fetch API gesendet werden, muss die Option credentials auf include oder same-origin gesetzt werden.

Im folgenden Leitfaden wird ein Muster für Webentwickler empfohlen, damit eine IAP-Sitzung erfolgreich eingerichtet und aktualisiert werden kann.

Informationen zur IAP-Antwort

Bei AJAX-Anfragen gibt IAP den HTTP-Statuscode 401: Unauthorized zurück. Beachten Sie, dass die AJAX-Anfrageerkennung nicht perfekt ist. Wenn Sie auf AJAX-Anfragen eine Statuscodeantwort vom Typ 302 anstelle des Statuscodes 401 erhalten, kann ein X-Requested-With-Header mit dem Wert "XMLHttpRequest" zu AJAX-Anfragen hinzugefügt werden. Damit wird IAP mitgeteilt, dass es sich um eine JavaScript-Anfrage handelt.

Verarbeitung einer HTTP `401`-AJAX-Antwort

Zur Einrichtung einer IAP-Sitzung, nachdem die Anwendung HTTP 401 empfangen hat, kann die Anwendung ein neues Fenster für die URL target_domain + ?gcp-iap-mode=DO_SESSION_REFRESH öffnen. Dies ist ein spezieller Handler, der nur die IAP-Sitzung unter target_domain einrichtet. Wenn das Fenster offen bleibt, wird es kontinuierlich aktualisiert, sodass Nutzereingaben bei Bedarf angefordert werden. Optional kann der Nutzer das Fenster schließen. Der Handler für den HTTP-Status 401 im Code des Entwicklers sollte dann ein neues Fenster öffnen, um die Sitzung zu aktualisieren.

Schritt 1: Anwendungscode ändern

Das folgende Beispiel zeigt, wie Sie den Anwendungscode so ändern, dass der HTTP-Statuscode 401 verarbeitet wird, und einen Link zur Sitzungsaktualisierung für den Nutzer bereitstellen:

if (response.status === 401) {
  statusElm.innerHTML = 'Login stale. <input type="button" value="Refresh" onclick="sessionRefreshClicked();"/>';
}

Schritt 2: onClick-Handler installieren

Der folgende Beispielcode installiert einen onClick-Handler, der das Fenster nach dem Aktualisieren der Sitzung schließt:

var iapSessionRefreshWindow = null;

function sessionRefreshClicked() {
  if (iapSessionRefreshWindow == null) {
    iapSessionRefreshWindow = window.open("/?gcp-iap-mode=DO_SESSION_REFRESH");
    window.setTimeout(checkSessionRefresh, 500);
  }
  return false;
}

function checkSessionRefresh() {
  if (iapSessionRefreshWindow != null && !iapSessionRefreshWindow.closed) {
    fetch('/favicon.ico').then(function(response) {
      if (response.status === 401) {
        window.setTimeout(checkSessionRefresh, 500);
      } else {
        iapSessionRefreshWindow.close();
        iapSessionRefreshWindow = null;
      }
    });
  } else {
    iapSessionRefreshWindow = null;
  }
}