Implementa la segmentación a nivel de fila para el contenido incorporado de Looker

Escrito por Christopher Seymour, analista de datos sénior y Dean Hicks, ingeniero de Relaciones con Desarrolladores

La segmentación a nivel de fila te permite limitar los datos a los que puede acceder un usuario individual, según los valores almacenados en uno o más campos de la base de datos. En esta guía, se describen métodos para implementar la segmentación a nivel de fila en el contenido incorporado de Looker y contiene las siguientes secciones:

Introducción

La funcionalidad de incorporación de Looker es una de las características más potentes y valiosas del producto Looker. Si estás leyendo esta guía, es probable que ya incorpores contenido de Looker en tu aplicación o que tengas la intención de hacerlo en un futuro cercano.

El objetivo de esta guía es ayudarte a comprender mejor el diseño de la función de incorporación de Looker y cómo implementar la segmentación en una aplicación en la que los socios pueden administrar el acceso a varias marcas. Como es una inmersión profunda en el tema, la lectura es un poco larga, así que ten en cuenta que esta guía no pretende ser una solución rápida para un problema sencillo, sino un elemento básico que te ayudará a administrar mejor todo tu caso de uso de incorporación de Looker.

Descripción general del caso de uso

En esta guía, se describe un caso de uso común en el que tu empresa incorpora contenido de Looker en tu producto y atiende a segmentos de usuarios que deberían ver diferentes porciones de tus datos.

Para este caso de uso de incorporación firmada, supongamos que eres el administrador de tu instancia de Looker. Trabajas con dos tipos de usuarios externos incorporados: clientes, que solo deberían poder acceder a los datos de su marca específica, y socios, que podrán acceder a los datos de varias marcas. Tienes un panel con algunas tarjetas que le muestras a cada cliente que usa tu producto, pero necesitas que el panel se filtre automáticamente para cada cliente, de modo que los paneles muestren solo los datos específicos de ese cliente. En los ejemplos de este documento, se usan dos empresas ficticias: Hooli y Pied Piper.

Tienes una tabla llamada productos, que muestra algunas métricas de productos de diferentes marcas. Cada marca corresponde a un usuario de incorporación diferente (con un external_user_id diferente) en la aplicación de incorporación firmada. Dado que cada usuario incorporado debe poder ver solo los datos de su propia marca, tienes una exploración que usa un filtro de acceso en un atributo de usuario de marca:

explore: products {
  access_filter: {
    field: products.brand
    user_attribute: brand
  }
}

Tienes un panel basado en esta exploración con dos mosaicos: uno muestra el nombre de la marca y el otro muestra la cantidad de productos de esa marca.

Usa el extremo create_sso_embed_url para generar URLs de incorporación de este panel para cada usuario de incorporación. En este ejemplo, se usan dos marcas: Pied Piper y Hooli. Este es el cuerpo de la solicitud que usas en la llamada create_sso_embed_url para Pied Piper, con external_user_id pied_piper:

{
  "target_url": "https://mylookerinstance.cloud.looker.com/embed/dashboards/17",
  "session_length": 300,
  "force_logout_login": true,
  "external_user_id": "pied_piper",
  "first_name": "PiedPiper",
  "last_name": "User",
  "permissions": ["access_data","see_user_dashboards"],
  "models": ["thelook"],
  "user_attributes": {"brand":"Pied Piper"}
}

La URL que generaste para Pied Piper muestra el panel de esta manera:

Este es el cuerpo de la solicitud que se usa en la llamada a create_sso_embed_url para Hooli, con external_user_id hooli:

{
  "target_url": "https://mylookerinstance.cloud.looker.com/embed/dashboards/17",
  "session_length": 300,
  "force_logout_login": true,
  "external_user_id": "hooli",
  "first_name": "Hooli",
  "last_name": "User",
  "permissions": ["access_data","see_user_dashboards"],
  "models": ["thelook"],
  "user_attributes": {"brand":"Hooli"}
}

La URL que se generó para Hooli muestra el panel de la siguiente manera:

Voilà! El panel se filtra según el valor de cada usuario incorporado para el atributo de usuario marca.

Sigue explorando

¡Genial! Pero ¿qué sucede si quiero darle acceso a un solo usuario a varias marcas? ¿Cómo puedo asegurarme de que solo los usuarios relevantes vean mis datos?

¡Buenas noticias! La función de incorporación firmada de Looker se diseñó para permitir que los desarrolladores creen experiencias de datos potentes y personalizadas para los usuarios y, al mismo tiempo, garantizar que se mantenga la administración de datos definida por tu modelo de datos y tus políticas de acceso al contenido.

Asegurarse de que la administración de datos sea hermética es fundamental para ofrecer esa experiencia de datos potente. Sigue leyendo para explorar algunos conceptos y prácticas recomendadas que puedes usar para diseñar la experiencia que mejor se adapte a tus necesidades. En primer lugar, te ofrecemos una breve descripción general de cómo funciona todo esto.

Aspectos básicos de la incorporación firmada de Looker

Es importante tener en cuenta que la autenticación y administración de usuarios de Looker en el contexto de incorporación funciona de la misma manera que en el contexto no incorporado y de la misma manera que la mayoría de las otras aplicaciones web.

Esto puede ser confuso en el contexto de incorporación firmada de Looker, ya que el paso de autenticación firmada, la configuración del usuario y el panel en sí se combinan en una URL larga y compleja. Sin embargo, esa URL se usa para establecer la sesión, que se sigue aplicando incluso después de que se abrevia la URL. Tener en cuenta este concepto te ayudará mucho a tener éxito en la creación de experiencias de datos increíbles.

Estructura de la URL de incorporación firmada

Esta es una de las URLs de autenticación de incorporación firmadas que genera la llamada a create_sso_embed_url con el cuerpo de la solicitud de Pied Piper:

https://mylookerinstance.cloud.looker.com/login/embed/%2Fembed%2Fdashboards%2F17?permissions=%5B%22access_data%22%2C%22see_user_dashboards%22%5D&models=%5B%22thelook%22%5D&signature=iG6vcKBgnA50jaL2iShFeQHwFPN7wvTx7Rz6r%2FtFuvE%3D&nonce=%22967729518a7dbb8a178f1c03a3511dd1%22&time=1696013242&session_length=300&external_user_id=%22pied_piper%22&access_filters=%7B%7D&first_name=%22Pied%22&last_name=%22Piper%22&user_attributes=%7B%22brand%22%3A%22Pied+Piper%22%7D&force_logout_login=true

Esta es la misma URL decodificada y dividida en líneas individuales:

https://mylookerinstance.cloud.looker.com/login/embed/
/embed/dashboards/17
?permissions=["access_data","see_user_dashboards"]
&models=["thelook"]
&signature=iG6vcKBgnA50jaL2iShFeQHwFPN7wvTx7Rz6r/tFuvE=
&nonce="967729518a7dbb8a178f1c03a3511dd1"
&time=1696013242
&session_length=300
&external_user_id="pied_piper"
&access_filters={}
&first_name="PiedPiper"
&last_name="User"
&user_attributes={"brand":"Pied Piper"}
&force_logout_login=true

Cuando accedes a esta URL, sucede lo siguiente:

  1. Looker busca una cuenta de usuario existente con external_user_id = pied_piper. Si no existe ninguna, Looker crea una cuenta de usuario nueva con ese external_user_id.

  2. Los detalles de la cuenta del usuario existente, incluidos los permisos, los modelos, los grupos (si se especifican) y los valores de los atributos del usuario (si se especifican), se reemplazan por los detalles de la cuenta que se especifican en la URL.

  3. Looker autentica al usuario y establece una sesión para ese usuario almacenando una cookie de sesión en el navegador.

  4. Luego, Looker redirecciona a la URL de destino o de redireccionamiento que se especifica en la llamada a create_sso_embed_url:

    https://mylookerinstance.cloud.looker.com/embed/dashboards/17

    Puedes ver esta URL de redireccionamiento como una URL relativa codificada en la URL de incorporación firmada original:

    %2Fembed%2Fdashboards%2F17

Aunque los pasos 1 a 3 se realizan automáticamente en segundo plano y todo lo que ve el usuario final es el resultado final (el panel en sí), estos pasos son, en esencia, los mismos con los que se autentica un usuario normal de Looker sin incorporar. Supongamos que quieres que un usuario acceda con credenciales de usuario y contraseña. El proceso se vería de la siguiente manera:

  1. Tú (el administrador de Looker) navegas al panel Administrador: usuarios y usas la barra de búsqueda para verificar si ya existe una cuenta de usuario para este usuario. De lo contrario, debes crear una cuenta de usuario nueva.

  2. Tú (el administrador de Looker) presionas Editar junto al usuario en el panel Administrador - Usuarios y le asignas permisos, modelos, grupos, valores de atributos de usuario y otros valores.

  3. El usuario va a la página de acceso en https://mylookerinstance.cloud.looker.com/login e ingresa su nombre de usuario y contraseña. Looker autentica al usuario y establece una sesión para ese usuario almacenando una cookie de sesión en el navegador.

  4. Luego, Looker redirecciona a la página de destino (por lo general, https://mylookerinstance.cloud.looker.com/browse).

Ten en cuenta que la cookie de sesión se aplicará a cada pestaña de la ventana del navegador. Si el usuario comienza en https://mylookerinstance.cloud.looker.com/browse, abre una nueva pestaña del navegador y navega a cualquier página a la que sus permisos le den acceso, la página se cargará como se espera con la cookie de sesión que ya se estableció en la pestaña del navegador original.

Lo mismo ocurre con los usuarios incorporados. Los usuarios de Embed son un poco más limitados en cuanto a las páginas a las que pueden acceder en la IU: solo pueden acceder a las URLs de Vista, Panel y Explorar con el prefijo /embed. Sin embargo, pueden navegar manualmente a cualquier panel al que les otorgue acceso la información de su cuenta de usuario. Supongamos que la URL de incorporación original firmada te redirecciona a https://mylookerinstance.cloud.looker.com/embed/dashboards/17 en una pestaña del navegador. Luego, abre una pestaña nueva del navegador y carga un panel de incorporación diferente que se encuentra en la misma carpeta (y, por lo tanto, tiene las mismas restricciones de acceso): https://mylookerinstance.cloud.looker.com/embed/dashboards/19.

Aunque la URL de redireccionamiento especificada en la URL de incorporación firmada original era para el panel 17, puedes ver que el panel 19 se carga como se espera si ingresas la URL de forma manual en una pestaña del navegador. Ten en cuenta que no se necesitó otra URL de incorporación firmada para cargar un panel diferente.

La idea clave aquí es que todos los detalles de la cuenta de usuario establecidos en la URL (permisos, atributos de usuario, etc.) se aplican a toda la sesión del usuario, no solo al panel específico especificado en la URL firmada original. En otras palabras, como su nombre lo indica, los atributos de usuario son una función del usuario, no del panel, y deben usarse para determinar los niveles de acceso de un usuario específico en toda la aplicación, no solo en una pestaña específica.

Acceso a varias marcas al mismo tiempo

Considera que también tienes socios externos que pueden ser propietarios o administradores de varias marcas. En este ejemplo, un socio administra las marcas Pied Piper y Hooli.

El enfoque desde una perspectiva no incorporada

Las sesiones de usuario incorporadas firmadas funcionan de la misma manera que las sesiones normales de usuarios de Looker, por lo que puede ser útil reformular el enfoque problemático descrito anteriormente en el contexto de una sesión de usuario regular de Looker y no incorporada y desglosar esos pasos para comprender cómo implementar esta solución de una manera más sólida. Así es como se vería ese flujo de trabajo si estuvieras dando instrucciones a un usuario de IE estándar con acceso a la IU de Looker:

  1. Creas dos cuentas de usuario diferentes en la página Administrador - Usuarios.
    1. En la página de edición de la primera cuenta de usuario, estableceste el valor del atributo de usuario brand en pied_piper.
    2. En la página de edición de la segunda cuenta de usuario, estableces el valor del atributo de usuario marca en hooli.
  2. Le envías al socio los correos electrónicos de configuración de las cuentas de usuario.
  3. El socio configura credenciales de correo electrónico y contraseña independientes para cada cuenta.
  4. Le das al socio el vínculo al panel. (https://mylookerinstance.cloud.looker.com/dashboards/17) y dile que, para cambiar el panel entre marcas, deberá volver a la página de acceso en otra pestaña, ingresar las credenciales de correo electrónico y contraseña de su otra cuenta de usuario y, luego, volver a cargar el panel en esa pestaña.

El socio sigue las instrucciones. Sin embargo, después de ingresar el nombre de usuario y la contraseña de la cuenta de usuario de Hooli en la segunda pestaña del navegador y volver a la primera pestaña en la que ya se había cargado el panel de Pied Piper, el socio presiona el botón Actualizar. Para sorpresa del socio, el panel muestra los datos de Hooli.

Por ahora, es posible que te preguntes:

Espera... esto es muy inconveniente. Entonces, ¿cuál es la mejor manera de hacerlo?

Por supuesto. Estas situaciones ayudan a ilustrar un principio que ya es trivial en el contexto no incorporado, pero que puede quedar oculto por las abstracciones del contexto incorporado: Un solo usuario humano debe estar asociado con una sola cuenta de usuario de Looker con un solo conjunto de valores de atributos del usuario. Esto también se explica claramente en nuestra explicación de external_user_id en nuestra documentación de incorporación firmada.

Looker usa external_user_id para diferenciar a los usuarios incorporados firmados, por lo que cada usuario debe tener asignado un ID único.

Puedes crear un external_user_id para un usuario con cualquier cadena que desees, siempre que sea única para ese usuario. Cada ID está asociado con un conjunto de permisos, atributos de usuario y modelos. Un solo navegador puede admitir una sola external_user_id, o sesión de usuario, a la vez. No se pueden realizar cambios en los permisos ni los atributos de un usuario durante la sesión.

Acceso a varias marcas al mismo tiempo: qué NO hacer

Al igual que con cualquier solución personalizable, hay ciertos enfoques que debes evitar. Por ejemplo, una implementación en la que tu app genera las URLs para external_user_ids usando las mismas entradas en la llamada a create_sso_embed_url que se mostró anteriormente y crea una pestaña nueva en la app para cargar cada panel al que debe acceder el socio. Con frecuencia, observamos que los desarrolladores implementan soluciones como esta, lo que genera un flujo de trabajo incorrecto para el usuario:

  1. Navega a la pestaña del panel Pied Piper.
  2. Navega a la pestaña del panel de Hooli.
  3. Regresa a la pestaña del panel Pied Piper.
  4. Presiona el botón Reload en el panel de Pied Piper.

... el panel de Pied Piper muestra los datos de Hooli.

Puedes probar un enfoque similar, pero en su lugar, usa el mismo test_user de external_user_id para ambas llamadas a create_sso_embed_url. Pero el comportamiento es exactamente el mismo: una vez que la pestaña se vuelve a cargar con el panel Pied Piper, se muestran los datos de Hooli.

¿Cómo puedo asegurarme de que el panel de cada marca muestre solo los datos de esa marca?

Aplicación de las prácticas recomendadas

Para aplicar el enfoque descrito en la sección "El enfoque desde una perspectiva no incorporada", necesitarás un solo valor de atributo de usuario que otorgue acceso a TODOS los datos a los que el socio debe tener acceso en toda la aplicación. Para ello, usa un valor separado por comas para el atributo brand Pied Piper,Hooli:

{
  "target_url": "https://mylookerinstance.cloud.looker.com/embed/dashboards/17",
  "session_length": 300,
  "force_logout_login": true,
  "external_user_id": "test_user",
  "first_name": "Test",
  "last_name": "User",
  "permissions": ["access_data","see_user_dashboards"],
  "models": ["thelook"],
  "user_attributes": {"brand":"Pied Piper,Hooli"}
}

Para que esta sintaxis funcione, deberás asegurarte de que el atributo del usuario esté configurado como Filtro de cadenas (avanzado):

Ten en cuenta que aún puedes cambiar el conjunto de atributos de un usuario si algo cambia en sus niveles de acceso a los datos. Por ejemplo, si el socio adquiere la propiedad de una tercera marca, puedes agregarla a la lista separada por comas que especificaste para el atributo de usuario marca. De esta manera, cuando salga y vuelva a acceder, se aplicarán los cambios.

Cómo filtrar los resultados del panel

De acuerdo, entiendo que los atributos del usuario deben especificar todos los datos a los que un usuario puede acceder en la aplicación. Sin embargo, si especifico los atributos del usuario de esta manera, se mostrarán los datos de todas esas marcas en mi panel. ¿Cómo puedo limitar los resultados de un panel específico a una marca específica?

La forma correcta de filtrar un panel en particular es usar ol' filtros del panel. (Esto puede parecer obvio ahora, pero hemos visto que algunas personas se quedan atascadas en los atributos del usuario como la única forma de aplicar filtros en el contexto de incorporación, quizás porque user_attributes es un parámetro en la URL de incorporación firmada y los filtros no lo son).

Asegúrate de requerir un valor de filtro y de usar una de las opciones de control de selección única, como el menú desplegable:

Asegúrate de que el filtro se aplique al campo correcto en todos los mosaicos necesarios:

Ahora, tu socio puede seleccionar entre esos dos (y solo esos dos) valores, ya que las opciones disponibles en el menú desplegable están limitadas por los atributos del usuario:

Completa previamente los filtros del panel

Muy bien, ahora se puede filtrar el panel según una marca específica, pero me gustaría que el valor del filtro ya estuviera establecido en una marca específica cuando el usuario cargue el panel para esa marca en mi app.

Una vez más, es útil pensar en cómo funciona esto en el contexto no incorporado. ¿Cómo le envío a alguien un vínculo a un panel que ya tiene aplicado un valor de filtro específico? Es posible que hayas notado que cuando seleccionas un valor de filtro, ese valor aparece en la URL del panel:

Incluye esa parte de la URL en tu target_url para la llamada a create_sso_embed_url:

{
  "target_url": "https://mylookerinstance.cloud.looker.com/embed/dashboards/17?Brand=Hooli",
  "session_length": 300,
  "force_logout_login": true,
  "external_user_id": "test_user",
  "first_name": "Test",
  "last_name": "User",
  "permissions": ["access_data","see_user_dashboards"],
  "models": ["thelook"],
  "user_attributes": {"brand":"Pied Piper,Hooli"}
}

Si usas el SDK incorporado, puedes usar withFilters para especificar los filtros iniciales que se aplicarán al contenido incorporado:

https://looker-open-source.github.io/embed-sdk/classes/EmbedBuilder.html#withFilters

Si usas tu propia secuencia de comandos personalizada, asegúrate de agregar el filtro a la URL antes de que se codifique la ruta. Es posible que algunos valores ya estén codificados en la string de filtro (por ejemplo, hay un espacio codificado como + en ?Brand=Pied+Piper), por lo que esos valores se codificarán dos veces en la URL final. Puedes consultar el artículo "SO embedded dashboard - set dashboard filter as part of URL?". Publicación de la comunidad de Looker para analizar estos matices. Si aún tienes problemas para aplicar los filtros, puedes usar esa publicación de Comunidad para hacer preguntas.

Cómo ocultar los filtros del panel

Ya veo cómo configurar los filtros iniciales en mis paneles, pero no quiero que el socio cambie los filtros del panel. El valor del filtro debería determinarse SOLO en función del panel al que navegó el socio en mi app. ¿Cómo puedo ocultar los filtros del panel?

Para ello, puedes usar temas. Los temas son una función pagada, por lo que, si aún no la tienes habilitada en tu instancia de Looker, comunícate con tu equipo de ventas de Looker para que la habilite.

Una vez que esta función esté habilitada, navega a la sección Controles del panel de la página Administrador - Temas, donde puedes borrar la opción Mostrar barra de filtros:

Luego, podrás establecer tu tema como predeterminado o aplicarlo en la URL de tus paneles específicos. Una vez más, esto se incluiría en el target_url de la llamada a create_sso_embed_url:

{
  "target_url": "https://mylookerinstance.cloud.looker.com/embed/dashboards/17?Brand=Hooli&theme=test_theme",
  "session_length": 300,
  "force_logout_login": true,
  "external_user_id": "test_user",
  "first_name": "Test",
  "last_name": "User",
  "permissions": ["access_data","see_user_dashboards"],
  "models": ["thelook"],
  "user_attributes": {"brand":"Pied Piper,Hooli"}
}

Encontrarás más información para ocultar filtros del panel de incorporación, incluidos algunos fragmentos de código del SDK de incorporación, en el instructivo de YouTube Cómo incorporar Looker con filtros personalizados.

El resultado final debería ser idéntico a la experiencia del usuario de la pregunta original:

Pero ahora, debido a que los valores del filtro están codificados en las respectivas URLs de destino que están incorporadas en la app, el panel de cada marca siempre mostrará el panel filtrado con la marca correcta, incluso cuando cambies de pestaña.

Cómo realizar pruebas como otros usuarios

Ahora, la experiencia del usuario se parece mucho a lo que imaginé originalmente. Sin embargo, en mi caso de uso, el socio tiene diferentes permisos y otros parámetros de configuración de usuario que los usuarios individuales con external_user_id=pied_piper y external_user_id=hooli no tienen, lo que genera diferentes opciones disponibles en la IU y una experiencia del usuario ligeramente diferente en general. Quiero permitir que un usuario vea todo exactamente como lo ven los usuarios pied_piper y hooli , como si la persona hubiera accedido como esos usuarios. ¿Cómo puedo lograrlo?

Si quieres que un usuario pueda realizar pruebas como cada uno de los usuarios individuales de la marca, puedes compilar una función sudo similar en tu app que cargará las URLs de incorporación para external_user_id=pied_piper cuando el usuario esté sudo como el usuario de Pied Piper y las URLs de incorporación para external_user_id=hooli cuando el usuario esté sudo como el usuario de Hooli. También puedes usar el extremo de la API de login_user para sudo como usuario de la marca con la API si tu app la usa.

Sin embargo, si vuelves a pensar en el contexto no incorporado, en la página Administrador - Usuarios, no puedes usar sudo de forma simultánea como varios usuarios no incorporados en varias pestañas. La sesión de sudo se aplicará a toda la ventana del navegador, al igual que todas las demás sesiones de usuario. Por lo tanto, debes diseñar sudo para que se use como un solo usuario a la vez. Y, si lo piensas, este diseño es más coherente porque imita perfectamente la experiencia de los usuarios con los que estás sudo. Por ejemplo, el usuario pied_piper solo tiene acceso al panel de Pied Piper y no puede abrir paneles adicionales en pestañas adicionales. Por lo tanto, tampoco deberías poder abrir diferentes paneles en distintas pestañas cuando estás usando la identidad de este usuario.

Conclusión

Esperamos que esta guía te haya resultado útil y que te sientas bien preparado para seguir adelante con la creación de tu contenido de incorporación firmado de Looker. Trabajamos continuamente para hacer de Looker la oferta de análisis de datos más flexible y sólida, y queremos conocer tus comentarios. Si tienes preguntas o quieres obtener más información, puedes interactuar con nosotros en la Comunidad de Looker y asistir a nuestros eventos comunitarios.