Lorsque Looker est intégré dans un iFrame à l'aide d'une intégration signée, certains navigateurs appliquent par défaut des règles relatives aux cookies qui bloquent les cookies tiers. Les cookies tiers sont rejetés lorsque l'iFrame intégré est chargé à partir d'un domaine différent de celui utilisé pour charger l'application d'intégration. Vous pouvez généralement contourner cette limitation en demandant et en utilisant un domaine personnalisé. Toutefois, dans certains cas, les domaines personnalisés ne peuvent pas être utilisés. 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 ?
Si 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 de l'utilisateur, et le serveur Looker l'utilise pour établir l'identité de l'utilisateur à l'origine de la requête. Lorsque les cookies sont bloqués, le cookie n'est pas envoyé avec une requête, de sorte que le serveur Looker ne peut pas identifier l'utilisateur associé à la requête.
Pour résoudre ce problème, l'intégration sans cookie Looker associe à chaque requête des jetons pouvant être utilisés pour recréer la session utilisateur sur le serveur Looker. Il est de la responsabilité de 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é. Le processus d'obtention et de fourniture de ces jetons est décrit dans la suite de ce document.
Pour utiliser l'une 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 de l'intégration doit également être listé dans la liste d'autorisation des domaines intégrés ou, si vous utilisez Looker 23.8 ou version ultérieure, le domaine intégré peut être inclus lors de l'acquisition de la session sans cookie.
Créer un iFrame d'ingestion Looker
Le schéma séquentiel suivant illustre la création d'un iFrame intégré. Plusieurs iFrames peuvent être générés simultanément ou ultérieurement. Lorsqu'il est implémenté correctement, l'iFrame rejoint automatiquement la session créée par le premier iFrame. Le SDK Looker Embed simplifie ce processus en rejoignant automatiquement la session existante.
- 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. Vous pouvez utiliser le SDK Looker Embed pour lancer cette session, mais une URL du point de terminaison ou une fonction de rappel doit être fournie. Si une fonction de rappel est utilisée, elle appelle le serveur d'applications d'intégration pour acquérir la session d'intégration Looker. Sinon, le SDK Embed appelle l'URL du point de terminaison fournie.
- Le serveur d'applications 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 de Looker, car il accepte la définition de l'utilisateur d'intégration en tant qu'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. Vous trouverez des explications plus détaillées dans la section Acquérir une session de ce document.
- Le traitement du point de terminaison de la session d'intégration d'acquisition est semblable au point de terminaison
/login/embed/{signed url)signé, en ce sens qu'il attend la définition de l'utilisateur de l'intégration Looker dans le corps de la requête, plutôt que dans l'URL. Le processus d'acquisition du point de terminaison de la session d'intégration valide et crée ou met à jour l'utilisateur de l'intégration. Il peut également accepter un jeton de référence de session existant. Ce point est important, car il permet à plusieurs iFrames Looker intégrés 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é. Cette méthode est compatible avec les cas d'utilisation où un iFrame est créé à l'aide d'une URL d'intégration signée, tandis que d'autres iFrame sont créés sans URL d'intégration signée. Dans ce cas, les iFrames sans URL d'intégration signée héritent 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 d'applications d'intégration doit assurer le suivi des données renvoyées par les données Looker et les associer à la fois à l'utilisateur appelant et à l'user-agent du navigateur de l'utilisateur appelant. Pour savoir comment procéder, consultez la section Générer des jetons de ce document. Cet appel renvoie le jeton d'autorisation, un jeton de navigation, un jeton d'API, ainsi que toutes les valeurs TTL associées. Le jeton de référence de la 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 pour intégrer Looker doit être créée. Le SDK Looker Embed crée 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'APIwindows.postMessageLooker de ce document pour obtenir des exemples.L'URL de connexion ne contient pas les détails de l'utilisateur intégré signé. 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 un délai de 30 secondes et ne peut être utilisé qu'une seule fois. Si des iFrame supplémentaires sont nécessaires, une session d'intégration doit être acquise à nouveau. Toutefois, si le jeton de référence de la session est fourni, le jeton d'autorisation sera associé à la même session.
Le point de terminaison de connexion de l'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 intégré associé est toujours valide.
- Le user-agent du navigateur associé à la requête correspond au navigateur-agent associé à la session.
Si les vérifications de l'étape précédente réussissent, la requête est redirigée à l'aide de l'URI cible contenu dans l'URL. Le processus est le même que pour la connexion à l'intégration signée Looker.
Cette requête est la redirection permettant de lancer le tableau de bord Looker. Cette requête utilisera le jeton de navigation comme 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 navigateur-agent associé à la session.
Si la requête est valide, la session est restaurée et la requête du tableau de bord s'exécute.
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 intégré de Looker.
Une fois les jetons reçus, l'UI Looker exécutée dans l'iFrame lance le processus pour afficher l'objet de la requête. Au cours de ce processus, l'UI 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 le trouve, 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 navigateur-agent associé à la session.
Si la session est valide, elle est restaurée pour la requête, et la requête API s'exécute.
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érer de nouveaux jetons
Le schéma séquentiel 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 expirent, l'UI 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 d'applications d'intégration. Le SDK d'intégration de 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 d'applications de représentations vectorielles continues pour générer de nouveaux jetons. Sinon, le SDK Embed appelle l'URL du point de terminaison fournie.
- L'application d'intégration trouve l'élément
session_reference_tokenassocié à la session d'intégration. L'exemple fourni dans le dépôt Git du SDK d'intégration Looker utilise des cookies de session, mais un cache côté serveur distribué, par exemple Redis, peut également être utilisé. - Le serveur d'applications d'intégration appelle le serveur Looker avec une requête pour générer des jetons. Cette requête nécessite une API et des jetons de navigation récents, en plus du user-agent du navigateur qui a initié la requête.
- Le serveur Looker valide l'user-agent, le jeton de référence de la 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'applications de représentations vectorielles continues appelant.
- Le serveur d'applications d'intégration supprime le jeton de référence de session de la réponse et renvoie la réponse restante au client d'application d'intégration.
- Le client de l'application d'intégration envoie les nouveaux jetons générés à l'interface utilisateur de Looker. Le SDK Looker Embed s'en chargera automatiquement. Les clients d'application d'intégration qui utilisent l'API
windows.postMessageseront responsables de l'envoi des jetons. Une fois que l'interface utilisateur de Looker a reçu les jetons, ceux-ci sont utilisés pour les appels d'API et les navigations sur les pages suivants.
Implémentation de l'intégration sans cookie Looker
L'intégration sans cookie Looker peut être implémentée à l'aide du SDK Looker Embed ou de l'API windows.postMessage. La méthode qui utilise le SDK d'intégration Looker est plus facile, mais un exemple montrant comment utiliser l'API windows.postMessage est également disponible. Vous trouverez des explications détaillées sur les deux implémentations dans 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 a des points communs avec l'intégration signée Looker. L'intégration sans cookie nécessite l'activation de l'authentification SSO intégrée. Toutefois, contrairement à l'intégration signée Looker, l'intégration sans cookie n'utilise pas le paramètre Embed Secret. L'intégration sans cookie utilise un jeton Web JSON (JWT, JSON Web Token) sous la forme d'un paramètre Embed JWT Secret (Code secret JWT intégré), qui peut être défini ou réinitialisé sur la page Embed (Intégrer) de la section Platform (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ée le JWT. Évitez de réinitialiser ce jeton, car cela invalidera toutes les sessions d'intégration sans cookie actives.
Contrairement au secret d'intégration, le secret JWT d'incorporation n'est jamais exposé, car il n'est utilisé qu'en interne dans le serveur Looker.
Implémentation du client d'application
Cette section inclut des exemples illustrant comment implémenter une intégration sans cookie dans le client d'application. Elle contient les sous-sections suivantes:
- Installer et mettre à jour le SDK Looker Embed
- Utiliser le SDK Looker Embed
- Utiliser l'API
windows.postMessageLooker
Installer ou mettre à jour le SDK Looker Embed
Les versions suivantes du SDK Looker sont requises pour utiliser la représentation vectorielle continue sans cookie:
@looker/embed-sdk >= 1.8
@looker/sdk >= 22.16.0
Utiliser le SDK Looker Embed
Une nouvelle méthode d'initialisation a été ajoutée au SDK Embed afin de 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 référencer les points de terminaison du serveur d'application d'intégration. L'implémentation de ces points de terminaison sur le serveur d'applications est détaillée dans la section Implémentation d'un serveur d'application de ce document.
LookerEmbedSDK.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 s'il est nécessaire que l'application cliente d'intégration ait connaissance de l'état de la session d'intégration Looker. Vous pouvez également utiliser l'événement session:status, ce qui rend inutile l'utilisation de 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 (): Promise<LookerEmbedCookielessSessionData> => {
const { api_token, navigation_token } = getApplicationTokens() || {}
const resp = await fetch('/generate-embed-tokens', {
method: 'PUT',
headers: { 'content-type': 'application/json' },
body: JSON.stringify({ api_token, navigation_token }),
})
if (!resp.ok) {
if (resp.status === 400) {
return { session_reference_token_ttl: 0 }
}
console.error('generate-embed-tokens failed', { resp })
throw new Error(
`generate-embed-tokens failed: ${resp.status} ${resp.statusText}`
)
}
return (await resp.json()) as LookerEmbedCookielessSessionData
}
LookerEmbedSDK.initCookieless(
runtimeConfig.lookerHost,
acquireEmbedSessionCallback,
generateEmbedTokensCallback
)
Utiliser l'API windows.postMessage Looker
Vous pouvez voir 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 clés 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 jetons, 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
}
Mise en œuvre du serveur d'applications
Cette section inclut des exemples illustrant comment implémenter une intégration sans cookie dans le serveur d'applications. Elle contient les sous-sections suivantes:
- Implémentation de base
- Acquérir une session
- Générer des jetons
- Éléments à prendre en compte concernant l'implémentation
Implémentation de base
L'application d'intégration est nécessaire pour implémenter deux points de terminaison côté serveur qui appelleront des points de terminaison Looker. Cela permet de s'assurer que le jeton de référence de session reste sécurisé. Les points de terminaison sont les suivants:
- Acquérir une session : si un jeton de référence de session existe déjà et est toujours actif, les demandes de session rejoignent la session existante. La session d'acquisition est appelée lors de la création d'un iFrame.
- Générer des jetons : Looker déclenche régulièrement des appels vers ce point de terminaison.
Acquérir une session
Dans TypeScript, cet exemple utilise la session pour enregistrer ou restaurer le jeton de référence de session. Le point de terminaison n'a pas besoin d'ê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 la version 23.8 de Looker, le domaine intégré peut être inclus lorsque la session sans cookie est acquise. Il s'agit d'une alternative à l'ajout du domaine d'intégration via le panneau Admin > Intégrer de Looker. Looker enregistre le domaine de l'intégration dans la base de données interne de Looker. Il ne s'affichera donc pas dans le panneau Admin > Embed (Administration > Intégrer). Au lieu de cela, le domaine intégré est associé à la session sans cookie et n'existe que pendant la durée de la session. Consultez les bonnes pratiques de sécurité si vous décidez d'utiliser cette fonctionnalité.
Générer des jetons
Dans TypeScript, cet exemple utilise la session pour enregistrer ou restaurer le jeton de référence de session. Le point de terminaison n'a pas besoin d'ê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. Le renvoi de la réponse 400 ne devrait pas se produire, mais si tel est le cas, 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'incorporation 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é.
La réponse 400 n'est pas renvoyée à l'expiration de la session d'intégration. 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')) {
// Currently the Looker UI does not know how to handle bad
// tokens. This should not 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 assurer le suivi du jeton de référence de la 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 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 en tant que cookie, ce cookie doit être chiffré. L'exemple du dépôt du SDK intégré utilise un cookie de session pour stocker le jeton de référence de la session.
À l'expiration de la session d'intégration Looker, 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 d'effectuer une action.
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, cela signifie que 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é au lieu d'utiliser la boîte de dialogue par défaut de la session intégrée qui a expiré.
Exécuter l'exemple d'intégration sans cookie Looker
Le dépôt du SDK d'ingestion contient un serveur et un client Node Express simples écrits en TypeScript, qui implémentent une application d'intégration simple. Les exemples présentés précédemment sont issus de cette implémentation. Le code suivant suppose que votre instance Looker a été configurée pour utiliser une intégration sans cookie, comme décrit précédemment.
Vous pouvez exécuter le serveur comme suit:
- Clonez le dépôt du SDK Embed :
git clone git@github.com:looker-open-source/embed-sdk.git. - Changez 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é (inclus dans .gitignore).
Le format est le suivant :
LOOKER_EMBED_HOST=your-looker-instance-url.com.
LOOKER_EMBED_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