Lorsque Looker est intégré dans un iFrame à l'aide de l'intégration signée, certains navigateurs utilisent par défaut une règle relative aux cookies qui bloque les cookies tiers. Les cookies tiers sont rejetés lorsque l'iframe intégrée est chargée à partir d'un domaine différent de celui qui charge l'application d'intégration. Vous pouvez généralement contourner cette limitation en demandant et en utilisant un domaine personnalisé. Toutefois, les domaines de redirection ne peuvent pas être utilisés dans certains scénarios. C'est dans ces scénarios que l'intégration sans cookie de Looker peut être utilisée.
Comment fonctionne l'intégration sans cookie ?
Lorsque les cookies tiers ne sont pas bloqués, un cookie de session est créé lorsqu'un utilisateur se connecte initialement à Looker. Ce cookie est envoyé avec chaque requête utilisateur, et le serveur Looker l'utilise pour établir l'identité de l'utilisateur qui a initié la requête. Lorsque les cookies sont bloqués, le cookie n'est pas envoyé avec une requête. Le serveur Looker ne peut donc pas identifier l'utilisateur associé à la requête.
Pour résoudre ce problème, l'intégration sans cookie de Looker associe des jetons à chaque requête. Ces jetons peuvent être utilisés pour recréer la session utilisateur sur le serveur Looker. Il incombe à l'application d'intégration d'obtenir ces jetons et de les mettre à la disposition de l'instance Looker qui s'exécute dans l'iframe intégrée. Le processus d'obtention et de fourniture de ces jetons est décrit dans la suite de ce document.
Pour utiliser l'une ou l'autre de ces API, l'application d'intégration doit pouvoir s'authentifier auprès de l'API Looker avec des droits d'administrateur. Le domaine d'intégration doit également figurer dans la liste d'autorisation des domaines d'intégration ou, si vous utilisez Looker 23.8 ou une version ultérieure, le domaine d'intégration peut être inclus lorsque la session sans cookie est acquise.
Créer un iFrame d'intégration Looker
Le diagramme de séquence suivant illustre la création d'un iFrame d'intégration. Plusieurs iFrames peuvent être générés simultanément ou de manière séquentielle. Si l'implémentation est correcte, l'iframe rejoindra automatiquement la session créée par le premier iframe. Le SDK d'intégration Looker simplifie ce processus en rejoignant automatiquement la session existante. Pour savoir comment éviter les conflits de connexion simultanée lors du chargement de plusieurs iFrames, consultez Bonnes pratiques pour l'intégration de plusieurs iFrames sans cookies.
- L'utilisateur effectue une action dans l'application d'intégration qui entraîne la création d'un iFrame Looker.
- Le client de l'application d'intégration acquiert une session Looker. Le SDK d'intégration Looker peut être utilisé pour lancer cette session, mais une URL de point de terminaison ou une fonction de rappel doit être fournie. Si une fonction de rappel est utilisée, elle appellera le serveur d'application d'intégration pour acquérir la session d'intégration Looker. Sinon, le SDK d'intégration appellera l'URL du point de terminaison fournie.
- Le serveur d'application d'intégration utilise l'API Looker pour acquérir une session d'intégration. Cet appel d'API est semblable au processus de signature d'intégration signée Looker, car il accepte la définition de l'utilisateur d'intégration en entrée. Si une session d'intégration Looker existe déjà pour l'utilisateur appelant, le jeton de référence de session associé doit être inclus dans l'appel. Ce point sera expliqué plus en détail dans la section Acquérir une session de ce document.
- Le traitement du point de terminaison de la session d'acquisition d'intégration est semblable à celui du point de terminaison
/login/embed/(signed url)signé, car il attend la définition de l'utilisateur d'intégration Looker dans le corps de la requête, plutôt que dans l'URL. Le processus du point de terminaison d'acquisition de session d'intégration valide, puis crée ou met à jour l'utilisateur intégré. Il peut également accepter un jeton de référence de session existant. Ceci est important, car cela permet à plusieurs iFrames intégrés Looker de partager la même session. L'utilisateur intégré ne sera pas mis à jour si un jeton de référence de session est fourni et que la session n'a pas expiré. Cela permet de gérer le cas d'utilisation où un iFrame est créé à l'aide d'une URL d'intégration signée et d'autres iFrames sont créés sans URL d'intégration signée. Dans ce cas, les iFrames sans URL d'intégration signées hériteront du cookie de la première session. - L'appel d'API Looker renvoie quatre jetons, chacun avec une valeur TTL (Time To Live) :
- Jeton d'autorisation (TTL = 30 secondes)
- Jeton de navigation (TTL = 10 minutes)
- Jeton d'API (TTL = 10 minutes)
- Jeton de référence de session (TTL = durée de vie restante de la session)
- Le serveur de l'application d'intégration doit suivre les données renvoyées par les données Looker et les associer à l'utilisateur appelant et à l'user-agent du navigateur de l'utilisateur appelant. Des suggestions sur la façon de procéder sont fournies dans la section Générer des jetons de ce document. Cet appel renvoie le jeton d'autorisation, un jeton de navigation et un jeton d'API, ainsi que tous les TTL associés. Le jeton de référence de session doit être sécurisé et ne pas être exposé dans le navigateur appelant.
Une fois les jetons renvoyés au navigateur, une URL de connexion d'intégration Looker doit être construite. Le SDK Looker Embed construira automatiquement l'URL de connexion intégrée. Pour utiliser l'API
windows.postMessageafin de créer l'URL de connexion intégrée, consultez la section Utiliser l'API Lookerwindows.postMessagede ce document pour obtenir des exemples.L'URL de connexion ne contient pas les détails de l'utilisateur de l'intégration signée. Il contient l'URI cible, y compris le jeton de navigation, et le jeton d'autorisation en tant que paramètre de requête. Le jeton d'autorisation doit être utilisé dans les 30 secondes et ne peut être utilisé qu'une seule fois. Si des iFrames supplémentaires sont nécessaires, une session d'intégration doit être acquise à nouveau. Toutefois, si le jeton de référence de session est fourni, le jeton d'autorisation sera associé à la même session.
Le point de terminaison de connexion d'intégration Looker détermine si la connexion est destinée à une intégration sans cookie, ce qui est indiqué par la présence du jeton d'autorisation. Si le jeton d'autorisation est valide, il vérifie les éléments suivants :
- La session associée est toujours valide.
- L'utilisateur d'intégration associé est toujours valide.
- Le user-agent du navigateur associé à la requête correspond au user-agent du navigateur associé à la session.
Si les vérifications de l'étape précédente sont concluantes, la requête est redirigée à l'aide de l'URI cible contenu dans l'URL. Il s'agit du même processus que pour la connexion à l'intégration signée Looker.
Cette requête est la redirection pour lancer le tableau de bord Looker. Cette requête inclura le jeton de navigation en tant que paramètre.
Avant l'exécution du point de terminaison, le serveur Looker recherche le jeton de navigation dans la requête. Si le serveur trouve le jeton, il vérifie les éléments suivants :
- La session associée est toujours valide.
- Le user-agent du navigateur associé à la requête correspond au user-agent du navigateur associé à la session.
S'il est valide, la session est restaurée pour la requête et la requête du tableau de bord est exécutée.
Le code HTML permettant de charger le tableau de bord est renvoyé à l'iFrame.
L'interface utilisateur de Looker qui s'exécute dans l'iframe détermine que le code HTML du tableau de bord est une réponse d'intégration sans cookie. À ce stade, l'interface utilisateur de Looker envoie un message à l'application d'intégration pour demander les jetons récupérés à l'étape 6. L'UI attend ensuite de recevoir les jetons. Si les jetons n'arrivent pas, un message s'affiche.
L'application d'intégration envoie les jetons à l'iFrame Looker intégrée.
Une fois les jetons reçus, l'UI Looker exécutée dans l'iframe lance le processus d'affichage de l'objet de requête. Pendant ce processus, l'interface utilisateur effectue des appels d'API vers le serveur Looker. Le jeton d'API reçu à l'étape 15 est automatiquement injecté en tant qu'en-tête dans toutes les requêtes API.
Avant d'exécuter un point de terminaison, le serveur Looker recherche le jeton d'API dans la requête. Si le serveur trouve le jeton, il vérifie les éléments suivants :
- La session associée est toujours valide.
- Le user-agent du navigateur associé à la requête correspond au user-agent du navigateur associé à la session.
Si la session est valide, elle est restaurée pour la requête, et la requête API est exécutée.
Les données du tableau de bord sont renvoyées.
Le tableau de bord s'affiche.
L'utilisateur contrôle le tableau de bord.
Génération de nouveaux jetons…
Le diagramme de séquence suivant illustre la génération de nouveaux jetons.
- L'interface utilisateur de Looker qui s'exécute dans l'iFrame intégré surveille la valeur TTL des jetons d'intégration.
- Lorsque les jetons approchent de leur date d'expiration, l'interface utilisateur de Looker envoie un message de jeton d'actualisation au client de l'application d'intégration.
- Le client de l'application d'intégration demande ensuite de nouveaux jetons à un point de terminaison implémenté dans le serveur de l'application d'intégration. Le SDK d'intégration Looker demandera automatiquement de nouveaux jetons, mais l'URL du point de terminaison ou une fonction de rappel doit être fournie. Si la fonction de rappel est utilisée, elle appelle le serveur de l'application d'intégration pour générer de nouveaux jetons. Sinon, le SDK d'intégration appellera l'URL du point de terminaison fournie.
- L'application d'intégration trouve le
session_reference_tokenassocié à la session d'intégration. L'exemple fourni dans le dépôt Git du SDK Looker Embed utilise des cookies de session, mais un cache côté serveur distribué, Redis par exemple, peut également être utilisé. - Le serveur d'applications d'intégration appelle le serveur Looker avec une requête de génération de jetons. Cette requête nécessite également des jetons d'API et de navigation récents, en plus du user-agent du navigateur qui a initié la requête.
- Le serveur Looker valide l'agent utilisateur, le jeton de référence de session, le jeton de navigation et le jeton d'API. Si la requête est valide, de nouveaux jetons sont générés.
- Les jetons sont renvoyés au serveur d'application d'intégration appelant.
- Le serveur d'application d'intégration supprime le jeton de référence de session de la réponse et renvoie la réponse restante au client de l'application d'intégration.
- Le client de l'application d'intégration envoie les jetons nouvellement générés à l'interface utilisateur de Looker. Le SDK d'intégration Looker s'en chargera automatiquement. Les clients d'application d'intégration qui utilisent l'API
windows.postMessageseront chargés d'envoyer les jetons. Une fois que l'UI Looker reçoit les jetons, ils sont utilisés dans les appels d'API et les navigations sur les pages suivants.
Implémenter l'intégration sans cookie de Looker
L'intégration sans cookie de Looker peut être implémentée à l'aide du SDK d'intégration Looker ou de l'API windows.postMessage. Vous pouvez utiliser la méthode du SDK d'intégration Looker, mais un exemple montrant comment utiliser l'API windows.postMessage est également disponible. Pour obtenir des explications détaillées sur les deux implémentations, consultez le fichier README du SDK Embed de Looker. Le dépôt Git du SDK Embed contient également des implémentations fonctionnelles.
Configurer l'instance Looker
L'intégration sans cookie partage des caractéristiques avec l'intégration signée de Looker.
Prérequis
Pour utiliser l'intégration sans cookie et exposer les points de terminaison de l'API d'intégration sans cookie, un administrateur Looker doit vérifier et activer les exigences suivantes dans le panneau d'administration Admin de Looker :
- Authentification unique intégrée : dans le panneau Admin > Plate-forme > Intégration, activez l'authentification unique intégrée. L'intégration sans cookie repose sur la fonction Intégrer l'authentification unique sous-jacente en tant que paramètre de base.
- Sessions persistantes : dans le panneau Admin > Authentification > Sessions, activez Sessions persistantes.
- Autorisations de l'utilisateur de l'API : assurez-vous que les identifiants de l'API utilisés pour acquérir le jeton appartiennent à un utilisateur Looker disposant du rôle Administrateur ou d'un rôle personnalisé contenant l'autorisation
manage_embed_settings.
Configurer le secret du jeton Web JSON
Contrairement à l'intégration signée Looker, l'intégration sans cookie n'utilise pas le paramètre Secret d'intégration. L'intégration sans cookie utilise un jeton Web JSON (JWT) sous la forme d'un paramètre Secret JWT d'intégration, qui peut être défini ou réinitialisé sur la page Intégration dans la section Plate-forme du menu Admin.
Il n'est pas nécessaire de définir le secret JWT, car la toute première tentative de création d'une session d'intégration sans cookie créera le JWT. Évitez de réinitialiser ce jeton, car cela invaliderait toutes les sessions d'intégration actives sans cookie.
Contrairement au secret d'intégration, le secret JWT d'intégration n'est jamais exposé, car il n'est utilisé qu'en interne sur le serveur Looker.
Implémentation du client d'application
Cette section inclut des exemples d'implémentation de l'intégration sans cookie dans le client d'application et contient les sous-sections suivantes :
- Installer et mettre à jour le SDK d'intégration Looker
- Utiliser le SDK d'intégration Looker
- Utiliser l'API Looker
windows.postMessage
Installer ou mettre à jour le SDK d'intégration Looker
Les versions suivantes du SDK Looker sont requises pour utiliser l'intégration sans cookie :
@looker/embed-sdk >= 2.0.0
@looker/sdk >= 22.16.0
Utiliser le SDK Looker Embed
Une nouvelle méthode d'initialisation a été ajoutée au SDK Embed pour lancer la session sans cookie. Cette méthode accepte deux chaînes d'URL ou deux fonctions de rappel. Les chaînes d'URL doivent faire référence aux points de terminaison du serveur d'application d'intégration. Les détails de l'implémentation de ces points de terminaison sur le serveur d'applications sont abordés dans la section Implémentation du serveur d'applications de ce document.
getEmbedSDK().initCookieless(
runtimeConfig.lookerHost,
'/acquire-embed-session',
'/generate-embed-tokens'
)
L'exemple suivant montre comment les rappels sont utilisés. Les rappels ne doivent être utilisés que lorsque l'application cliente d'intégration doit connaître l'état de la session d'intégration Looker. Vous pouvez également utiliser l'événement session:status, ce qui évite d'avoir à utiliser des rappels avec le SDK 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
)
Utiliser l'API Looker windows.postMessage
Vous trouverez un exemple détaillé d'utilisation de l'API windows.postMessage dans les fichiers message_example.ts et message_utils.ts du dépôt Git du SDK Embed. Les points forts de l'exemple sont détaillés ici.
L'exemple suivant montre comment créer l'URL de l'iFrame. La fonction de rappel est identique à l'exemple acquireEmbedSessionCallback vu précédemment.
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}`
}
L'exemple suivant montre comment écouter les requêtes de jeton, générer de nouveaux jetons et les envoyer à Looker. La fonction de rappel est identique à l'exemple generateEmbedTokensCallback précédent.
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
}
Implémentation du serveur d'application
Cette section inclut des exemples d'implémentation de l'intégration sans cookie dans le serveur d'applications et contient les sous-sections suivantes :
- Implémentation de base
- Acquérir une session
- Générer des jetons
- Points à observer avant de configurer des événements
Implémentation de base
L'application d'intégration doit implémenter deux points de terminaison côté serveur qui appelleront les points de terminaison Looker. Cela permet de s'assurer que le jeton de référence de session reste sécurisé. Voici les points de terminaison :
- Acquérir une session : si un jeton de référence de session existe déjà et est toujours actif, les demandes de session rejoindront la session existante. "Acquire session" est appelé lorsqu'un iframe est créé.
- Générer des jetons : Looker déclenche régulièrement des appels vers ce point de terminaison.
Acquérir une session
Cet exemple en TypeScript utilise la session pour enregistrer ou restaurer le jeton de référence de la session. Le point de terminaison ne doit pas nécessairement être implémenté 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
}
}
À partir de Looker 23.8, le domaine d'intégration peut être inclus lors de l'acquisition de la session sans cookie. Il s'agit d'une alternative à l'ajout du domaine d'intégration à l'aide du panneau Admin > Intégration de Looker. Looker enregistre le domaine d'intégration dans la base de données interne de Looker. Il ne s'affiche donc pas dans le panneau Admin > Intégration. À la place, le domaine d'intégration est associé à la session sans cookie et n'existe que pendant la durée de la session. Si vous décidez d'utiliser cette fonctionnalité, consultez les bonnes pratiques de sécurité.
Générer des jetons
Cet exemple en TypeScript utilise la session pour enregistrer ou restaurer le jeton de référence de la session. Le point de terminaison ne doit pas nécessairement être implémenté en TypeScript.
Il est important de savoir comment gérer les réponses 400, qui se produisent lorsque les jetons ne sont pas valides. Bien qu'une réponse 400 ne devrait pas être renvoyée, si cela se produit, il est recommandé de mettre fin à la session d'intégration Looker. Vous pouvez mettre fin à la session d'intégration Looker en détruisant l'iframe d'intégration ou en définissant la valeur session_reference_token_ttl sur zéro dans le message session:tokens. Si vous définissez la valeur session_reference_token_ttl sur zéro, l'iFrame Looker affiche une boîte de dialogue indiquant que la session a expiré.
Une réponse 400 n'est pas renvoyée lorsque la session d'intégration expire. Si la session d'intégration a expiré, une réponse 200 est renvoyée avec la valeur session_reference_token_ttl définie sur zéro.
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
}
Observations relatives à la mise en œuvre
L'application d'intégration doit suivre le jeton de référence de session et le sécuriser. Ce jeton doit être associé à l'utilisateur de l'application intégrée. Le jeton d'application d'intégration peut être stocké de l'une des manières suivantes :
- Dans la session de l'utilisateur de l'application intégrée
- Dans un cache côté serveur disponible dans un environnement en cluster
- Dans une table de base de données associée à l'utilisateur
Si la session est stockée sous forme de cookie, celui-ci doit être chiffré. L'exemple du dépôt du SDK d'intégration utilise un cookie de session pour stocker le jeton de référence de session.
Lorsque la session d'intégration Looker expire, une boîte de dialogue s'affiche dans l'iFrame intégré. À ce stade, l'utilisateur ne pourra rien faire dans l'instance intégrée. Dans ce cas, les événements session:status sont générés, ce qui permet à l'application d'intégration de détecter l'état actuel de l'application Looker intégrée et de prendre des mesures.
Une application d'intégration peut détecter si la session d'intégration a expiré en vérifiant si la valeur session_reference_token_ttl renvoyée par le point de terminaison generate_tokens est égale à zéro. Si la valeur est zéro, la session d'intégration a expiré. Envisagez d'utiliser une fonction de rappel pour générer des jetons lors de l'initialisation de l'intégration sans cookie. La fonction de rappel peut alors déterminer si la session d'intégration a expiré et détruire l'iframe intégrée au lieu d'utiliser la boîte de dialogue par défaut d'expiration de la session d'intégration.
Bonnes pratiques pour intégrer plusieurs iFrames avec l'intégration sans cookie
Lorsque vous intégrez plusieurs iFrames Looker sur une même page dans une intégration sans cookie, chaque iFrame nécessite son propre authentication_token à usage unique de acquire_embed_cookieless_session, mais tous les iFrames de la page doivent partager un seul session_reference_token. Suivez ces bonnes pratiques pour intégrer plusieurs iFrames sans cookies :
Acquérir la session une fois et réutiliser
session_reference_token: commencez par acquérir la session sans cookie une fois, mettez en cache lesession_reference_tokenrenvoyé sur votre serveur backend, puis transmettez cesession_reference_tokendans les appelsacquire_embed_cookieless_sessionsuivants pour les iFrames supplémentaires. Looker associe ensuite chaque nouvel iframe à la session existante et ignore la mise à jour de l'utilisateur intégré.Évitez l'acquisition parallèle de sessions initiales : si plusieurs iFrames sont installés en même temps et que votre backend appelle
acquire_embed_cookieless_sessionen parallèle sans transmettre desession_reference_tokenexistant, Looker traite chaque requête comme une nouvelle connexion, met à jour l'utilisateur intégré simultanément et crée des sessions distinctes. Les requêtes de connexion simultanées pour un même utilisateur d'intégration peuvent entraîner des conflits de verrouillage sur le serveur Looker. De plus, écraser lesession_reference_tokenstocké avec la dernière réponse interrompt l'actualisation du jeton (generate_tokens_for_cookieless_session) sur les iFrames précédentes avec une erreur400 Invalid input tokens provided.Précharger un iframe et utiliser la navigation dans l'iframe : pour établir la session utilisateur intégrée avant de charger le contenu, préchargez un iframe à l'aide de
/embed/preload(ou de la méthode.preload()dans le SDK Embed v2). Lorsque vous utilisez Embed SDK v2, vous pouvez également naviguer dans un iframe existant à l'aide de méthodes telles queconnection.loadDashboard(DASHBOARD_ID)ouconnection.loadUrl(EMBED_URL)au lieu de créer des iframes supplémentaires. Pour en savoir plus, consultez Présentation du SDK Embed.
Exécuter l'exemple d'intégration sans cookie de Looker
Le dépôt du SDK d'intégration contient un serveur et un client Node Express écrits en TypeScript qui implémentent une application d'intégration. Les exemples présentés précédemment sont tirés de cette implémentation. Les instructions suivantes supposent que votre instance Looker a été configurée pour utiliser l'intégration sans cookie, comme décrit précédemment.
Vous pouvez exécuter le serveur de la manière suivante :
- Clonez le dépôt du SDK Embed :
git clone git@github.com:looker-open-source/embed-sdk.git - Changer de répertoire :
cd embed-sdk - Installez les dépendances :
npm install. - Configurez le serveur, comme indiqué dans la section Configurer le serveur de ce document.
- Exécutez le serveur :
npm run server.
Configurer le serveur
Créez un fichier .env à la racine du dépôt cloné (il est inclus dans .gitignore).
Le format est le suivant :
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
Résoudre les erreurs 401 Unauthorized lors de l'ouverture de liens dans un nouvel onglet
Lorsque vous utilisez l'intégration sans cookie de Looker, les utilisateurs qui tentent d'ouvrir des liens dans un nouvel onglet ou une nouvelle fenêtre de navigateur (comme les analyses détaillées de tableaux de bord, les explorations ou les téléchargements de documents) peuvent rencontrer une erreur HTTP 401 Unauthorized ou être redirigés vers la page de connexion Looker. Ce problème se produit le plus souvent lorsque les cookies tiers sont désactivés dans le navigateur.
Cause
Pour éviter les failles de détournement de session, un correctif de sécurité a été introduit dans Looker (versions 25.18.61+, 25.20.44+ et 26.0.22+). Il a intentionnellement cessé de renvoyer des cookies de session dans la réponse d'intégration initiale sans cookie. Comme le navigateur ne reçoit plus ce cookie de session, l'ouverture d'une URL Looker dans un nouvel onglet ou une nouvelle fenêtre entraîne la perte du contexte d'authentification, ce qui fait échouer la requête.
Résolution et solutions de contournement
- Mettre à niveau Looker : mettez à niveau l'instance Looker vers la version 26.0.36 ou une version ultérieure. Cette version introduit un correctif qui ajoute de manière sécurisée un jeton à usage unique aux URL ouvertes dans une nouvelle fenêtre lors d'une session d'intégration sans cookie, ce qui permet à l'utilisateur d'ouvrir à nouveau des liens sécurisés dans de nouveaux onglets.
- Ouvrir les liens dans le même iFrame : si vous ne pouvez pas effectuer la mise à niveau immédiatement, configurez tous les liens des tableaux de bord intégrés pour qu'ils s'ouvrent dans le même iFrame en définissant les cibles des liens sur
_self(par exemple,target="_self"). - Effectuer le routage via l'application hôte : s'il est absolument nécessaire d'ouvrir une nouvelle page ou un nouvel onglet, ciblez le lien vers une nouvelle page de votre application hôte qui initialise un nouvel iframe d'intégration sans cookie, plutôt que de créer un lien direct vers l'instance Looker.
- Utiliser l'intégration signée avec un domaine personnalisé : vous pouvez également utiliser l'intégration signée standard avec un domaine personnalisé.