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.

Esta guía está pensada para 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 puedan administrar el acceso a varias marcas. A modo de análisis detallado del tema, es una lectura un poco larga, así que ten en cuenta que esta guía no pretende ser una solución rápida a un problema sencillo, sino un componente básico para ayudarte 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 la instancia de Looker. Trabajas con dos tipos de usuarios de incorporación externos: clientes, que solo deberían poder acceder a datos correspondientes a su marca específica, y socios, que podrán acceder a datos de varias marcas. Tienes un panel con algunos campos que se muestra a todos los clientes que usan tu producto, pero necesitas que el panel se filtre automáticamente para cada cliente, de modo que en los paneles se 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 products, en la que se muestran algunas métricas de productos de diferentes marcas. Cada marca corresponde a un usuario incorporado diferente (con un external_user_id diferente) en la aplicación incorporada firmada. Dado que cada usuario incorporado debería poder ver solo los datos de su propia marca, tienes una exploración que usa un filtro de acceso en un atributo de usuario brand:

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 incorporadas 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 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 la siguiente manera:

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

{
  "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 de acuerdo con el valor de cada usuario incorporado para el atributo de usuario brand.

Ahondar en el tema

¡Genial! Pero ¿qué sucede si quiero permitir que un solo usuario acceda 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, 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.

Asegurarse de que la administración de datos sea estricta es primordial para brindar esa experiencia de datos poderosa. 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. Primero, presentamos una breve descripción general de cómo funciona todo esto.

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

Es importante tener en cuenta que la autenticación y la administración de usuarios de Looker en el contexto de incorporación funcionan de la misma manera que en el contexto de no incorporación y, fundamentalmente, de la misma manera que la mayoría de las demás 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á en gran medida a crear experiencias de datos excelentes.

Estructura de URL de incorporación firmada

Esta es una de las URLs de autenticación de incorporación firmadas generadas por la llamada 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, 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 especifica) y los valores de atributos de 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 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 deseas que un usuario acceda con credenciales de usuario y contraseña. El proceso se verí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. 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 aprovisiona al usuario 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 é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 tenga acceso con sus permisos, la página se cargará como se espera mediante la cookie de sesión que ya se estableció en la pestaña original del navegador.

Lo mismo ocurre con los usuarios insertados. 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, tienen la libertad de navegar manualmente a cualquier panel al que tengan acceso los detalles 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, abres una nueva pestaña del navegador y cargas 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 que se especificó en la URL de incorporación original firmada era para el panel 17, puedes ver que el panel 19 se carga como se esperaba si ingresas manualmente la URL 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.

Cómo acceder 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.

Enfoque desde una perspectiva no integrada

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, configure el valor del atributo de usuario brand como pied_piper.
    2. En la página de edición de la segunda cuenta de usuario, configure el valor del atributo de usuario brand como hooli.
  2. Envías al socio los correos electrónicos de configuración de ambas cuentas de usuario.
  3. El socio configura credenciales de correo electrónico y contraseña independientes para cada cuenta.
  4. Debes proporcionarle al socio el vínculo al panel. (https://mylookerinstance.cloud.looker.com/dashboards/17) y decirle 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 regresar a la primera pestaña en la que ya estaba cargado el panel Pied Piper, el socio presiona el botón Volver a cargar. 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! Lo que ayudan a ilustrar estas situaciones es un principio que ya es trivial en el contexto de no incorporación, pero que puede ocultarse por las abstracciones del contexto de incorporación: Un solo usuario humano debe asociarse con una sola cuenta de usuario de Looker con un solo conjunto de valores de atributos de usuario. Esto también queda claro en nuestra explicación de external_user_id en nuestra documentación de incorporaciones firmadas.

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 se asocia con un conjunto de permisos, atributos de usuario y modelos. Un solo navegador puede admitir solo 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 hay que 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 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, puedes usar 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 en el panel de cada marca solo se muestren los datos de esa marca?

Aplicación de las prácticas recomendadas

Para aplicar el enfoque que se describe en la sección “El enfoque desde una perspectiva no integrada”, necesitarás un solo valor de atributo de usuario que otorgue acceso a TODOS los datos a los que el socio debería tener acceso en 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 de usuario esté configurado como String Filter (advanced):

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

Filtra los resultados del panel

Muy bien, entiendo que los atributos de usuario deben especificar todos los datos a los que puede acceder desde la aplicación. Pero si especifico los atributos de usuario de esta manera, se mostrarán los datos de todas esas marcas en mi panel. ¿Cómo limito los resultados de un panel en particular 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 notamos 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 solicitar 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 todos los mosaicos necesarios:

Ahora tu socio puede seleccionar entre esos dos valores (y solo esos dos), porque las opciones disponibles en el menú desplegable están limitadas por los atributos de 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.

Nuevamente, es útil pensar en cómo funciona esto en el contexto de no incorporación. ¿Cómo le envías a un usuario 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 "¿Cuál es el panel de control incorporado - ¿Deseas establecer el filtro para el panel como parte de la URL?" Publicación de Comunidad de Looker para analizar estos matices. Si todavía tienes problemas para aplicar los filtros, esa publicación de Comunidad también puede ser un buen lugar para agregar preguntas.

Oculta 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, debes comunicarte con tu equipo de Ventas de Looker para que la habiliten.

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

Encuentra 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 debe 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.

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 otras configuraciones 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 pied_piper , 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 piensas de nuevo en el contexto de no incorporación: en la página Administrador: Usuarios, no puedes sudo simultáneamente como múltiples usuarios no incorporados en varias pestañas, la sesión sudo se aplicará a toda la ventana del navegador, al igual que a las demás sesiones de usuario. Por lo tanto, debes diseñar sudo a sudo 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. El usuario pied_piper, por ejemplo, tiene acceso solo al panel de Pied Piper y no tiene acceso para 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.