Grafana: Connexion automatique par URL de jeton

serait assez peu sûr car tout le monde peut voir le jeton, vous pouvez créer un instantané des données visibles et l'intégrer, ce serait plus sécurisé

Oui, mais en utilisant des instantanés, vous n'avez pas l'autorisation de le modifier, ou existe-t-il un moyen de modifier le tableau de bord via des instantanés?

Ceci est assez important pour l'interopérabilité avec SaaS.
Nous avons notre propre authentification et nos propres tableaux de bord, nous voulons offrir la possibilité de transmettre un utilisateur de notre tableau de bord à Grafana - dans la même veine que la façon dont Heroku interagit avec New Relic et d'autres services sans mot de passe.

Fournir une méthode d'authentification url + token est normal.
Si quelqu'un va ensuite et intègre cela sur un site Web public, aucune sécurité ne sauvera cette personne d'elle-même. C'est leur faute.
Fournir suffisamment d'avertissements dans la documentation / l'interface utilisateur devrait suffire pour cela.

Sans cette fonctionnalité, les utilisateurs doivent rencontrer un deuxième écran de connexion, où ils seront confus quant au nom d'utilisateur / mot de passe à saisir.

C'est un gros bloqueur pour nous.

Cela semble être une bonne fonctionnalité à avoir dans Grafana. Aimerait de l'aide pour les relations publiques car il y a tellement d'autres choses qui sont vraiment prioritaires en ce moment

Belle explication @adamlwgriffiths, la même chose m'arrive.

Pour le moment, nous avons résolu ce problème avec un petit hack, en ajoutant un javascript qui se connecte automatiquement à grafana, mais c'est une solution temporelle

+10 pour ça !!
Pour rendre cela sécurisé, il devrait y avoir un hachage du nom d'utilisateur + mot de passe + date, contenu dans le jeton. Cela pourrait être utilisé pour faire expirer le jeton après x nombre d'heures afin d'améliorer la sécurité.

Si j'ai du temps, j'envisagerai sérieusement de travailler dessus

Si vous stockez la date de création du jeton afin de pouvoir l'expirer, vous stockez également le hachage et le compte associé, donc je ne pense pas que le hachage doive être généré à partir de données particulières. Il doit simplement s'agir d'un espace de recherche suffisamment grand pour que les devinettes soient irréalisables.

@adamlwgriffiths , cela devrait également prendre en charge certains rôles de base .. tels que le visualiseur, l'éditeur .. etc.

Je pense - à long terme - que le jeton user / org / api doit être consolidé, plutôt qu'une nouvelle méthode ajoutée.
Si les jetons d'API étaient étendus pour permettre l'utilisation à partir de l'interface HTML, cela ne poserait pas de problème.
Les jetons d'API ont déjà des rôles et peuvent être révoqués.Ils doivent donc simplement être utilisables pour la vue Web plutôt que pour l'API pure.

Les jetons API IMO doivent fonctionner de la même manière que les utilisateurs normaux. Il y a une ségrégation arbitraire qui n'est pas documentée et je trouve qu'elle est contre-intuitive. Activer toutes les vérifications de connexion pour vérifier également les clés API serait le meilleur à mon avis.

Cette fonctionnalité a-t-elle été implémentée? J'essayais de rediriger automatiquement un utilisateur vers le tableau de bord grafana depuis mon site.

@comcomservices En guise de suivi du jeton lui-même, vous pouvez certainement crypter les informations à l'intérieur du jeton avec l'ID utilisateur et le délai d'expiration du jeton. De cette façon, vous pouvez simplement lire le jeton lui-même et obtenir les informations sans exiger que les jetons soient stockés dans la base de données et en exécutant `` balayer et effacer '' les anciens jetons.

J'hésite à recommander une telle chose, je crois fermement que la cryptographie est difficile, et sans une compréhension complète de ce que vous faites, ce n'est pas une bonne idée d'essayer de le faire.

L'autre problème avec les jetons chiffrés est qu'ils sont plutôt volumineux et que plus il y a d'informations, plus ils deviennent volumineux.
Où une chaîne aléatoire peut être faite à n'importe quelle longueur, tant que l'espace est suffisamment grand pour rendre la force brute impossible.

@adamlwgriffiths en ce qui concerne la cryptographie, j'ai une formation formelle et je l'apprécie, mais pour ce cas, je suis tout à fait d'accord pour dire qu'un jeton serait le meilleur. pendant trop longtemps ... je vais l'obtenir et c'est le premier sur ma liste

J'attends avec impatience cette fonctionnalité! En ce qui @adamlwgriffiths ci-dessus concernant l'incorporation du jeton sur un site, je crois que le moyen d'atténuer cela consiste à associer ce jeton à un domaine qui devrait le demander; de cette façon, ce jeton ne fonctionne que lorsque l'origine correspond. Un exemple de ceci - encore une fois, si je comprends bien le problème - est le raven-js de Sentry ; il créera une URL publique et la limitera par origine (voir ci-dessous). Cela atténuerait-il le problème de sécurité?

@ Germanaz0 Votre JS de connexion automatique est-il accessible au public? Je cherche à implémenter quelque chose de similaire sur la branche principale et il semble que le backend redirige vers l'écran de connexion avant d'accéder à la page du tableau de bord. Je ne suis pas encore très familier avec la structure du projet, donc je ne me connecte peut-être pas à la bonne section du code JS.

@rca oui, mais ma solution est super simple https://gist.github.com/Germanaz0/d41b5f60dd8097405b6b

Vous recevez un paramètre d'entrée comme? T = base64 d'un json avec {user: _USERNAME_, pass: _PASS_, redirect_to: _URL_TO_REDIRECT}

Vous devez inclure ce script dans la page de connexion.

@ Germanaz0 , merci pour le partage! Après avoir envoyé mon commentaire, j'ai commencé à jeter un coup d'œil et, comme vous l'avez souligné, j'ai trouvé que je devais mettre à jour la page de connexion. J'ai adopté une approche légèrement différente et mis à jour le contrôleur de connexion au lieu de créer un script autonome; mon changement est ici: https://github.com/zymbit/grafana/tree/auto-login-by-cookie-redirect

Cela mérite-t-il une pull request? Je serais heureux de créer les mods nécessaires pour que cela puisse être fusionné.

Une mise à jour pour ceci?
@rca Avez-vous créé un PR?

+1 pour un PR de @rca

@ Germanaz0 , dans quel fichier

@rca avez-vous des instructions sur la façon d'utiliser votre mod de contrôleur de connexion? Je suis nouveau sur grafana et j'essaie de faire fonctionner cela pour un kiosque sans surveillance.

BTW si quelqu'un d'autre a besoin d'un moyen d'accomplir cela pour les kiosques, etc., vérifiez le proxy d' authentification de

@scottfuhrman Rien de formellement écrit, cependant, voici mon cas d'utilisation et ma mise en œuvre:

Je ne cherchais pas le mode kiosque, mais plutôt un moyen d'intégrer un tableau de bord en tant qu'iframe sur une page externe. Les graphiques sont intégrés assez propres, par exemple:

Sur la page que vous souhaitez intégrer au tableau de bord, vous avez besoin du balisage suivant:

<div id='grafana-dashboard' class="col-lg-12"></div>


<script type="text/javascript">
    GrafanaEmbed = {
        grafanaUrl: 'https://your.grafana.example.com',
        dashboard: 'dashboad-name',
        queryParams: {
            dashnav: 0,
            // this is a base64-encoded string of username:password
            // for example on a *NIX machine (and Mac OS X):
            // $ echo "kiosk1:supersecret" | base64
            // a2lvc2sxOnN1cGVyc2VjcmV0Cg==
            auth: 'a2lvc2sxOnN1cGVyc2VjcmV0Cg==',
            theme: 'light'
        }
    };

    (function() {
        var d = document.createElement('script'); d.type = 'text/javascript'; d.async = true;
        d.src = GrafanaEmbed.grafanaUrl + '/public/app/features/dashboard/embed.js';
        (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(d);
    })();
</script>

J'espère que cela t'aides.

+1

Je n'ai pas les ressources en personnel pour cela, mais je serais heureux de financer les efforts pour cela.

Je pensais avoir résolu ce problème jusqu'à ce que j'essaye d'utiliser une liste de lecture. L'utilisation de authproxy fonctionne pour un tableau de bord donné, mais une fois que j'ai essayé une liste de lecture avec plusieurs tableaux de bord, j'ai rencontré le même problème. Je ne comprends pas l'intérêt d'avoir un mode kiosque quand il est impossible d'implémenter une vraie application kiosque à moins de désactiver complètement la sécurité de visualisation?

@torkelo J'ai recruté @ over64 pour travailler là-dessus pour moi.

Comment recommandez-vous que cela soit mis en œuvre? Fondamentalement, ce dont j'ai besoin est d'avoir un jeton dans la chaîne d'URL qui contourne / résout l'authentification. Quelle est la meilleure approche pour cela?

pas sûr, devrait rechercher comment une telle fonctionnalité devrait être mise en œuvre en toute sécurité

Je l'ai. Nous sommes prêts une fois que vous avez élaboré un plan :)

si vous avez une idée de comment faire, faites-le moi savoir et je pourrai l'évaluer

Bien. @ over64 jettera un œil et suggérera quelque chose.

@torkelo Pouvez-vous regarder les relations publiques de @ over64 dans # 7431 pour voir si cela a du sens.

Une solution de contournement facile? J'essaie de mettre en œuvre la solution @ Germanaz0 mais cela ne fonctionne pas pour moi :(

C'est un must, sinon un est bloqué lors de l'incorporation d'un instantané dans iframe. L'URL de l'instantané intégré doit prendre en charge la clé / jeton de connexion.

Salut tout le monde,

Les commentaires les plus récents de ce fil concernent:

• Sécurité
• intégration dans une iframe

En ce qui concerne la sécurité, veuillez considérer mon ancien commentaire ci-dessus: https://github.com/grafana/grafana/issues/3752#issuecomment -200874453

Et concernant l'intégration dans une iframe: https://github.com/grafana/grafana/issues/3752#issuecomment -267062843

Cette branche (quoique assez ancienne) contient du code emprunté à Discourse qui dimensionne joliment un iframe ainsi que l'authentification via un jeton comme décrit dans le commentaire ci-dessus.

@torkelo Veuillez me faire savoir si vous envisagez une pull request incorporant les éléments ci-dessus.

@rca qu'est-ce que embed.js dans votre code ci-dessus?

@zoell c'est quelques js empruntés au projet Discourse pour bien dimensionner un iframe sur la page en fonction du contenu intégré avec le cadre.

@rca oh merci. Je n'ai pas pu trouver ce fichier dans la branche que vous avez mentionnée. Est-ce disponible ailleurs?

@zoell , je vais bifurquer ce dépôt et inclure ce fichier comme il se doit.

@rca merci, ce serait génial.

@rca Je suis désolé, je ne trouve toujours pas le fichier dans la branche que vous avez mentionnée auparavant.

@TinaRen @zoell J'ai laissé tomber le ballon là-dessus, excuses.

Cependant, après avoir jeté un coup d'œil à l'instant, il semble que le fichier soit là depuis toujours! 😬

Je ferai tout travail supplémentaire à ce sujet à:

https://github.com/rca/grafana

Et le fichier est à:

https://github.com/rca/grafana/blob/embedding/public/app/features/dashboard/embed.js

Si ce fichier ne se construit pas et se retrouve dans le répertoire public_gen/ , merci de me le faire savoir.

Merci!

Est-il possible au moins de limiter grafana aux accès localhost? (pour restreindre le partage du panneau au même site serveur)

J'adorerais voir quelqu'un essayer cela avec une mise en œuvre appropriée qui puisse aller en amont. La solution que nous avons proposée (# 7431), n'a jamais été acceptée :(

Je suis heureux que quelqu'un de notre côté consacre du temps à cela, mais nous aurions besoin de conseils sur ce qui serait acceptable en amont.

Nous avons réussi à le faire avec succès en utilisant Grafana de auth.proxy de Nginx et ngx_http_secure_link_module

Les liens que j'utilise sont au format http://grafana/?user=nayar&md5=2tutcea9nfdsfdsfdsw&expires=1505386800

Une fois que l'utilisateur clique dessus, le cookie de session est défini et l'utilisateur peut parcourir grafana comme s'il s'était connecté normalement.

Avantages:

• Le lien expire après un certain temps + sécurité
• Link génère un hachage avec userid, timestamp et passkey + sécurité
• Pas besoin de taper le mot de passe + commodité

Ma conf nginx est comme ça

server {
    listen 3001 default_server;
#   listen [::]:3001 default_server;

    server_name _;

        location / {
        set $user "";
        set $state "";

        if ($args ~ "^user=(.+)&md5") {
                    set $user $1;
                    set $state "${state}U";
                }

        secure_link $arg_md5,$arg_expires;
                secure_link_md5 "$secure_link_expires$uri$user grafanarocks";

                if ($secure_link = "") { 
                    set $state "${state}S1";
                }

                if ($secure_link = "0") { 
                    set $state "${state}S2";
                }

                add_header X-uristate "$state";

                if ($state = "US1") { return 403; }
                if ($state = "US2") { return 410; }

                add_header X-uri "$user";

                proxy_set_header X-WEBAUTH-USER $user;

                proxy_pass http://127.0.0.1:3000;
            }
    }

N'hésitez pas à me contacter si vous avez besoin d'aide pour cela

Très intéressant, @Nayar. Cependant, mon souci avec cette solution est qu'elle nécessite un assez grand nombre de personnalisations. Je préférerais quelque chose qui est intégré à Grafana de manière native.

J'ai utilisé un stock Grafana. Juste eu à recompiler un stock nginx avec le module activé et c'est tout.

Nayar, pouvez-vous s'il vous plaît me faire savoir si la solution que vous avez implémentée peut fonctionner avec toutes les versions de grafana.i suis nouveau sur Grafana. Dans mon organisation, ils ont déjà installé

Trouver quelques idées (et problèmes) sur la façon de résoudre ce problème.

Solution la plus rapide:

1) ajoutez un type spécial (indicateur) sur une clé API afin qu'elle puisse être utilisée dans l'url pour vous connecter.

Proos: les clés API ne peuvent être ajoutées que par les administrateurs de l'organisation.

2) permettre aux utilisateurs de créer des clés api et des clés url (variante de la clé api).

Les problèmes avec cela vont être les configurations oauth où si un utilisateur peut créer une clé api ou une clé url, il pourra l'utiliser après avoir été supprimé de l'accès de Grafana (du système oauth). Comme la clé API ou la clé URL ne nécessitera pas de connexion oauth. Cela va être un gros problème pour les clés API des utilisateurs lorsque nous les réaliserons finalement. Une solution d'atténuation pourrait consister à autoriser uniquement les administrateurs de l'organisation ou les administrateurs du serveur Grafana à créer des clés API utilisateur.

Réflexions @DanCech ? Continuer avec l'utilisation d'une clé API avec un indicateur AllowUrlLogin?

Je ne pense pas que l'utilisation de l'infrastructure de clé API soit la bonne voie à suivre, car cela rend difficile l'ajout de fonctionnalités plus tard (par exemple, limiter l'URL à un ensemble particulier de tableaux de bord, permettant aux non-administrateurs de créer des liens de connexion ) et risque de prêter à confusion pour les utilisateurs. Nous pourrions certainement utiliser les mêmes concepts et avoir une structure backend similaire, mais cela nous donne plus d'options si nous le séparons, et je pense que ce sera plus clair pour les utilisateurs.

En ce qui concerne la question de connexion oauth, je pense que nous devons déterminer quelle devrait être la portée ici. Le même problème existe pour les utilisateurs oauth si vous avez également activé les mots de passe, car ils peuvent définir un mot de passe local et pourraient se connecter de cette manière après la désactivation du compte oauth. La seule vraie solution à ce problème est de stocker ce lien dans le compte utilisateur et d'envoyer toujours un utilisateur oauth via la boucle de redirection oauth avant d'accepter sa connexion.

Je pense également que nous devons trouver un nom raisonnable pour cette fonctionnalité. L '"URL de connexion" est peut-être trop large et ne laisse pas vraiment de place pour une utilisation future, par exemple pour partager un lien en direct limité à un tableau de bord particulier.

@mattttt aimerait avoir votre avis

car il est difficile d'ajouter plus de fonctionnalités plus tard (par exemple, limiter l'URL à un ensemble particulier de tableaux de bord, permettant aux non-administrateurs de créer des liens de connexion)

J'hésite à lier cette fonctionnalité de connexion à des autorisations ou à la limiter à des tableaux de bord spécifiques (autre que de la lier à un rôle d'organisation ou à un utilisateur). Parce que cela transformerait cela en une fonctionnalité de partage et définirait des attentes en matière de sécurité qui ne sont pas satisfaites (puisque vous pouvez interroger toutes les données à partir d'une source de données utilisée par une organisation).

La seule vraie solution à ce problème est de stocker ce lien dans le compte utilisateur et d'envoyer toujours un utilisateur oauth via la boucle de redirection oauth avant d'accepter sa connexion.

Je ne sais pas comment cela résout la «révocation» de l'url de connexion / du jeton API utilisateur. S'ils n'essayaient jamais de se connecter avec oauth après la suppression de leur accès, Grafana ne le saurait jamais.

@hemsush Selon ce billet de blog, cela devrait fonctionner à partir de Grafana 2.0: https://grafana.com/blog/2015/12/07/grafana-authproxy-have-it-your-way/

J'hésite à lier cette fonctionnalité de connexion à des autorisations ou à la limiter à des tableaux de bord spécifiques (autre que de la lier à un rôle d'organisation ou à un utilisateur). Parce que cela transformerait cela en une fonctionnalité de partage et définirait des attentes en matière de sécurité qui ne sont pas satisfaites (puisque vous pouvez interroger toutes les données à partir d'une source de données utilisée par une organisation).

C'est un problème qui doit être résolu, donc ma suggestion serait que ce système soit conçu avec ce cas d'utilisation à l'esprit pour l'avenir.

Je ne sais pas comment cela résout la «révocation» de l'url de connexion / du jeton API utilisateur. S'ils n'essayaient jamais de se connecter avec oauth après la suppression de leur accès, Grafana ne le saurait jamais.

Je pense que la vue que le client obtient lors de l'utilisation de l'un de ces liens devrait être similaire à celle de l'utilisateur "anonyme", où il ne se connecte pas comme par magie en tant qu'utilisateur particulier, mais obtient plutôt un compte de visionneuse limité, ce qui diviserait totalement cette fonctionnalité à partir de comptes d'utilisateurs individuels. Cela éviterait le problème des autorisations de compte utilisateur individuel, réduirait le niveau de risque car un lien ne pourrait pas être utilisé pour apporter des modifications et permettrait une gestion centralisée de tous les liens d'accès actifs par les administrateurs de l'organisation.

Proposition de solution

1) Introduisez un nouveau concept de «jeton d'URL de visionneuse», que vous pouvez ajouter / supprimer de la page des clés API (nous pouvons créer une nouvelle page pour cela plus tard). Stockez dans une nouvelle table url_token et ils fonctionneront dans une perspective de sécurité très similaire aux clés API. C'est-à-dire qu'ils seront générés et validés de la même manière que les clés API. Le peut cependant être utilisé pour vous connecter via l'utilisation dans l'url avec "& url-auth-token =".
2) Option pour restreindre le jeton pour qu'il ne fonctionne qu'avec l'API de rendu PNG (sera plus sécurisé car les utilisateurs avec un jeton URL ne pourront pas émettre de requête uniquement afficher les tableaux de bord / panneaux existants)
3) À l'avenir, nous devrons trouver un moyen de lier le jeton aux groupes d'utilisateurs et aux autorisations du tableau de bord, sans savoir comment cela fonctionnera encore. Je pense qu'il pourrait être bon de créer un utilisateur factice pour cela qui peut être utilisé pour donner aux utilisateurs "URL Token" des autorisations sur des tableaux de bord et des sources de données spécifiques. Je détesterais avoir à avoir des vérifications / jointures explicites pour les jetons d'url dans les vérifications d'autorisation.

4) Indiquez clairement que toute personne disposant d'un jeton d'URL aura accès à toutes les sources de données de l'organisation (et pourra techniquement émettre n'importe quelle requête) (à moins que l'option restrict to render api ne soit utilisée).

pensées @bergquist @DanCech

Option permettant de restreindre le jeton pour qu'il ne fonctionne qu'avec l'API de rendu PNG (sera plus sécurisé car les utilisateurs avec un jeton URL ne pourront pas émettre de requête uniquement afficher les tableaux de bord / panneaux existants)

Je ne pense pas que le rendu PNG soit une bonne solution. Il scintillera et n'aura pas l'air aussi beau que le vrai Grafana.

J'aime l'idée de connecter le token à un utilisateur. Le moyen le plus simple de connecter ce jeton / connexion aux groupes d'utilisateurs et aux autorisations de dossier du tableau de bord. Mais je pense que la connexion en utilisant le jeton (connexion tv / mode vue / mode tv) devrait forcer l'utilisateur à être dans le rôle Viewer .

Indiquez clairement que toute personne disposant d'un jeton d'URL aura accès à toutes les sources de données de l'organisation (et peut techniquement émettre n'importe quelle requête) (sauf si l'option restrict to render api est utilisée).

L'ajout d'informations et d'avertissements lors de la création de nouveaux jetons peut aider.

Le problème lié à la liaison d'un jeton à un utilisateur "normal" est que cela pose toutes sortes de problèmes lorsque l'utilisateur est modifié ou supprimé. Si les jetons d'url peuvent être membres d'un groupe de la même manière que les utilisateurs, il y aurait une grande flexibilité dans la configuration d'URL individuelles avec accès à des tableaux de bord particuliers, etc.

Je ne suis pas sûr que cela ajouterait beaucoup de complexité aux vérifications des autorisations, vous utiliseriez une table différente pour les membres du groupe selon que le spectateur est un utilisateur régulier ou un jeton d'url, mais les vérifications d'accès dans tout le système ne devraient pas besoin de changer.

En ce qui concerne réellement l’accès aux sources de données, il n’y a pas de différence ici avec les utilisateurs réguliers. La solution finale à ce problème consiste à déplacer les plugins de source de données vers le backend et à faire en sorte que le frontend envoie les demandes de source de données en spécifiant les valeurs du tableau de bord, du panneau, de la plage de temps et du modèle et en faisant construire les requêtes réelles sur le backend après avoir validé que l'utilisateur a accès et que les valeurs du modèle var sont légitimes.

Le problème lié à la liaison d'un jeton à un utilisateur "normal" est que cela pose toutes sortes de problèmes lorsque l'utilisateur est modifié ou supprimé

Le problème que toute personne connaissant un jeton (même si le compte est arrêté) puisse afficher les tableaux de bord est vrai pour les deux solutions. La révocation de l'accès peut être effectuée en supprimant l'utilisateur ou le jeton.

Je ne suis pas sûr que cela ajouterait beaucoup de complexité aux vérifications des autorisations, vous utiliseriez une table différente pour les membres du groupe selon que le spectateur est un utilisateur régulier ou un jeton d'url, mais les vérifications d'accès dans tout le système ne devraient pas besoin de changer.

Les contrôles doivent avoir la même apparence quelle que soit l'authentification. Ce ne sera donc pas un gros problème. L'interface utilisateur pour ajouter des jetons / utilisateurs à des groupes, des tableaux de bord, etc. peut être désordonnée et n'aidera qu'un très petit nombre d'utilisateurs.

En ce qui concerne réellement l’accès aux sources de données, il n’y a pas de différence ici avec les utilisateurs réguliers. La solution finale à ce problème consiste à déplacer les plugins de source de données vers le backend et à faire en sorte que le frontend envoie les demandes de source de données en spécifiant les valeurs du tableau de bord, du panneau, de la plage de temps et du modèle et en faisant construire les requêtes réelles sur le backend après avoir validé que l'utilisateur a accès et que les valeurs du modèle var sont légitimes.

C'est là que je pense que nous devrions commencer à travailler pour offrir une bonne expérience de partage de tableaux de bord de manière sécurisée. Sans cela, toute solution ressemble à de mauvais compromis. Je pense qu'il devrait être maintenu au strict minimum jusqu'à ce que l'accès à la source de données soit résolu.

J'ai également rencontré ce problème avec le tableau de bord intégré en mode username+passwd+ldap auth ...
Une mise à jour à ce sujet?

Je suis très intéressé par l'option de jeton de visionneuse. Si je peux aider de quelque manière que ce soit, je serais heureux de vous aider.

Bonjour gars!
J'essaye de créer un lien authentifié pour un dashbord, j'ai un backend en java et un front end en JSF, je veux mettre un utilisateur sur l'écran qui, lorsqu'il sera cliqué, redirigera l'utilisateur directement vers son dashboar, je Je ne comprends pas bien le concept, quelqu'un Avez-vous un exemple de la façon dont je peux faire cela?

Salut,

Juste une idée, essayant d'aider. Pourquoi ne pas ajouter une nouvelle API utilisateur, en utilisant l'authentification de base comme ceci
? curl https://admin:admin<strong i="7">@localhost</strong>:3000/api/user/cookie
et obtenez un résultat JSON comme
{"user_name":"admin","cookie_name":"grafana_,session":"a0b1c2d3e4","remember":"da27ef425e9e0d"}

Il serait sécurisé via https, et je pourrais utiliser ces informations pour falsifier des cookies et autoriser les utilisateurs à voir leurs magnifiques graphiques.

Je regarde attentivement votre code et je pense ( très respectueusement ) que ce ne serait pas trop difficile.
Au lieu d'envoyer:
user.Rands+user.Password, setting.CookieRememberName, user.Login, days, setting.AppSubUrl+"/"

à la fonction SetSuperSecureCookie, vous pouvez créer une nouvelle fonction, inspirée de SetSuperSecureCookie, quelque chose comme ceci:

func (ctx *Context) NewFunc(secret, name, value string, others ...interface{}) {
   key := pbkdf2.Key([]byte(secret), []byte(secret), 1000, 16, sha256.New)
   text, err := com.AESGCMEncrypt(key, []byte(value))
   return hex.EncodeToString(text)
}

La réponse pourrait être élaborée et envoyée comme dans l'une de vos fonctions comme:

func getUserUserProfile(userId int64) Response {
    query := m.GetUserProfileQuery{UserId: userId}

    if err := bus.Dispatch(&query); err != nil {
        return ApiError(500, "Failed to get user", err)
    }

    cook:= array
    result := {
        user_name: user.name,
                cookie_name:   cookie.name,
        session: s.session,
                remember: cokie.remember

    }

    return Json(200, &result)
}

Je sais que vous n'êtes pas un magicien et que le codage ne joue pas au Lego mais c'est une fonction très importante pour moi. J'essaierais d'aider.

Lors de la GrafanaCon, @DanCech a évoqué l'idée de créer des listes de lecture publiques avec une clé GUID. Similaire à la façon dont les instantanés fonctionnent aujourd'hui. Le partage / le stockage de cette clé peut être considéré comme aussi sûr qu'un jeton API, mais limité à l'affichage de listes de lecture. La liste de lecture peut être associée au créateur / à la mise à jour pour valider les autorisations d'affichage du tableau de bord.

L'URL peut ressembler à quelque chose comme https://play.grafana.com/playlists/public/<hash>

Une chose que j'aime à propos de cette solution est qu'elle limite la fonctionnalité à l'affichage uniquement des listes de lecture (tableau de bord), ce qui, à mon avis, est le plus grand cas d'utilisation de jetons comme celui-ci.

Mais nous aurions toujours besoin de connecter l'utilisateur d'une manière ou d'une autre, car le tableau de bord acl / annotations, etc. nécessitera une authentification côté serveur.

Je suppose que nous pouvons réfléchir davantage à ce genre de solution. Je voulais principalement braindump notre conversation de GrafanaCon :)

Merci @bergquist , c'est vraiment bien de

La prochaine évolution de cette pensée a été d'ajouter le concept d'un «écran» pour découpler davantage les choses, afin que l'utilisateur puisse créer un «écran» qui avait alors une URL hachée secrète à laquelle il se connecterait. Cela servirait le même objectif mais permettrait la gestion des écrans à partir de Grafana, afin que l'utilisateur puisse contrôler quelle playlist a été affichée, etc.

L'objectif final ici serait de prendre en charge un mécanisme permettant à un utilisateur de créer facilement une carte SD ou une image USB qui pourrait être utilisée pour démarrer un Raspberry Pi dédié et afficher la liste de lecture souhaitée en toute sécurité à partir de Grafana sans avoir à sauter à travers les cerceaux d'authentification.

L'objectif final ici serait de prendre en charge un mécanisme permettant à un utilisateur de créer facilement une carte SD ou une image USB qui pourrait être utilisée pour démarrer un Raspberry Pi dédié et afficher la liste de lecture souhaitée en toute sécurité à partir de Grafana sans avoir à sauter à travers les cerceaux d'authentification.

@DanCech C'est exactement le cas d'utilisation que je recherche.

La prochaine évolution de cette pensée a été d'ajouter le concept d'un «écran» pour découpler davantage les choses, afin que l'utilisateur puisse créer un «écran» qui avait alors une URL hachée secrète à laquelle il se connecterait.

@DanCech Cela semble parfait!

Salut à tous,

Cela semble être un peu éloigné du numéro original ouvert par Germanaz0

Cela devrait être bien d'avoir une connexion automatique passant un jeton utilisateur via l'URL, cela pourrait être une solution partielle pour intégrer des iframes sur les sites.

et expliqué par adamlwgriffiths

Nous avons notre propre authentification et nos propres tableaux de bord, nous voulons offrir la possibilité de transmettre un utilisateur de notre tableau de bord à Grafana - dans la même veine que la façon dont Heroku interagit avec New Relic et d'autres services sans mot de passe. Fournir une méthode d'authentification url + token est normal.

Germanaz0 développe un script js

Pour le moment, nous avons résolu ce problème avec un petit hack, en ajoutant un javascript qui se connecte automatiquement à grafana, mais c'est une solution temporelle

Je comprends qu'ils ont besoin d'une connexion automatique pour utiliser grafana chart sur leur propre site. C'est ce dont j'ai besoin sans utiliser de playlist ... Serait-ce possible?

Si vous souhaitez simplement enregistrer automatiquement un utilisateur dans votre meilleur pari, utilisez http://docs.grafana.org/tutorials/authproxy/

@DanCech le problème est que cela permettrait à tous les utilisateurs de se connecter automatiquement. Nous voulons un moyen de ne connecter automatiquement que les utilisateurs qui ont une URL spécifique.

@gzzo qui dépend de la conception du proxy

Je recherche également cette fonctionnalité dans Grafana.
Je pense que l'intégration de Microsoft Power BI est la bonne solution. Voir les liens ci-dessous.
https://github.com/Microsoft/PowerBI-JavaScript/wiki/Embedding-Basics
https://microsoft.github.io/PowerBI-JavaScript/demo/v2-demo/index.html

Je pense que la solution PowerBi ci-dessus est basée sur OAuth2.
Le côté serveur Grafana doit prendre en charge OAuth2 et activer CORS.

@Nayar Je suis nouveau à Grafana. Que voulez-vous dire par le stock Grafana et le stock Nginx que vous avez commentés le 14 septembre 2017? Avez-vous un lien entre les deux?

J'attends avec impatience la version 5.4, je suppose.

Nous avons réussi à le faire avec succès en utilisant Grafana de auth.proxy de Nginx et ngx_http_secure_link_module

Les liens que j'utilise sont au format http://grafana/?user=nayar&md5=2tutcea9nfdsfdsfdsw&expires=1505386800

Une fois que l'utilisateur clique dessus, le cookie de session est défini et l'utilisateur peut parcourir grafana comme s'il s'était connecté normalement.

Avantages:

• Le lien expire après un certain temps + sécurité
• Link génère un hachage avec userid, timestamp et passkey + sécurité
• Pas besoin de taper le mot de passe + commodité

Ma conf nginx est comme ça

server {
  listen 3001 default_server;
#     listen [::]:3001 default_server;

  server_name _;

        location / {
      set $user "";
      set $state "";

      if ($args ~ "^user=(.+)&md5") {
                    set $user $1;
                    set $state "${state}U";
                }

      secure_link $arg_md5,$arg_expires;
                secure_link_md5 "$secure_link_expires$uri$user grafanarocks";

                if ($secure_link = "") { 
                    set $state "${state}S1";
                }

                if ($secure_link = "0") { 
                    set $state "${state}S2";
                }

                add_header X-uristate "$state";

                if ($state = "US1") { return 403; }
                if ($state = "US2") { return 410; }

                add_header X-uri "$user";

                proxy_set_header X-WEBAUTH-USER $user;

                proxy_pass http://127.0.0.1:3000;
            }
    }

N'hésitez pas à me contacter si vous avez besoin d'aide pour cela

Salut Nayar,
J'essaye de faire l'intégration grafana avec le SaaS.
L'exigence est après la connexion de l'utilisateur dans mon application Web, puis cliquez sur le lien «grafana» dans ma page, il sera redirigé vers le tableau de bord grafana sans entrer le nom d'utilisateur et le mot de passe.

Votre commentaire semble répondre à mon exigence. Mais je ne suis toujours pas clair sur le processus d'authentification.
Lorsque proxy_pass à grafana, comment vérifier que l'utilisateur est authentifié par ma propre application.

Mon application Web est via X-XSRF-TOKEN pour vérifier les droits de l'utilisateur.

Je suis nouveau dans la configuration du serveur, nous vous remercions de votre aide.

@torkelo / @bergquist Juste un c'est ainsi que nous avons travaillé autour de cela dans Screenly . C'est en direct et fonctionne très bien! Merci pour le travail acharné, les gars!

@torkelo / @bergquist Juste un c'est ainsi que nous avons travaillé autour de cela dans Screenly . C'est en direct et fonctionne très bien! Merci pour le travail acharné, les gars!

@vpetersson Je n'utilise pas screenly mais je suis curieux de savoir comment vous avez pu implémenter cela. Je comprends la génération d'un jeton API. Avez-vous toujours iframe dans l'URL? Comment avez-vous ajouté le jeton d'authentification dans les en-têtes de demande?

@GimpMaster Nous utilisons juste l'en-tête auth, donc pas besoin d'iframes. Depuis que nous avons écrit le lecteur / navigateur, nous avons pu injecter l'en-tête d'authentification dans le chargement de la page.

Je viens de faire fonctionner mon mode Kiosk en utilisant l'approche de Screenly que @GimpMaster a lié. J'ai utilisé l'extension Chrome ModHeader où j'ai ajouté l'en-tête Authorization avec la clé API Bearer. Mais comme les extensions ont besoin d'un peu de temps pour charger les 10 secondes de mise en veille, la

@Nayar J'ai adapté avec succès votre configuration ngnix suggérée pour utiliser l'accès _unsecure_. Autrement dit, il prend simplement le nom d'utilisateur de la chaîne de requête et le place dans X-WEBAUTH-USER. Cela obtient alors l'identifiant de session a grafana et nous sommes partis. Merci!

Je ne parviens pas à faire fonctionner la méthode md5. Je ne sais pas exactement de quoi j'ai besoin de faire une empreinte digitale md5. Pourriez-vous élaborer? Existe-t-il des astuces pour fabriquer le md5?

Est-il possible de mettre en œuvre des solutions pour se connecter par token / cookie / header / ... dans grafana 6. *?

Je ne peux pas le faire avec un simple panneau de liens dans un PHP vierge

index.php

<html>
<body>
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js" type="text/javascript"></script>
<script language="javaScript">
$( document ).ready(function() {
$.ajax({
        type: "GET",
        //url: "http://page.test;/grafana/",
        url: "http://page.test;/grafana/d/o24Tt1Cik/dashboard-test?orgId=1",
        contentType: "application/json",
        xhrFields: {
            withCredentials: false
        },
        beforeSend: function(request) {
                     request.setRequestHeader("X-WEBAUTH-USER", "admin");
                },
        headers: {
            // Set any custom headers here.
        "X-WEBAUTH-USER" : "admin"
        },
        success: function(data){
                var iframeDoc = $("#monitoringframe").get(0).contentDocument;
                iframeDoc.open();
                iframeDoc.write(data);
                iframeDoc.close();
//$("#monitoringframe").attr('srcdoc',data)
        },
        error : function(err) {
            console.log('Error!', err)
        }
    });
});

</script>
<iframe name="monitoringframe" id="monitoringframe" src="about:blank" sandbox="allow-forms allow-popups allow-same-origin allow-scripts" width=100% height=600 border="0" frameborder="0" />
</body>
</html>

nginx

 server {
  listen 80;
  server_name page.test;
  root /var/www/page;
  index index.html index.htm index.php;

        location ~ \.php$ {
        fastcgi_pass   127.0.0.1:9000;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        include        fastcgi_params;
    }
        location /grafana/ {

                proxy_pass http://localhost:3000/;

       }

}

grafana.ini

[auth.proxy]
# Defaults to false, but set to true to enable this feature
enabled = true
# HTTP Header name that will contain the username or email
header_name = X-WEBAUTH-USER
# HTTP Header property, defaults to `username` but can also be `email`
header_property = username
# Set to `true` to enable auto sign up of users who do not exist in Grafana DB. Defaults to `true`.
auto_sign_up = true
# If combined with Grafana LDAP integration define sync interval
ldap_sync_ttl = 60
# Limit where auth proxy requests come from by configuring a list of IP addresses.
# This can be used to prevent users spoofing the X-WEBAUTH-USER header.
# Example `whitelist = 192.168.1.1, 192.168.1.0/24, 2001::23, 2001::0/120`
whitelist = 127.0.0.1, ::1/120
# Optionally define more headers to sync other user attributes
# Example `headers = Name:X-WEBAUTH-NAME Email:X-WEBAUTH-EMAIL`
headers =

[auth.basic]
;enabled = true

J'ai testé la modification de ma configuration nginx et la définition de "? User = myUser" dans l'URL, mais je n'obtiens qu'une réponse non autorisée

location /grafana/ {

                error_log /var/www/grafana/error.log;
                access_log /var/www/grafana/access.log;

                set $user "";

                if ($args ~ "^user=(.+)") {
                    set $user $1;
                }

                add_header X-uri "$user";

                proxy_set_header X-WEBAUTH-USER $user;

                proxy_pass http://localhost:3000/;

       }

@ mr0bles Tout ce qui documentation . Je n'ai pas vu de solution plus tôt où vous appelez le proxy avec "X-WEBAUTH-USER - généralement vous vous authentifiez dans votre proxy qui à son tour remplit et fournit le X-WEBAUTH-USER à grafana.

@marefr merci pour la réponse.
J'ai lu la documentation et mon API fonctionne, mais j'ai besoin d'une authentification utilisateur dynamique (pas la même autorisation pour tous les utilisateurs de la page)

Cette solution de @Nayar inclut le X-WEBAUTH-USER dans l'en-tête sans le coder en dur, mais je ne peux pas le faire fonctionner

Je pense que quelque chose s'est cassé dans la version 6.0 ou 6.1.
J'ai mis à jour une installation entièrement fonctionnelle en utilisant le proxy d'authentification dans Apache2 vers la version 6.1 hier (à partir de la version 5.3) et j'obtiens exactement les mêmes écrans que

Veuillez noter que Grafana semble comprendre l'en-tête du proxy: il connecte initialement l'utilisateur, mais les demandes suivantes obtiennent une réponse 401.

@Bitblade, nous n'avons reçu aucun autre rapport similaire au vôtre. Veuillez ouvrir un nouveau rapport de bogue car ce problème concerne une demande de fonctionnalité.

Nous avons réussi à le faire avec succès en utilisant Grafana de auth.proxy de Nginx et ngx_http_secure_link_module

Les liens que j'utilise sont au format http://grafana/?user=nayar&md5=2tutcea9nfdsfdsfdsw&expires=1505386800

Une fois que l'utilisateur clique dessus, le cookie de session est défini et l'utilisateur peut parcourir grafana comme s'il s'était connecté normalement.

Avantages:

• Le lien expire après un certain temps + sécurité
• Link génère un hachage avec userid, timestamp et passkey + sécurité
• Pas besoin de taper le mot de passe + commodité

Ma conf nginx est comme ça

server {
  listen 3001 default_server;
#     listen [::]:3001 default_server;

  server_name _;

        location / {
      set $user "";
      set $state "";

      if ($args ~ "^user=(.+)&md5") {
                    set $user $1;
                    set $state "${state}U";
                }

      secure_link $arg_md5,$arg_expires;
                secure_link_md5 "$secure_link_expires$uri$user grafanarocks";

                if ($secure_link = "") { 
                    set $state "${state}S1";
                }

                if ($secure_link = "0") { 
                    set $state "${state}S2";
                }

                add_header X-uristate "$state";

                if ($state = "US1") { return 403; }
                if ($state = "US2") { return 410; }

                add_header X-uri "$user";

                proxy_set_header X-WEBAUTH-USER $user;

                proxy_pass http://127.0.0.1:3000;
            }
    }

N'hésitez pas à me contacter si vous avez besoin d'aide pour cela

Cette solution ne fonctionne pas pour moi. Parce que je pense que chaque demande doit contenir un en-tête X-WEBAUTH-USER valide. Cela ne fonctionne pas si vous remplissez l'en-tête de la première demande, obtenez des cookies et suivez-les.

J'ai terminé avec la solution suivante:

server {
  listen 80 default_server;
  listen [::]:80 default_server;

  client_max_body_size 10m;
  root /foo/public;

  location /grafana/ {
    auth_request /gauth;
    auth_request_set $user $upstream_http_user;

    proxy_set_header X-WEBAUTH-USER $user;
    proxy_pass http://localhost:4000/;
  }

  location / {
    try_files $uri @app;
  }

  location <strong i="23">@app</strong> {
    proxy_pass http://127.0.0.1:3000;
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-SSL-Client-Cert $ssl_client_cert;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_redirect  off;
  }
}

La solution utilise donc le module nginx auth_request. Mon application est responsable du contrôle d'accès (demande / gauth) et renvoie le nom d'utilisateur dans l'en-tête de réponse User .

Bonjour, en attendant, vous pouvez utiliser ma solution qui est décrite ici: https://github.com/guysoft/FullPageOS/issues/175

Voici ma solution de contournement en utilisant l'authentification OAuth générique de Grafana et PHP: https://github.com/nbayramberdiyev/grafana-generic-oauth

J'espère que ceci vous aidera.

je voulais juste commenter comment j'ai résolu cela en utilisant http basic auth https://github.com/grafana/grafana/issues/13706#issuecomment -540958284

Cela devrait être bien d'avoir une connexion automatique passant un jeton utilisateur via l'URL, cela pourrait être une solution partielle pour intégrer des iframes sur les sites.

@rca pouvez-vous donner un exemple avec votre code? Je copie votre code et embed.js, mais cela n'a pas fonctionné.

Si vous utilisez oauth, il existe un moyen de retirer un grafana intégré sans double connexion

1. Configurer grafana avec un seul fournisseur oauth et aucun autre mécanisme de connexion
2. Définissez GF_AUTH_OAUTH_AUTO_LOGIN sur true
3. Hébergez grafana sur un sous-chemin et utilisez un proxy inverse pour que grafana soit servi sur le même hôte que votre application principale
4. Accrochez votre application principale et votre grafana au même fournisseur oauth (au fournisseur oauth, ce sera la même "application")
5. Incorporer grafana
6. Lorsque l'iframe se charge, grafana essaiera de se connecter automatiquement avec oauth (ce qui devrait réussir car il est sur le même domaine que votre application principale, partageant ainsi le même cookie d'authentification)

EDIT: Vous devrez peut-être définir security.cookie_samesite=none dans grafana pour que cela fonctionne correctement dans certains navigateurs (C'est parce que dans l'iframe, une redirection vers le fournisseur oauth (domaine différent) se produit, puis une redirection vers votre domaine grafana. Actuellement, Firefox ne permettra pas à un cookie du même site défini sur lax de persister de cette manière. https://bugzilla.mozilla.org/show_bug.cgi?id=1454027 ce qui signifie que grafana perd son oauth_state cookie si cookie_samesite n'est pas défini sur none )

@seanlaff J'ai essayé votre solution avec AWS Cognito mais elle renvoie un en-tête qui ne permet pas de la mettre dans une iframe (X-Frame-Options: deny), des conseils à ce sujet?

Nous avons réussi à le faire avec succès en utilisant Grafana de auth.proxy de Nginx et ngx_http_secure_link_module
Les liens que j'utilise sont au format http://grafana/?user=nayar&md5=2tutcea9nfdsfdsfdsw&expires=1505386800
Une fois que l'utilisateur clique dessus, le cookie de session est défini et l'utilisateur peut parcourir grafana comme s'il s'était connecté normalement.
Avantages:

• Le lien expire après un certain temps + sécurité
• Link génère un hachage avec userid, timestamp et passkey + sécurité
• Pas besoin de taper le mot de passe + commodité

Ma conf nginx est comme ça

server {
    listen 3001 default_server;
#   listen [::]:3001 default_server;

    server_name _;

        location / {
        set $user "";
        set $state "";

        if ($args ~ "^user=(.+)&md5") {
                    set $user $1;
                    set $state "${state}U";
                }

        secure_link $arg_md5,$arg_expires;
                secure_link_md5 "$secure_link_expires$uri$user grafanarocks";

                if ($secure_link = "") { 
                    set $state "${state}S1";
                }

                if ($secure_link = "0") { 
                    set $state "${state}S2";
                }

                add_header X-uristate "$state";

                if ($state = "US1") { return 403; }
                if ($state = "US2") { return 410; }

                add_header X-uri "$user";

                proxy_set_header X-WEBAUTH-USER $user;

                proxy_pass http://127.0.0.1:3000;
            }
    }

N'hésitez pas à me contacter si vous avez besoin d'aide pour cela

Cette solution ne fonctionne pas pour moi. Parce que je pense que chaque demande doit contenir un en-tête X-WEBAUTH-USER valide. Cela ne fonctionne pas si vous remplissez l'en-tête de la première demande, obtenez des cookies et suivez-les.

J'ai terminé avec la solution suivante:

server {
  listen 80 default_server;
  listen [::]:80 default_server;

  client_max_body_size 10m;
  root /foo/public;

  location /grafana/ {
    auth_request /gauth;
    auth_request_set $user $upstream_http_user;

    proxy_set_header X-WEBAUTH-USER $user;
    proxy_pass http://localhost:4000/;
  }

  location / {
    try_files $uri @app;
  }

  location <strong i="24">@app</strong> {
    proxy_pass http://127.0.0.1:3000;
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-SSL-Client-Cert $ssl_client_cert;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_redirect  off;
  }
}

La solution utilise donc le module nginx auth_request. Mon application est responsable du contrôle d'accès (demande / gauth) et renvoie le nom d'utilisateur dans l'en-tête de réponse User .

comment utiliser avec iframe?
je suis nouveau sur Grafana et NGINX
alors veuillez partager le maximum de détails maintenant pour modifier

comment utiliser avec iframe?

@pgsekaran cette solution n'est pas pour iframe, mais pour obtenir une interface utilisateur grafana sans connexion grafana explicite pour les utilisateurs de votre application. Dans ce cas, l'application est un proxy qui sait se connecter à grafana.

Salut,
Merci pour une réponse rapide. avez-vous un lien avec référence pour ajouter le Grafana avec une autre application en utilisant iframe.i ajouter Grafana à mon application mais je ne suis pas en mesure de définir la gestion de l'utilisation.
CordialementGuna
Le mardi 23 juin 2020 à 09:54:57 GMT + 5: 30, Konstantin Kolotyuk [email protected] a écrit:

comment utiliser avec iframe?

@pgsekaran cette solution n'est pas pour iframe, mais pour obtenir une interface utilisateur grafana sans connexion grafana explicite pour les utilisateurs de votre application. Dans ce cas, l'application est un proxy qui sait se connecter à grafana.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub ou désabonnez-vous.

N'est-il toujours pas mis en œuvre? Sérieusement, c'est une bonne fonctionnalité.

@pgsekaran J'ai une solution pour iframe, qui n'est pas très sécurisée car elle utilise une connexion basée sur le nom d'utilisateur et repose sur des noms d'utilisateurs difficiles à deviner. fondamentalement, le nom d'utilisateur est le jeton.
ive écrit à ce sujet ici, pas en détail mais eouhg pour vous aider à démarrer
https://blog.yadamiel.com/tutorials/embed-and-authenticate-grafana-in-a-iframe

@pgsekaran J'ai une solution pour iframe, qui n'est pas très sécurisée car elle utilise une connexion basée sur le nom d'utilisateur et repose sur des noms d'utilisateurs difficiles à deviner. fondamentalement, le nom d'utilisateur est le jeton.
ive écrit à ce sujet ici, pas en détail mais eouhg pour vous aider à démarrer
https://blog.yadamiel.com/tutorials/embed-and-authenticate-grafana-in-a-iframe

Salut,

J'ai besoin de configurer avec NGINX et iframe avec connexion automatique

Le problème exact a été expliqué dans https://github.com/grafana/grafana/issues/16319#issuecomment -483272921: L'identifiant de session n'est pas retourné avec la première réponse qui contient la page "squelette". Les demandes suivantes ne contiennent pas de jeton de connexion automatique, elles échouent donc.

Nous utilisons le chrome en mode kiosque pour afficher les tableaux de bord Grafana à divers endroits. Comme la même instance Grafana est également disponible pour les utilisateurs, nous utilisons auth.generic_oauth ( auth.basic jusqu'à 5.x) pour connecter les humains et auth.proxy pour se connecter aux machines en mode kiosque:

/usr/bin/chromium --app="https://server.localdomain/grafana/d/000000004/002-the-big-picture?orgId=1&refresh=5m&autologin=lHOrdypkhxzNYb2lRaIjbNPlOCZw9gWE"

Comme d'autres l'ont noté, cela ne fonctionne pas simplement. Ce qui fonctionnerait, c'est d'appeler d'abord l'url http://prometheus.localdomain/grafana/login?autologin=lHOrdypkhxzNYb2lRaIjbNPlOCZw9gWE (qui définit maintenant le cookie grafana_session ), puis de la rediriger vers le tableau de bord réel. Mais ... mode kiosque 🤷 et iframes 🤦‍♂️

Notre dernière solution de travail consiste à combiner le paramètre de requête autologin avec un cookie personnalisé. Oui, vous ne pouvez pas vous déconnecter via l'interface graphique car le cookie personnalisé n'est pas supprimé, mais comme ce mécanisme n'est utilisé que sur les machines en mode kiosque, cela n'était pas nécessaire.

Voici donc la configuration nginx pour le serveur Grafana:

# this maps tokens to grafana users
map $arg_autologin $autologin {
    lHOrdypkhxzNYb2lRaIjbNPlOCZw9gWE "display-1";
    default "";
}

server {
    listen 80;

    server_name server.localdomain;

    # add_header cannot be used in an "if"-context
    # so we set it to an empty string here as 
    # `add_header Set-Cookie "";` just removes the complete
    # header from the response
    set $setCookieHeader "";

    # when the autologin query param is not set, use
    # the value from the cookie named `grafana_autologin`
    if ($arg_autologin = "") {
        set $arg_autologin $cookie_grafana_autologin;
    }

    # when either the autologin query param or the `grafana_autologin`
    # cookie was set, place the autologin token and the cookie path
    # in the variable. `path=/` is needed to allow deeplinking
    if ($arg_autologin != "") {
        set $setCookieHeader "grafana_autologin=$arg_autologin;path=/";
    }

    location /grafana/ {
        rewrite  ^/grafana/(.*)  /$1 break;

        # now send the Set-Cookie header when an autologin token was provided
        add_header Set-Cookie $setCookieHeader;

        # look up the autologin token in the map above and set the grafana user
        proxy_set_header X-WEBAUTH-USER $autologin;
        proxy_pass http://localhost:3000;
    }
}