Incorporación sin cookies

Cuando Looker se incorpora en un iframe con la incorporación firmada, algunos navegadores usan de forma predeterminada una política de cookies que bloquea las cookies de terceros. Se rechazan las cookies de terceros cuando el iframe incorporado se carga desde un dominio diferente del que carga la aplicación de incorporación. En general, puedes solucionar esta limitación solicitando y usando un dominio personalizado. Sin embargo, los dominios personalizados no se pueden usar en algunos casos. Para estos casos, se puede usar la incorporación sin cookies de Looker.

¿Cómo funciona la incorporación sin cookies?

Cuando no se bloquean las cookies de terceros, se crea una cookie de sesión cuando un usuario accede inicialmente a Looker. Esta cookie se envía con cada solicitud del usuario, y el servidor de Looker la usa para establecer la identidad del usuario que inició la solicitud. Cuando se bloquean las cookies, estas no se envían con una solicitud, por lo que el servidor de Looker no puede identificar al usuario asociado con la solicitud.

Para resolver este problema, la incorporación sin cookies de Looker asocia tokens a cada solicitud que se pueden usar para recrear la sesión del usuario en el servidor de Looker. Es responsabilidad de la aplicación integrada obtener estos tokens y ponerlos a disposición de la instancia de Looker que se ejecuta en el iframe integrado. El proceso para obtener y proporcionar estos tokens se describe en el resto de este documento.

Para usar cualquiera de las APIs, la aplicación integrada debe poder autenticarse en la API de Looker con privilegios de administrador. El dominio de incorporación también debe aparecer en la lista de entidades permitidas de dominios incorporados o, si se usa Looker 23.8 o versiones posteriores, el dominio de incorporación se puede incluir cuando se adquiere la sesión sin cookies.

Cómo crear un iframe de Looker incorporado

En el siguiente diagrama de secuencia, se ilustra la creación de un iframe de incorporación. Se pueden generar varios elementos iframe de forma simultánea o en algún momento en el futuro. Cuando se implementa correctamente, el iframe se unirá automáticamente a la sesión que creó el primer iframe. El SDK de Looker Embed simplifica este proceso, ya que une automáticamente la sesión existente.

Diagrama de secuencia que ilustra la creación de un iframe de incorporación.

  1. El usuario realiza una acción en la aplicación incorporada que genera la creación de un iframe de Looker.
  2. El cliente de la aplicación integrada adquiere una sesión de Looker. El SDK de Looker Embed se puede usar para iniciar esta sesión, pero se debe proporcionar una URL de extremo o una función de devolución de llamada. Si se usa una función de devolución de llamada, esta llamará al servidor de la aplicación integrada para adquirir la sesión de Looker integrada. De lo contrario, el SDK de Embed llamará a la URL del extremo proporcionada.
  3. El servidor de la aplicación integrada usa la API de Looker para adquirir una sesión de incorporación. Esta llamada a la API es similar al proceso de firma de incorporación firmada de Looker, ya que acepta la definición del usuario incorporado como entrada. Si ya existe una sesión de incorporación de Looker para el usuario que realiza la llamada, se debe incluir en la llamada el token de referencia de sesión asociado. Esto se explicará con más detalle en la sección Adquirir sesión de este documento.
  4. El procesamiento del extremo de sesión de incorporación de adquisición es similar al extremo de /login/embed/(signed url) firmado, ya que espera la definición del usuario incorporado de Looker como cuerpo de la solicitud, en lugar de en la URL. El proceso del extremo de sesión de incorporación de adquisición valida y, luego, crea o actualiza el usuario incorporado. También puede aceptar un token de referencia de sesión existente. Esto es importante, ya que permite que varios elementos iframe incorporados de Looker compartan la misma sesión. El usuario incorporado no se actualizará si se proporciona un token de referencia de sesión y la sesión no venció. Esto admite el caso de uso en el que se crea un iframe con una URL de incorporación firmada y otros iframes se crean sin una URL de incorporación firmada. En este caso, los iframes sin URLs de incorporación firmadas heredarán la cookie de la primera sesión.
  5. La llamada a la API de Looker devuelve cuatro tokens, cada uno con un tiempo de actividad (TTL):
    • Token de autorización (TTL = 30 segundos)
    • Token de navegación (TTL = 10 minutos)
    • Token de API (TTL = 10 minutos)
    • Token de referencia de sesión (TTL = tiempo de actividad restante de la sesión)
  6. El servidor de aplicaciones integrado debe hacer un seguimiento de los datos que devuelve Looker y asociarlos tanto con el usuario que realiza la llamada como con el agente de usuario del navegador del usuario que realiza la llamada. En la sección Genera tokens de este documento, se proporcionan sugerencias para hacerlo. Esta llamada devolverá el token de autorización, un token de navegación y un token de API, junto con todos los TTL asociados. El token de referencia de la sesión debe protegerse y no exponerse en el navegador que realiza la llamada.
  7. Una vez que los tokens se hayan devuelto al navegador, se debe construir una URL de acceso integrada de Looker. El SDK de Embed de Looker creará automáticamente la URL de acceso incorporado. Para usar la API de windows.postMessage y crear la URL de acceso integrada, consulta la sección Uso de la API de windows.postMessage de Looker de este documento para ver ejemplos.

    La URL de acceso no contiene los detalles del usuario incorporado firmado. Contiene el URI de destino, incluido el token de navegación, y el token de autorización como parámetro de consulta. El token de autorización se debe usar en un plazo de 30 segundos y solo se puede usar una vez. Si se requieren iframes adicionales, se debe volver a adquirir una sesión de incorporación. Sin embargo, si se proporciona el token de referencia de sesión, el token de autorización se asociará con la misma sesión.

  8. El extremo de acceso integrado de Looker determina si el acceso es para la integración sin cookies, lo que se indica con la presencia del token de autorización. Si el token de autorización es válido, verifica lo siguiente:

    • La sesión asociada sigue siendo válida.
    • El usuario incorporado asociado sigue siendo válido.
    • El usuario-agente del navegador asociado a la solicitud coincide con el agente del navegador asociado a la sesión.
  9. Si se superan las verificaciones del paso anterior, la solicitud se redirecciona con el URI de destino que se incluye en la URL. Este es el mismo proceso que para el acceso integrado firmado de Looker.

  10. Esta solicitud es el redireccionamiento para iniciar el panel de Looker. Esta solicitud tendrá el token de navegación como parámetro.

  11. Antes de que se ejecute el extremo, el servidor de Looker busca el token de navegación en la solicitud. Si el servidor encuentra el token, verifica lo siguiente:

    • La sesión asociada sigue siendo válida.
    • El usuario-agente del navegador asociado a la solicitud coincide con el agente del navegador asociado a la sesión.

    Si es válida, se restablece la sesión para la solicitud y se ejecuta la solicitud del panel.

  12. El código HTML para cargar el panel se devuelve al iframe.

  13. La IU de Looker que se ejecuta en el iframe determina que el HTML del panel es una respuesta de incorporación sin cookies. En ese momento, la IU de Looker envía un mensaje a la aplicación integrada para solicitar los tokens que se recuperaron en el paso 6. Luego, la IU espera hasta recibir los tokens. Si no llegan los tokens, se muestra un mensaje.

  14. La aplicación de incorporación envía los tokens al iframe incorporado de Looker.

  15. Cuando se reciben los tokens, la IU de Looker que se ejecuta en el iframe inicia el proceso para renderizar el objeto de solicitud. Durante este proceso, la IU realizará llamadas a la API al servidor de Looker. El token de API que se recibió en el paso 15 se inserta automáticamente como encabezado en todas las solicitudes a la API.

  16. Antes de que se ejecute cualquier extremo, el servidor de Looker busca el token de API en la solicitud. Si el servidor encuentra el token, verifica lo siguiente:

    • La sesión asociada sigue siendo válida.
    • El usuario-agente del navegador asociado a la solicitud coincide con el agente del navegador asociado a la sesión.

    Si la sesión es válida, se restablece para la solicitud y se ejecuta la solicitud a la API.

  17. Se devuelven los datos del panel.

  18. Se renderizará el panel.

  19. El usuario tiene control sobre el panel.

Cómo generar tokens nuevos

En el siguiente diagrama de secuencia, se ilustra la generación de tokens nuevos.

Un diagrama de secuencia que ilustra la generación de tokens nuevos.

  1. La IU de Looker que se ejecuta en el iframe incorporado supervisa el TTL de los tokens de incorporación.
  2. Cuando los tokens están por vencer, la IU de Looker envía un mensaje de token de actualización al cliente de la aplicación integrada.
  3. Luego, el cliente de la aplicación incorporada solicita tokens nuevos a un extremo que se implementa en el servidor de la aplicación incorporada. El SDK de Looker Embed solicitará tokens nuevos automáticamente, pero se debe proporcionar la URL del extremo o una función de devolución de llamada. Si se usa la función de devolución de llamada, esta llamará al servidor de la aplicación incorporada para generar tokens nuevos. De lo contrario, el SDK de Embed llamará a la URL del extremo proporcionada.
  4. La aplicación de incorporación encuentra el session_reference_token asociado con la sesión de incorporación. En el ejemplo que se proporciona en el repositorio de Git del SDK de Looker Embed, se usan cookies de sesión, pero también se puede usar una caché distribuida del servidor, como Redis.
  5. El servidor de la aplicación integrada llama al servidor de Looker con una solicitud para generar tokens. Esta solicitud también requiere tokens de navegación y de API recientes, además del usuario-agente del navegador que inició la solicitud.
  6. El servidor de Looker valida el usuario-agente, el token de referencia de sesión, el token de navegación y el token de API. Si la solicitud es válida, se generan tokens nuevos.
  7. Los tokens se devuelven al servidor de aplicaciones de la aplicación de incorporación que realiza la llamada.
  8. El servidor de la aplicación de incorporación quita el token de referencia de sesión de la respuesta y devuelve la respuesta restante al cliente de la aplicación de incorporación.
  9. El cliente de la aplicación integrada envía los tokens recién generados a la IU de Looker. El SDK de Embed de Looker lo hará automáticamente. Los clientes de aplicaciones integradas que usen la API de windows.postMessage serán responsables de enviar los tokens. Una vez que la IU de Looker recibe los tokens, estos se usarán en las llamadas posteriores a la API y en la navegación de páginas.

Implementa la incorporación sin cookies de Looker

La incorporación de Looker sin cookies se puede implementar con el SDK de Embed de Looker o la API de windows.postMessage. Puedes usar el método del SDK de Looker Embed, pero también hay disponible un ejemplo que muestra cómo usar la API de windows.postMessage. Encontrarás explicaciones detalladas de ambas implementaciones en el archivo README del SDK de Embed de Looker. El repositorio de Git del SDK de Embed también contiene implementaciones en funcionamiento.

Configura la instancia de Looker

El embedding sin cookies comparte características con el embedding firmado de Looker.

Requisitos previos

Para usar la incorporación sin cookies y exponer los extremos de la API de incorporación sin cookies, un administrador de Looker debe verificar y habilitar los siguientes requisitos en el panel Administrador de Looker:

  • Incorporar autenticación de SSO: En el panel Admin > Platform > Embed, habilita Incorporar autenticación de SSO. La incorporación sin cookies se basa en la función subyacente Embed SSO Authentication como parámetro de configuración fundamental.
  • Sesiones persistentes: En el panel Administrador > Autenticación > Sesiones, habilita Sesiones persistentes.
  • Permisos de usuario de la API: Asegúrate de que las credenciales de la API que se usan para adquirir el token pertenezcan a un usuario de Looker con el rol de administrador o un rol personalizado que contenga el permiso manage_embed_settings.

Cómo configurar el secreto del token web JSON

A diferencia de la incorporación firmada de Looker, la incorporación sin cookies no usa el parámetro de configuración Embed Secret. La incorporación sin cookies usa un token web JSON (JWT) en forma de un parámetro de configuración Embed JWT Secret, que se puede establecer o restablecer en la página Embed en la sección Platform del menú Admin.

No es necesario configurar el secreto de JWT, ya que el primer intento de crear una sesión de incorporación sin cookies creará el JWT. Evita restablecer este token, ya que, si lo haces, se invalidarán todas las sesiones de incorporación sin cookies activas.

A diferencia del secreto de incorporación, el secreto del JWT de incorporación nunca se expone, ya que solo se usa de forma interna en el servidor de Looker.

Implementación del cliente de la aplicación

En esta sección, se incluyen ejemplos de cómo implementar la incorporación sin cookies en el cliente de la aplicación y se incluyen las siguientes subsecciones:

Instala o actualiza el SDK de Embed de Looker

Se requieren las siguientes versiones del SDK de Looker para usar la incorporación sin cookies:

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

Usa el SDK de Embed de Looker

Se agregó un nuevo método de inicialización al SDK de Embed para iniciar la sesión sin cookies. Este método acepta dos cadenas de URL o dos funciones de devolución de llamada. Las cadenas de URL deben hacer referencia a los extremos del servidor de aplicaciones de incorporación. Los detalles de implementación de estos extremos en el servidor de aplicaciones se explican en la sección Implementación del servidor de aplicaciones de este documento.

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

En el siguiente ejemplo, se muestra cómo se usan las devoluciones de llamadas. Las devoluciones de llamada solo se deben usar cuando sea necesario que la aplicación cliente integrada conozca el estado de la sesión de integración de Looker. También puedes usar el evento session:status, lo que hace que no sea necesario usar devoluciones de llamada con el SDK de Embed.

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
)

Usa la API de windows.postMessage de Looker

Puedes ver un ejemplo detallado del uso de la API de windows.postMessage en los archivos message_example.ts y message_utils.ts en el repositorio de Git del SDK de Embed. Aquí se detallan los aspectos destacados del ejemplo.

En el siguiente ejemplo, se muestra cómo compilar la URL del iframe. La función de devolución de llamada es idéntica al ejemplo de acquireEmbedSessionCallback que se vio anteriormente.

  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}`
  }

En el siguiente ejemplo, se muestra cómo escuchar solicitudes de tokens, generar tokens nuevos y enviarlos a Looker. La función de devolución de llamada es idéntica al ejemplo anterior de generateEmbedTokensCallback.

      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
  }

Implementación del servidor de aplicaciones

En esta sección, se incluyen ejemplos de cómo implementar la incorporación sin cookies en el servidor de aplicaciones y se incluyen las siguientes subsecciones:

Implementación básica

La aplicación integrada debe implementar dos extremos del servidor que invocarán extremos de Looker. Esto es para garantizar que el token de referencia de la sesión siga siendo seguro. Estos son los extremos:

  1. Adquirir sesión: Si ya existe un token de referencia de sesión y sigue activo, las solicitudes de una sesión se unirán a la sesión existente. Se llama a Acquire session cuando se crea un iframe.
  2. Generar tokens: Looker llama a este extremo de forma periódica.

Adquirir sesión

En este ejemplo en TypeScript, se usa la sesión para guardar o restablecer el token de referencia de la sesión. No es necesario implementar el extremo en TypeScript.

  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
  }
}

A partir de Looker 23.8, se puede incluir el dominio de la incorporación cuando se adquiere la sesión sin cookies. Esta es una alternativa para agregar el dominio incorporado con el panel Administrador > Incorporación de Looker. Looker guarda el dominio de la incorporación en la base de datos interna de Looker, por lo que no se mostrará en el panel Administrador > Incorporación. En cambio, el dominio de la incorporación se asocia con la sesión sin cookies y solo existe durante la sesión. Si decides aprovechar esta función, revisa las prácticas recomendadas de seguridad.

Generar tokens

En este ejemplo en TypeScript, se usa la sesión para guardar o restablecer el token de referencia de la sesión. No es necesario implementar el extremo en TypeScript.

Es importante que sepas cómo controlar las respuestas 400, que se producen cuando los tokens no son válidos. Si bien no debería devolverse una respuesta 400, si esto sucede, la práctica recomendada es finalizar la sesión de Looker integrada. Puedes finalizar la sesión de Looker integrada destruyendo el iframe integrado o estableciendo el valor session_reference_token_ttl en cero en el mensaje session:tokens. Si estableces el valor de session_reference_token_ttl en cero, el iframe de Looker mostrará un diálogo de sesión vencida.

No se devuelve una respuesta 400 cuando vence la sesión de incorporación. Si la sesión de incorporación venció, se muestra una respuesta 200 con el valor session_reference_token_ttl establecido en cero.

  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
  }

Consideraciones sobre la implementación

La aplicación de integración debe hacer un seguimiento del token de referencia de la sesión y mantenerlo seguro. Este token debe estar asociado con el usuario de la aplicación integrada. El token de aplicación de la aplicación de integración se puede almacenar de una de las siguientes maneras:

  • En la sesión del usuario de la aplicación integrada
  • En una caché del servidor que está disponible en un entorno agrupado en clústeres
  • En una tabla de base de datos asociada al usuario

Si la sesión se almacena como una cookie, esta debe estar encriptada. En el ejemplo del repositorio del SDK de integración, se usa una cookie de sesión para almacenar el token de referencia de la sesión.

Cuando venza la sesión de Looker integrada, se mostrará un diálogo en el iframe integrado. En este punto, el usuario no podrá hacer nada en la instancia integrada. Cuando esto ocurre, se generan los eventos session:status, lo que permite que la aplicación integrada detecte el estado actual de la aplicación de Looker integrada y tome algún tipo de medida.

Una aplicación de incorporación puede detectar si la sesión de incorporación venció verificando si el valor de session_reference_token_ttl que devuelve el extremo generate_tokens es cero. Si el valor es cero, significa que la sesión de incorporación venció. Considera usar una función de devolución de llamada para generar tokens cuando se inicialice la incorporación sin cookies. Luego, la función de devolución de llamada puede determinar si la sesión de incorporación venció y destruirá el iframe incorporado como alternativa al diálogo de sesión incorporada vencida predeterminado.

Cómo ejecutar el ejemplo de incorporación sin cookies de Looker

El repositorio del SDK de incorporación contiene un servidor y un cliente de nodos escritos en TypeScript que implementan una aplicación de incorporación. Los ejemplos que se mostraron anteriormente se tomaron de esta implementación. A continuación, se supone que tu instancia de Looker se configuró para usar la incorporación sin cookies, como se describió anteriormente.

Puedes ejecutar el servidor de la siguiente manera:

  1. Clona el repositorio del SDK de Embed: git clone git@github.com:looker-open-source/embed-sdk.git
  2. Cambia el directorio: cd embed-sdk
  3. Instala las dependencias: npm install
  4. Configura el servidor, como se muestra en la sección Configura el servidor de este documento.
  5. Ejecuta el servidor: npm run server

Configura el servidor

Crea un archivo .env en la raíz del repositorio clonado (se incluye en .gitignore).

El formato es el siguiente:

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

Cuando se usa la incorporación sin cookies de Looker, es posible que los usuarios que intenten abrir vínculos en una pestaña o ventana nueva del navegador (como los detalles del panel, los Explorar o las descargas de documentos) experimenten un error HTTP 401 Unauthorized o se los redireccione a la página de acceso de Looker. Este problema suele ocurrir cuando las cookies de terceros están inhabilitadas en el navegador.

Causa

Para evitar vulnerabilidades de secuestro de sesiones, se introdujo un parche de seguridad en Looker (versiones 25.18.61+, 25.20.44+ y 26.0.22+) que dejó de devolver intencionalmente cookies de sesión en la respuesta inicial de la incorporación sin cookies. Debido a que el navegador ya no recibe esta cookie de sesión, la apertura de una URL de Looker en una pestaña o ventana nueva pierde el contexto de autenticación, lo que provoca que la solicitud falle.

Resolución y soluciones

  • Actualiza Looker: Actualiza la instancia de Looker a la versión 26.0.36 o una posterior. En esta versión, se incluye una corrección que agrega de forma segura un token único a las URLs que se abren en una ventana nueva durante una sesión de incorporación sin cookies, lo que restablece la capacidad del usuario de abrir vínculos seguros en pestañas nuevas.
  • Abrir vínculos en el mismo iframe: Si la actualización no es posible de inmediato, configura todos los vínculos de los paneles integrados para que se abran en el mismo iframe. Para ello, establece los destinos de los vínculos en _self (por ejemplo, target="_self").
  • Enruta a través de la aplicación host: Si es estrictamente necesario abrir el vínculo en una pestaña o ventana nuevas, dirígelo a una página nueva dentro de tu aplicación host que inicialice un iframe de incorporación nuevo sin cookies en lugar de vincularlo directamente a la instancia de Looker.
  • Usa la incorporación firmada con un dominio personalizado: Como alternativa, considera usar la incorporación firmada estándar con un dominio personalizado.