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

Artículo escrito por Christopher Seymour, analista de datos sénior, y Dean Hicks, ingeniero de relaciones con desarrolladores

La segmentación a nivel de las filas 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 los métodos para implementar la segmentación a nivel de la fila en el contenido de Looker integrado y se incluyen las siguientes secciones:

Introducción

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

Esta guía tiene como objetivo 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 se trata de un análisis detallado del tema, la lectura es un poco extensa, así que ten en cuenta que esta guía no está diseñada para solucionar rápidamente un problema sencillo, sino que es un componente básico que te ayudará a administrar mejor todo tu caso de uso de Looker integrado.

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 su producto y publica segmentos de usuarios que deberían ver diferentes segmentaciones de tus datos.

Para este caso de uso de la URL incorporada firmada, supón que eres el administrador de tu instancia de Looker. Trabajarás con dos tipos de usuarios externos integrados: clientes, que solo deberían poder acceder a los datos relacionados con su marca específica, y socios, que podrán acceder a los datos de varias marcas. Tienes un panel con algunas tarjetas que les muestras a todos los clientes que usan tu producto, pero necesitas que el panel se filtre automáticamente para cada cliente, de modo que muestre solo los datos específicos de cada uno. En los ejemplos de este documento, se usan dos empresas ficticias: Hooli y Pied Piper.

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

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

Tienes un panel basado en este Explorar que tiene dos tarjetas: una muestra el nombre de la marca y la otra muestra la cantidad de productos de esa marca.

Usas el extremo create_sso_embed_url para generar URLs de incorporación de este panel para cada usuario incorporado. En este ejemplo, se usan dos marcas: Pied Piper y Hooli. Este es el cuerpo de la solicitud que usas en la llamada a 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 esta manera:

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

Profundiza en el tema

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

¡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, a la vez que garantiza que se mantenga la administración de datos definida por tu modelo de datos y las políticas de acceso al contenido.

Garantizar que la administración de datos sea hermética es fundamental para brindar esa potente experiencia de datos. Sigue leyendo para explorar algunos conceptos y prácticas recomendadas que puedes usar para diseñar la experiencia que mejor se adapte a ti. Primero, te brindaremos una breve descripción general de cómo funciona todo esto.

Conceptos básicos de la función de Looker para la URL de incorporación firmada

Es importante tener en cuenta que la autenticación y la administración de usuarios de Looker en el contexto de la incorporación funcionan 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 la incorporación firmada de Looker, ya que el paso de autenticación firmado, 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, lo que sigue siendo válido incluso después de que se acorta la URL. Tener en cuenta este concepto te ayudará a crear excelentes experiencias de datos.

Estructura de la URL de incorporación firmada

Esta es una de las URLs de autenticación de incorporación firmada que generó la llamada a create_sso_embed_url con el cuerpo de la solicitud para 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, suceden las siguientes acciones:

  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 él almacenando una cookie de sesión en el navegador.

  4. Luego, Looker redirecciona a la URL de destino, o URL de redireccionamiento, que se especifica en la llamada 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

Si bien los pasos del 1 al 3 se realizan automáticamente en segundo plano, y todo lo que ve el usuario final es el resultado final (el panel), estos pasos son fundamentalmente los mismos que los que realiza un usuario normal de Looker que no está integrado para autenticarse. Supongamos que deseas que un usuario acceda con credenciales de usuario y contraseña. El proceso sería similar al siguiente:

  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. Si no es así, creas una cuenta de usuario nueva.

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

  3. El usuario va a la página de acceso en https://mylookerinstance.cloud.looker.com/login y, luego, ingresa su nombre de usuario y contraseña. Looker autentica al usuario y establece una sesión para él 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 todas las pestañas 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á según lo previsto con la cookie de sesión que ya se estableció en la pestaña original del navegador.

Lo mismo sucede con los usuarios incorporados, que tienen un acceso más limitado a las páginas de la IU. Solo pueden acceder a las URLs de Looks, paneles y Explorar con el prefijo /embed, pero pueden navegar manualmente a cualquier panel al que les permitan acceder los detalles de su cuenta de usuario. Supongamos que la URL de incorporación firmada original te redirecciona a https://mylookerinstance.cloud.looker.com/embed/dashboards/17 en una pestaña del navegador. Luego, abres una nueva pestaña del navegador y cargas un panel incorporado 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 que se especificó en la URL de incorporación firmada original era para el panel 17, puedes ver que el panel 19 se carga según lo previsto 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 clave aquí es que todos los detalles de la cuenta de usuario establecidos en la URL (permisos, atributos del usuario, etcétera) se aplican a toda la sesión del usuario, no solo al panel específico que se indica en la URL firmada original. En otras palabras, como su nombre lo indica, los atributos del usuario son una característica 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.

Acceder a varias marcas al mismo tiempo

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

El enfoque desde una perspectiva que no es de incorporación

Las sesiones de usuarios de Looker integradas firmadas funcionan de la misma manera que las sesiones de usuarios de Looker normales y no integradas, por lo que puede ser útil reformular el enfoque problemático descrito anteriormente en el contexto de una sesión de usuario de Looker normal y no integrada, y desglosar esos pasos para comprender cómo implementar esta solución de una manera más sólida. A continuación, se muestra cómo sería ese flujo de trabajo si le dieras instrucciones a un usuario estándar de IE que tiene acceso a la IU de Looker:

  1. Crearás 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, establece el valor del atributo de usuario marca en pied_piper.
    2. En la página de edición de la segunda cuenta de usuario, establece el valor del atributo de usuario marca en hooli.
  2. Envías correos electrónicos de configuración de la cuenta para ambas cuentas de usuario al socio.
  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 y, luego, ingresar las credenciales de correo electrónico y contraseña de su otra cuenta de usuario, y 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, luego, 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 Recargar. Para sorpresa del socio, el panel muestra los datos de Hooli.

A estas alturas, tal vez te preguntes lo siguiente:

Espera… esto es muy inconveniente. ¿Cuál es la mejor manera de hacerlo?

¡Claro que sí! Lo que ayudan a ilustrar estas situaciones es un principio que ya es trivial en el contexto no integrado, pero que puede quedar oculto por las abstracciones del contexto integrado: Un solo usuario humano debe asociarse 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 sobre la incorporación firmada.

Looker usa external_user_id para diferenciar a los usuarios de la integración firmada, por lo que cada usuario debe tener un ID único asignado.

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

Acceder a varias marcas al mismo tiempo: lo que NO debes 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 ambos external_user_ids con las mismas entradas en la llamada create_sso_embed_url que se mostró anteriormente y crea una pestaña nueva en la app para cargar cada panel al que el socio necesita acceder. Es común que los desarrolladores implementen soluciones como esta, lo que genera un flujo de trabajo incorrecto para el usuario:

  1. Navega a la pestaña del panel de Pied Piper.
  2. Navega a la pestaña del panel de Hooli.
  3. Regresa a la pestaña del panel de Pied Piper.
  4. Presiona el botón Volver a cargar 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, usar el mismo external_user_id test_user para ambas llamadas de create_sso_embed_url. Sin embargo, el comportamiento es exactamente el mismo: una vez que se vuelve a cargar la pestaña con el panel de 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?

Cómo poner en práctica las prácticas recomendadas

Para aplicar el enfoque que se describe en la sección "El enfoque desde una perspectiva que no es de incorporación", necesitarás un solo valor de atributo del usuario que otorgue acceso a TODOS los datos a los que el socio debería tener acceso en toda la aplicación. Para ello, usa un valor separado por comas para el atributo marca 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 tu atributo del usuario esté configurado como Filtro de cadena (avanzado):

Ten en cuenta que aún puedes cambiar el conjunto de atributos del usuario si cambia algo 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 brand. De esa manera, cuando salgan de la cuenta y vuelvan a acceder, se aplicarán los cambios.

Cómo filtrar los resultados del panel

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 en particular a una marca específica?

La forma correcta de filtrar un panel en particular es usar los filtros de panel habituales. (Esto puede parecer obvio ahora, pero vimos que algunas personas se atascan con los atributos del usuario como la única forma de aplicar filtros en el contexto de la incorporación, tal vez 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 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 todas las tarjetas necesarias:

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

Cómo completar previamente los filtros del panel

Bien, ahora el panel se puede filtrar según una marca específica, pero me gustaría que el valor del filtro ya esté 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 cómo funciona esto en el contexto que no es de incorporación. ¿Cómo le envío a alguien un vínculo a un panel que ya tiene aplicado un valor de filtro específico? Bueno, es posible que hayas notado que, cuando seleccionas un valor de filtro, este 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 de incorporación, 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 propio script personalizado, 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 cadena 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 la publicación de la Comunidad de Looker "SO embedded dashboard - set dashboard filter as part of URL?" para obtener más información sobre estos detalles. Si aún tienes problemas para aplicar los filtros, esa publicación de la publicación de Comunidad también sería un buen lugar para agregar preguntas.

Cómo ocultar los filtros del panel

Entiendo cómo establecer los filtros iniciales en mis paneles, pero tampoco quiero que el socio cambie los filtros del panel por su cuenta. El valor del filtro debe determinarse SOLO según el panel al que haya navegado 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, debes comunicarte con tu equipo de ventas de Looker para que la habiliten.

Una vez que se habilite esa función, 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, puedes establecer tu tema como predeterminado o aplicarlo en la URL de tus paneles específicos. Nuevamente, 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"}
}

En este instructivo de YouTube, Incrusta Looker con filtros personalizados, encontrarás más información para ocultar los filtros de los paneles incorporados, incluidos algunos fragmentos de código del SDK de Embed.

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

Sin embargo, ahora, como los valores de los filtros están codificados en las URLs de destino respectivas que se incorporan en la app, el panel de cada marca siempre mostrará el panel filtrado para la marca correcta, incluso cuando cambies de pestañas.

Cómo realizar pruebas como otros usuarios

Ahora la experiencia del usuario se parece mucho a lo que había imaginado originalmente. Sin embargo, en mi caso de uso, el socio tiene permisos diferentes y otros parámetros de configuración del 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 de 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 cargue las URLs de incorporación para external_user_id=pied_piper cuando el usuario ejecute sudo como el usuario de Pied Piper, y las URLs de incorporación para external_user_id=hooli cuando el usuario ejecute sudo como el usuario de Hooli. También puedes usar el extremo de la API de login_user para ejecutar sudo como el usuario de la marca con la API si tu app usa la API.

Sin embargo, si vuelves a pensar en el contexto que no es de incorporación, en la página Administrador > Usuarios, no puedes suplantar simultáneamente a varios usuarios que no son de incorporación en varias pestañas. La sesión de suplantación 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 solo un usuario a la vez pueda usar sudo. Y, si lo piensas, este diseño es más coherente con la imitación perfecta de la experiencia de los usuarios a los que suplantas. 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 diferentes pestañas cuando suplantas a este usuario.

Conclusión

Esperamos que esta guía te haya sido útil y que te sientas preparado para seguir creando contenido de Looker con la función de incorporación firmada. Trabajamos continuamente para que Looker sea la oferta de análisis de datos incorporados más flexible y sólida, y queremos conocer tus comentarios. Si tienes preguntas o quieres obtener más información, puedes comunicarte con nosotros en la Comunidad de Looker y asistir a nuestros eventos de la comunidad.