Einbettung ohne Cookies

Wenn Looker mithilfe von signierten Einbettungen in einen iFrame eingebettet wird, verwenden einige Browser standardmäßig eine Cookie-Richtlinie, die Drittanbieter-Cookies blockiert. Drittanbieter-Cookies werden abgelehnt, wenn der eingebettete iFrame von einer Domain geladen wird, die sich von der Domain unterscheidet, über die die Einbettungsanwendung geladen wird. Sie können diese Einschränkung in der Regel umgehen, indem Sie eine benutzerdefinierte Domain anfordern und verwenden. In einigen Fällen können Vanity-Domains jedoch nicht verwendet werden. Für diese Szenarien kann die cookielose Einbettung von Looker verwendet werden.

Hinweis :Eine Liste der von Looker verwendeten Cookies finden Sie auf der Dokumentationsseite Looker-Cookieliste.

Wie funktioniert das Einbetten ohne Cookies?

Wenn Drittanbieter-Cookies nicht blockiert werden, wird ein Sitzungscookie erstellt, wenn sich ein Nutzer zum ersten Mal in Looker anmeldet. Dieses Cookie wird mit jeder Nutzeranfrage gesendet und der Looker-Server verwendet es, um die Identität des Nutzers zu ermitteln, der die Anfrage initiiert hat. Wenn Cookies blockiert werden, wird das Cookie nicht mit einer Anfrage gesendet. Der Looker-Server kann den Nutzer, der mit der Anfrage verknüpft ist, also nicht identifizieren.

Um dieses Problem zu beheben, werden bei der cookielosen Einbettung in Looker jedem Request Tokens zugeordnet, mit denen die Nutzersitzung auf dem Looker-Server neu erstellt werden kann. Es liegt in der Verantwortung der einbettenden Anwendung, diese Tokens abzurufen und der Looker-Instanz zur Verfügung zu stellen, die im eingebetteten iFrame ausgeführt wird. Wie Sie diese Tokens erhalten und bereitstellen, wird im Rest dieses Dokuments beschrieben.

Wichtig :Looker bietet zwei APIs für das Einbetten: das Looker Embed SDK und eine JavaScript-basierte API window.postMessage. Die cookielose Einbettung von Looker funktioniert für beide APIs. Das Looker Embed SDK vereinfacht die Interaktion des Einbettungsclients mit dem Looker-iFrame. In diesem Dokument finden Sie jedoch Beispiele für die Verwendung der window.postMessage API. Die Looker Cookieless Embed API unterscheidet sich von der Looker Signed Embed URL Signing API und erfordert eine andere Verarbeitung auf dem Einbettungsanwendungsserver. Die Looker-API zum Signieren von eingebetteten URLs und die Looker-API für eingebettete Inhalte ohne Cookies können gleichzeitig verwendet werden. Jeder einzelne Nutzer muss jedoch nur eine der beiden Methoden verwenden.

Damit Sie eine der beiden APIs verwenden können, muss sich die Einbettungsanwendung mit Administratorberechtigungen bei der Looker API authentifizieren können. Die Einbettungsdomain muss entweder in der Zulassungsliste für Einbettungsdomains aufgeführt sein oder, wenn Sie Looker 23.8 oder höher verwenden, kann die Einbettungsdomain eingeschlossen werden, wenn die sitzungslose Sitzung abgerufen wird.

Looker-Einbettungs-iFrame erstellen

Das folgende Sequenzdiagramm veranschaulicht das Erstellen eines Einbettungs-iFrames. Mehrere iFrames können entweder gleichzeitig oder zu einem späteren Zeitpunkt generiert werden. Bei korrekter Implementierung wird das Iframe automatisch der Sitzung beigetreten, die vom ersten Iframe erstellt wurde. Das Looker Embed SDK vereinfacht diesen Prozess, da es automatisch der vorhandenen Sitzung beitritt.

1. Der Nutzer führt in der Einbettungsanwendung eine Aktion aus, die zur Erstellung eines Looker-iFrames führt.
2. Der Client der Einbettungsanwendung ruft eine Looker-Sitzung ab. Das Looker Embed SDK kann verwendet werden, um diese Sitzung zu starten. Es muss jedoch eine Endpunkt-URL oder eine Callback-Funktion angegeben werden. Wenn eine Callback-Funktion verwendet wird, ruft sie den Server der Einbettungsanwendung auf, um die Looker-Einbettungssitzung abzurufen. Andernfalls wird die angegebene Endpunkt-URL vom Embed SDK aufgerufen.
3. Der Einbettungsanwendungsserver verwendet die Looker API, um eine Einbettungssitzung abzurufen. Dieser API-Aufruf ähnelt dem Signaturprozess für signierte Looker-Einbettungen, da er die Definition des eingebetteten Nutzers als Eingabe akzeptiert. Wenn für den aufrufenden Nutzer bereits eine Looker-Einbettungssitzung vorhanden ist, sollte das zugehörige Sitzungsreferenztoken im Aufruf enthalten sein. Dies wird im Abschnitt Sitzung erfassen dieses Dokuments genauer erläutert.
4. Die Verarbeitung des Endpunkts zum Abrufen einer Einbettungssitzung ähnelt dem signierten /login/embed/(signed url)-Endpunkt, da die Definition des eingebetteten Looker-Nutzers als Text der Anfrage und nicht in der URL erwartet wird. Beim Endpunkt zum Abrufen der Einbettungssitzung wird der eingebettete Nutzer validiert und dann erstellt oder aktualisiert. Es kann auch ein vorhandenes Sitzungsreferenz-Token akzeptieren. Das ist wichtig, da mehrere eingebettete Looker-iFrames dieselbe Sitzung verwenden können. Der eingebettete Nutzer wird nicht aktualisiert, wenn ein Sitzungsreferenztoken angegeben wird und die Sitzung noch nicht abgelaufen ist. So wird der Anwendungsfall unterstützt, in dem ein iFrame mit einer signierten Einbettungs-URL und andere iFrames ohne eine signierte Einbettungs-URL erstellt werden. In diesem Fall erben die iFrames ohne signierte Einbettungs-URLs das Cookie aus der ersten Sitzung.
5. Der Looker API-Aufruf gibt vier Tokens zurück, die jeweils eine Gültigkeitsdauer (Time to Live, TTL) haben:
   • Autorisierungstoken (TTL = 30 Sekunden)
   • Navigationstoken (Gültigkeitsdauer = 10 Minuten)
   • API-Token (Gültigkeitsdauer = 10 Minuten)
   • Sitzungsreferenztoken (TTL = verbleibende Lebensdauer der Sitzung)
6. Der Server der Einbettungsanwendung muss die von den Looker-Daten zurückgegebenen Daten im Blick behalten und sie sowohl dem aufrufenden Nutzer als auch dem User-Agent des Browsers des aufrufenden Nutzers zuordnen. Vorschläge dazu finden Sie in diesem Dokument im Abschnitt Tokens generieren. Bei diesem Aufruf werden das Autorisierungstoken, ein Navigationstoken und ein API-Token sowie alle zugehörigen TTLs zurückgegeben. Das Sitzungsreferenztoken sollte geschützt und nicht im aufrufenden Browser verfügbar gemacht werden.

7. Sobald die Tokens an den Browser zurückgegeben wurden, muss eine Looker-Einbettungs-Anmelde-URL erstellt werden. Das Looker Embed SDK erstellt die Einbettungs-Anmelde-URL automatisch. Informationen zur Verwendung der windows.postMessage API zum Erstellen der Einbettungs-Anmelde-URL finden Sie in diesem Dokument im Abschnitt Looker windows.postMessage API verwenden.

   Die Log-in-URL enthält nicht die Details des signierten eingebetteten Nutzers. Sie enthält den Ziel-URI, einschließlich des Navigationstokens, und das Autorisierungstoken als Abfrageparameter. Das Autorisierungstoken muss innerhalb von 30 Sekunden verwendet werden und kann nur einmal verwendet werden. Wenn zusätzliche iFrames erforderlich sind, muss eine neue Einbettungssitzung gestartet werden. Wenn das Sitzungsreferenztoken angegeben wird, wird das Autorisierungstoken jedoch derselben Sitzung zugeordnet.

8. Der Looker-Einbettungsanmeldeendpunkt bestimmt, ob die Anmeldung für die cookielose Einbettung erfolgt. Dies wird durch das Vorhandensein des Autorisierungstokens angegeben. Wenn das Autorisierungstoken gültig ist, wird Folgendes geprüft:

   • Die zugehörige Sitzung ist noch gültig.
   • Der zugehörige Einbettungsnutzer ist weiterhin gültig.
   • Der Browser-User-Agent, der der Anfrage zugeordnet ist, stimmt mit dem Browser-User-Agent überein, der der Sitzung zugeordnet ist.

9. Wenn die Prüfungen aus dem vorherigen Schritt erfolgreich sind, wird die Anfrage über den Ziel-URI, der in der URL enthalten ist, weitergeleitet. Das Verfahren ist dasselbe wie für die Anmeldung für eingebettete Looker-Inhalte mit Signatur.

10. Diese Anfrage ist die Weiterleitung zum Starten des Looker-Dashboards. Diese Anfrage enthält das Navigationstoken als Parameter.

11. Bevor der Endpunkt ausgeführt wird, sucht der Looker-Server in der Anfrage nach dem Navigationstoken. Wenn der Server das Token findet, prüft er Folgendes:

    • Die zugehörige Sitzung ist noch gültig.
    • Der Browser-User-Agent, der der Anfrage zugeordnet ist, stimmt mit dem Browser-User-Agent überein, der der Sitzung zugeordnet ist.

    Wenn die Sitzung gültig ist, wird sie für die Anfrage wiederhergestellt und die Dashboard-Anfrage wird ausgeführt.

12. Das HTML zum Laden des Dashboards wird an den iFrame zurückgegeben.

13. Die Looker-Benutzeroberfläche, die im iFrame ausgeführt wird, stellt fest, dass das Dashboard-HTML eine cookieless-Einbettungsantwort ist. Die Looker-Benutzeroberfläche sendet dann eine Nachricht an die Einbettungsanwendung, um die in Schritt 6 abgerufenen Tokens anzufordern. Die Benutzeroberfläche wartet dann, bis sie die Tokens empfängt. Wenn die Tokens nicht eingehen, wird eine Meldung angezeigt.

14. Die Einbettungsanwendung sendet die Tokens an den eingebetteten Looker-iFrame.

15. Wenn die Tokens empfangen werden, startet die Looker-Benutzeroberfläche, die im iFrame ausgeführt wird, den Prozess zum Rendern des Anfrageobjekts. Während dieses Vorgangs werden API-Aufrufe an den Looker-Server gesendet. Das im Schritt 15 empfangene API-Token wird automatisch als Header in alle API-Anfragen eingefügt.

16. Bevor ein Endpunkt ausgeführt wird, sucht der Looker-Server in der Anfrage nach dem API-Token. Wenn der Server das Token findet, prüft er Folgendes:

    • Die zugehörige Sitzung ist noch gültig.
    • Der Browser-User-Agent, der der Anfrage zugeordnet ist, stimmt mit dem Browser-User-Agent überein, der der Sitzung zugeordnet ist.

    Wenn die Sitzung gültig ist, wird sie für die Anfrage wiederhergestellt und die API-Anfrage wird ausgeführt.

17. Dashboard-Daten werden zurückgegeben.

18. Das Dashboard wird gerendert.

19. Der Nutzer hat die Kontrolle über das Dashboard.

Neue Tokens generieren

Das folgende Sequenzdiagramm veranschaulicht die Generierung neuer Tokens.

1. Die Looker-Benutzeroberfläche, die im eingebetteten iFrame ausgeführt wird, überwacht die TTL der Einbettungstokens.
2. Wenn die Tokens ablaufen, sendet die Looker-Benutzeroberfläche eine Aktualisierungstoken-Nachricht an den Client der Einbettungsanwendung.
3. Der Client der Einbettungsanwendung fordert dann neue Tokens von einem Endpunkt an, der auf dem Server der Einbettungsanwendung implementiert ist. Das Looker Embed SDK fordert automatisch neue Tokens an. Dazu muss jedoch die Endpunkt-URL oder eine Callback-Funktion angegeben werden. Wenn die Callback-Funktion verwendet wird, ruft sie den Anwendungsserver auf, um neue Tokens zu generieren. Andernfalls wird die angegebene Endpunkt-URL vom Embed SDK aufgerufen.
4. Die Einbettungsanwendung sucht nach dem session_reference_token, das der Einbettungssitzung zugeordnet ist. Im Beispiel im Looker Embed SDK-Git-Repository werden Sitzungscookies verwendet. Es kann aber auch ein verteilter serverseitiger Cache wie Redis verwendet werden.
5. Der Anwendungsserver für Einbettungen ruft den Looker-Server mit einer Anfrage zum Generieren von Tokens auf. Für diese Anfrage sind neben dem User-Agent des Browsers, der die Anfrage initiiert hat, auch aktuelle API- und Navigationstokens erforderlich.
6. Der Looker-Server validiert den User-Agent, das Sitzungsreferenz-Token, das Navigationstoken und das API-Token. Wenn die Anfrage gültig ist, werden neue Tokens generiert.
7. Die Tokens werden an den aufrufenden Server der Einbettungsanwendung zurückgegeben.
8. Der Server der Einbettungsanwendung entfernt das Sitzungsreferenztoken aus der Antwort und gibt die verbleibende Antwort an den Client der Einbettungsanwendung zurück.
9. Der Client der Einbettungsanwendung sendet die neu generierten Tokens an die Looker-Benutzeroberfläche. Das Looker Embed SDK erledigt das automatisch. Einbettungsanwendungsclients, die die windows.postMessage API verwenden, sind für das Senden der Tokens verantwortlich. Sobald die Looker-Benutzeroberfläche die Tokens empfängt, werden sie in nachfolgenden API-Aufrufen und Seitenaufrufen verwendet.

Einbettung ohne Cookies in Looker implementieren

Die cookielose Einbettung von Looker kann entweder mit dem Looker Embed SDK oder der windows.postMessage API implementiert werden. Sie können die Methode Looker Embed SDK verwenden. Es ist aber auch ein Beispiel für die Verwendung der windows.postMessage API verfügbar. Detaillierte Erläuterungen zu beiden Implementierungen finden Sie in der README-Datei für das Looker Embed SDK. Das Git-Repository für das Embed SDK enthält auch funktionierende Implementierungen.

Looker-Instanz konfigurieren

Die Einbettung ohne Cookies ähnelt der signierten Einbettung in Looker. Damit die cookielose Einbettung verwendet werden kann, muss ein Administrator Embed SSO Authentication aktivieren. Im Gegensatz zu Looker-Einbettungen mit Signatur wird bei Cookieless Embedding jedoch nicht die Einstellung Einbettungs-Secret verwendet. Beim cookielosen Einbetten wird ein JSON Web Token (JWT) in Form der Einstellung JWT-Secret für Einbettung verwendet, die im Admin-Menü im Bereich Plattform auf der Seite „Einbetten“ festgelegt oder zurückgesetzt werden kann.

Das Festlegen des JWT-Secrets ist nicht erforderlich, da das JWT beim ersten Versuch, eine sitzungslose Einbettung zu erstellen, generiert wird. Setzen Sie dieses Token nicht zurück, da dadurch alle aktiven cookieless-Einbettungssitzungen ungültig werden.

Im Gegensatz zum Einbettungs-Secret wird das Einbettungs-JWT-Secret nie offengelegt, da es nur intern auf dem Looker-Server verwendet wird.

Implementierung des Anwendungsclients

Dieser Abschnitt enthält Beispiele für die Implementierung des cookielosen Einbettens im Anwendungsclient und die folgenden Unterabschnitte:

• Looker Embed SDK installieren und aktualisieren
• Looker Embed SDK verwenden
• Looker windows.postMessage API verwenden

Looker Embed SDK installieren oder aktualisieren

Die folgenden Looker SDK-Versionen sind für die Verwendung der cookielosen Einbettung erforderlich:

@looker/embed-sdk >= 2.0.0
@looker/sdk >= 22.16.0

Looker Embed SDK verwenden

Dem Embed SDK wurde eine neue Initialisierungsmethode hinzugefügt, um die cookieless Sitzung zu starten. Diese Methode akzeptiert entweder zwei URL-Strings oder zwei Callback-Funktionen. Die URL-Strings sollten auf Endpunkte auf dem Server der Einbettungsanwendung verweisen. Implementierungsdetails dieser Endpunkte auf dem Anwendungsserver werden im Abschnitt Anwendungsserver implementieren dieses Dokuments behandelt.

getEmbedSDK().initCookieless(
  runtimeConfig.lookerHost,
  '/acquire-embed-session',
  '/generate-embed-tokens'
)

Das folgende Beispiel zeigt, wie Callbacks verwendet werden. Callbacks sollten nur verwendet werden, wenn die eingebettete Clientanwendung den Status der Looker-Einbettungssitzung kennen muss. Sie können auch das session:status-Ereignis verwenden. In diesem Fall sind keine Rückrufe mit dem Embed SDK erforderlich.

Hinweis :Der folgende Code ist ein Beispiel. Eine ähnliche Implementierung ist erforderlich. Bei dieser Implementierung werden api_token und nav_token im Client gespeichert und Daten mit der Methode PUT an den Server gesendet. Eine alternative Implementierung besteht darin, api_token und nav_token in Sitzungsdaten zu speichern, sodass der Client eine GET-Methode verwenden kann. Im Beispielcode im GitHub-Repository für das Embed SDK wird der zweite Mechanismus verwendet.

const acquireEmbedSessionCallback =
  async (): Promise<LookerEmbedCookielessSessionData> => {
    const resp = await fetch('/acquire-embed-session')
    if (!resp.ok) {
      console.error('acquire-embed-session failed', { resp })
      throw new Error(
        `acquire-embed-session failed: ${resp.status} ${resp.statusText}`
      )
    }
    return (await resp.json()) as LookerEmbedCookielessSessionData
  }

const generateEmbedTokensCallback =
  async ({ api_token, navigation_token }): Promise<LookerEmbedCookielessSessionData> => {
    const resp = await fetch('/generate-embed-tokens', {
      method: 'PUT',
      headers: { 'content-type': 'application/json' },
      body: JSON.stringify({ api_token, navigation_token }),
    })
    if (!resp.ok) {
      console.error('generate-embed-tokens failed', { resp })
      throw new Error(
        `generate-embed-tokens failed: ${resp.status} ${resp.statusText}`
      )
    }
    return (await resp.json()) as LookerEmbedCookielessSessionData
  }

getEmbedSDK().initCookieless(
  runtimeConfig.lookerHost,
  acquireEmbedSessionCallback,
  generateEmbedTokensCallback
)

Looker windows.postMessage API verwenden

Ein detailliertes Beispiel für die Verwendung der windows.postMessage API finden Sie in den Dateien message_example.ts und message_utils.ts im Embed SDK-Git-Repository. Die Highlights des Beispiels werden hier beschrieben.

Das folgende Beispiel zeigt, wie die URL für den iFrame erstellt wird. Die Callback-Funktion ist mit dem acquireEmbedSessionCallback-Beispiel identisch, das wir uns bereits angesehen haben.

  private async getCookielessLoginUrl(): Promise<string> {
    const { authentication_token, navigation_token } =
      await this.embedEnvironment.acquireSession()
    const url = this.embedUrl.startsWith('/embed')
      ? this.embedUrl
      : `/embed${this.embedUrl}`
    const embedUrl = new URL(url, this.frameOrigin)
    if (!embedUrl.searchParams.has('embed_domain')) {
      embedUrl.searchParams.set('embed_domain', window.location.origin)
    }
    embedUrl.searchParams.set('embed_navigation_token', navigation_token)
    const targetUri = encodeURIComponent(
      `${embedUrl.pathname}${embedUrl.search}${embedUrl.hash}`
    )
    return `${embedUrl.origin}/login/embed/${targetUri}?embed_authentication_token=${authentication_token}`
  }

Das folgende Beispiel zeigt, wie Sie auf Tokenanfragen warten, neue Tokens generieren und sie an Looker senden. Die Callback-Funktion ist mit dem vorherigen generateEmbedTokensCallback-Beispiel identisch.

      this.on(
        'session:tokens:request',
        this.sessionTokensRequestHandler.bind(this)
      )

  private connected = false

  private async sessionTokensRequestHandler(_data: any) {
    const contentWindow = this.getContentWindow()
    if (contentWindow) {
      if (!this.connected) {
        // When not connected the newly acquired tokens can be used.
        const sessionTokens = this.embedEnvironment.applicationTokens
        if (sessionTokens) {
          this.connected = true
          this.send('session:tokens', this.embedEnvironment.applicationTokens)
        }
      } else {
        // If connected, the embedded Looker application has decided that
        // it needs new tokens. Generate new tokens.
        const sessionTokens = await this.embedEnvironment.generateTokens()
        this.send('session:tokens', sessionTokens)
      }
    }
  }

  send(messageType: string, data: any = {}) {
    const contentWindow = this.getContentWindow()
    if (contentWindow) {
      const message: any = {
        type: messageType,
        ...data,
      }
      contentWindow.postMessage(JSON.stringify(message), this.frameOrigin)
    }
    return this
  }

Implementierung des Anwendungsservers

Dieser Abschnitt enthält Beispiele für die Implementierung des cookielosen Einbettens auf dem Anwendungsserver und die folgenden Unterabschnitte:

• Einfache Implementierung
• Sitzung abrufen
• Tokens generieren
• Hinweise zur Implementierung

Einfache Implementierung

Die Einbettungsanwendung muss zwei serverseitige Endpunkte implementieren, die Looker-Endpunkte aufrufen. So wird sichergestellt, dass das Sitzungsreferenztoken sicher bleibt. Das sind die Endpunkte:

1. Sitzung abrufen: Wenn bereits ein Sitzungsreferenztoken vorhanden und noch aktiv ist, werden Anfragen für eine Sitzung der vorhandenen Sitzung hinzugefügt. „acquireSession“ wird aufgerufen, wenn ein iFrame erstellt wird.
2. Tokens generieren: Looker löst regelmäßig Aufrufe an diesen Endpunkt aus.

Sitzung akquirieren

In diesem Beispiel in TypeScript wird die Sitzung zum Speichern oder Wiederherstellen des Sitzungsreferenz-Tokens verwendet. Der Endpunkt muss nicht in TypeScript implementiert werden.

  app.get(
    '/acquire-embed-session',
    async function (req: Request, res: Response) {
      try {
        const current_session_reference_token =
          req.session && req.session.session_reference_token
        const response = await acquireEmbedSession(
          req.headers['user-agent']!,
          user,
          current_session_reference_token
        )
        const {
          authentication_token,
          authentication_token_ttl,
          navigation_token,
          navigation_token_ttl,
          session_reference_token,
          session_reference_token_ttl,
          api_token,
          api_token_ttl,
        } = response
        req.session!.session_reference_token = session_reference_token
        res.json({
          api_token,
          api_token_ttl,
          authentication_token,
          authentication_token_ttl,
          navigation_token,
          navigation_token_ttl,
          session_reference_token_ttl,
        })
      } catch (err: any) {
        res.status(400).send({ message: err.message })
      }
    }
  )

async function acquireEmbedSession(
  userAgent: string,
  user: LookerEmbedUser,
  session_reference_token: string
) {
  await acquireLookerSession()
    try {
    const request = {
      ...user,
      session_reference_token: session_reference_token,
    }
    const sdk = new Looker40SDK(lookerSession)
    const response = await sdk.ok(
      sdk.acquire_embed_cookieless_session(request, {
        headers: {
          'User-Agent': userAgent,
        },
      })
    )
    return response
  } catch (error) {
    console.error('embed session acquire failed', { error })
    throw error
  }
}

Ab Looker 23.8 kann die eingebettete Domain beim Abrufen der cookielosen Sitzung angegeben werden. Das ist eine Alternative zum Hinzufügen der Einbettungsdomain über das Looker-Feld Admin > Einbetten. Die eingebettete Domain wird in der internen Looker-Datenbank gespeichert und ist daher nicht im Bereich Verwaltung > Einbetten zu sehen. Stattdessen wird die Einbettungsdomain der cookielosen Sitzung zugeordnet und ist nur für die Dauer der Sitzung vorhanden. Wenn Sie diese Funktion nutzen möchten, sollten Sie sich die Best Practices für die Sicherheit ansehen.

Tokens generieren

In diesem Beispiel in TypeScript wird die Sitzung zum Speichern oder Wiederherstellen des Sitzungsreferenz-Tokens verwendet. Der Endpunkt muss nicht in TypeScript implementiert werden.

Es ist wichtig, dass Sie wissen, wie Sie 400er-Antworten behandeln, die auftreten, wenn Tokens ungültig sind. Obwohl eine 400-Antwort nicht zurückgegeben werden sollte, empfiehlt es sich, die Looker-Einbettungssitzung zu beenden, wenn dies doch geschieht. Sie können die Looker-Einbettungssitzung beenden, indem Sie entweder das eingebettete iFrame zerstören oder den Wert session_reference_token_ttl in der Nachricht session:tokens auf null setzen. Wenn Sie den Wert session_reference_token_ttl auf null setzen, wird im Looker-iFrame ein Dialogfeld angezeigt, in dem darauf hingewiesen wird, dass die Sitzung abgelaufen ist.

Wenn die Einbettungssitzung abläuft, wird keine 400-Antwort zurückgegeben. Wenn die eingebettete Sitzung abgelaufen ist, wird eine 200-Antwort mit dem Wert session_reference_token_ttl auf null zurückgegeben.

  app.put(
    '/generate-embed-tokens',
    async function (req: Request, res: Response) {
      try {
        const session_reference_token = req.session!.session_reference_token
        const { api_token, navigation_token } = req.body as any
        const tokens = await generateEmbedTokens(
          req.headers['user-agent']!,
          session_reference_token,
          api_token,
          navigation_token
        )
        res.json(tokens)
      } catch (err: any) {
        res.status(400).send({ message: err.message })
      }
    }
  )
}
async function generateEmbedTokens(
  userAgent: string,
  session_reference_token: string,
  api_token: string,
  navigation_token: string
) {
  if (!session_reference_token) {
    console.error('embed session generate tokens failed')
    // missing session reference  treat as expired session
    return {
      session_reference_token_ttl: 0,
    }
  }
  await acquireLookerSession()
  try {
    const sdk = new Looker40SDK(lookerSession)
    const response = await sdk.ok(
      sdk.generate_tokens_for_cookieless_session(
        {
          api_token,
          navigation_token,
          session_reference_token: session_reference_token || '',
        },
        {
          headers: {
            'User-Agent': userAgent,
          },
        }
      )
    )
    return {
      api_token: response.api_token,
      api_token_ttl: response.api_token_ttl,
      navigation_token: response.navigation_token,
      navigation_token_ttl: response.navigation_token_ttl,
      session_reference_token_ttl: response.session_reference_token_ttl,
    }
  } catch (error: any) {
    if (error.message?.includes('Invalid input tokens provided')) {
      // The Looker UI does not know how to handle bad
      // tokens. This shouldn't happen but if it does expire the
      // session. If the token is bad there is not much that that
      // the Looker UI can do.
      return {
        session_reference_token_ttl: 0,
      }
    }
    console.error('embed session generate tokens failed', { error })
    throw error
  }

Hinweise zur Implementierung

Die Einbettungsanwendung muss das Sitzungsreferenztoken im Blick behalten und sicher aufbewahren. Dieses Token sollte dem Nutzer der eingebetteten Anwendung zugeordnet sein. Das Token der Einbettungsanwendung kann auf eine der folgenden Arten gespeichert werden:

• In der Sitzung des Nutzers der eingebetteten Anwendung
• In einem serverseitigen Cache, der in einer geclusterten Umgebung verfügbar ist
• In einer Datenbanktabelle, die dem Nutzer zugeordnet ist

Wenn die Sitzung als Cookie gespeichert wird, sollte das Cookie verschlüsselt werden. Im Beispiel im Embed SDK-Repository wird ein Sitzungscookie zum Speichern des Sitzungsreferenz-Tokens verwendet.

Wenn die Looker-Einbettungssitzung abläuft, wird im eingebetteten iFrame ein Dialogfeld angezeigt. An diesem Punkt kann der Nutzer in der eingebetteten Instanz nichts mehr tun. In diesem Fall werden die session:status-Ereignisse generiert, sodass die Einbettungsanwendung den aktuellen Status der eingebetteten Looker-Anwendung erkennen und entsprechende Maßnahmen ergreifen kann.

Eine Einbettungsanwendung kann erkennen, ob die Einbettungssitzung abgelaufen ist, indem sie prüft, ob der session_reference_token_ttl-Wert, der vom generate_tokens-Endpunkt zurückgegeben wird, null ist. Wenn der Wert null ist, ist die Einbettungssitzung abgelaufen. Erwägen Sie die Verwendung einer Callback-Funktion zum Generieren von Tokens, wenn die cookieless-Einbettung initialisiert wird. Die Callback-Funktion kann dann feststellen, ob die Einbettungssitzung abgelaufen ist, und den eingebetteten iFrame löschen, anstatt das Standarddialogfeld für abgelaufene Einbettungssitzungen zu verwenden.

Beispiel für Looker-Einbettung ohne Cookies ausführen

Das Embed SDK-Repository enthält einen Node Express-Server und einen in TypeScript geschriebenen Client, der eine Einbettungsanwendung implementiert. Die oben gezeigten Beispiele stammen aus dieser Implementierung. Im Folgenden wird davon ausgegangen, dass Ihre Looker-Instanz wie oben beschrieben für die Verwendung von cookieless Embed konfiguriert wurde.

So führen Sie den Server aus:

1. Klonen Sie das Embed SDK-Repository – git clone [e-mail]:looker-open-source/embed-sdk.git
2. Verzeichnis ändern – cd embed-sdk
3. Abhängigkeiten installieren – npm install
4. Konfigurieren Sie den Server, wie im Abschnitt Server konfigurieren in diesem Dokument beschrieben.
5. Server ausführen – npm run server

Server konfigurieren

Erstellen Sie im Stammverzeichnis des geklonten Repositorys eine .env-Datei (diese ist in .gitignore enthalten).

Wichtig :Looker-Berichte sind verfügbar, wenn die Funktion „Looker-Berichte“ aktiviert ist. Weitere Anforderungen und Hinweise zum Einbetten von Berichten

Das Format dafür ist:

LOOKER_WEB_URL=your-looker-instance-url.com
LOOKER_API_URL=https://your-looker-instance-url.com
LOOKER_DEMO_HOST=localhost
LOOKER_DEMO_PORT=8080
LOOKER_EMBED_SECRET=embed-secret-from-embed-admin-page
LOOKER_CLIENT_ID=client-id-from-user-admin-page
LOOKER_CLIENT_SECRET=client-secret-from-user-admin-page
LOOKER_DASHBOARD_ID=id-of-dashboard
LOOKER_LOOK_ID=id-of-look
LOOKER_EXPLORE_ID=id-of-explore
LOOKER_EXTENSION_ID=id-of-extension
LOOKER_VERIFY_SSL=true
LOOKER_REPORT_ID=id-of-report
LOOKER_QUERY_VISUALIZATION_ID=id-of-query-visualization

Tipp :LOOKER_WEB_URL kann auch über LOOKER_EMBED_HOST konfiguriert werden. LOOKER_API_URL kann auch mit LOOKER_EMBED_API_URL konfiguriert werden.