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 einem Anmeldevorgang mit einem Google-Konto -Sitzung ist an die zugrunde liegende Google-Anmeldesitzung gebunden und läuft nur ab, wenn läuft diese Sitzung ab, unabhängig von der exp-Anforderung im JWT, das im Autorisierungsheader.

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 nur WebSocket für erste Anfragen die Autorisierung ständig zu überprüfen. Wenn eine WebSocket-Anfrage eingeht, beginnt mit einer HTTP-Upgrade-Anfrage. IAP bewertet dies als Standard-HTTP-Anfrage GET. Nach der Autorisierung der Anfrage wird IAP übergibt die Anfrage an den Server und öffnet eine dauerhafte Verbindung. Danach IAP überwacht die Anfragen nicht 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. Empfehlungen zum Stellen von AJAX-Anfragen auf dieser Seite funktionieren nicht, wenn Drittanbieter-Cookies deaktiviert sind. Die Empfehlungen funktionieren jedoch weiterhin, wenn sowohl die Quelle als auch das Ziel der AJAX-Anfragen stammen von derselben Website.

Eine Anleitung zum Verwalten von Drittanbieter-Cookies in Chrome finden Sie unter Löschen, erlauben oder ändern. und Cookies in Chrome 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;
  }
}