Grafana: Automatische Anmeldung per Token-URL

wäre ziemlich unsicher, da jeder das Token sehen kann, können Sie einen Schnappschuss der sichtbaren Daten erstellen und diese einbetten, es wäre sicherer

Ja, aber mit Snapshots haben Sie keine Berechtigung zum Bearbeiten, oder gibt es eine Möglichkeit, das Dashboard über Snapshots zu bearbeiten?

Dies ist sehr wichtig für die Interoperabilität mit SaaS.
Wir haben unsere eigene Authentifizierung und Dashboards. Wir möchten die Möglichkeit bieten, einen Benutzer von unserem Dashboard an Grafana weiterzuleiten - ähnlich wie Heroku mit New Relic und anderen Diensten mit Null-Passwörtern zusammenarbeitet.

Das Bereitstellen einer URL + Token-Authentifizierungsmethode ist selbstverständlich.
Wenn jemand dies dann auf einer öffentlichen Website einbettet, wird diese Person durch keine Sicherheitsmaßnahme vor sich selbst gerettet. Das ist ihre Schuld.
Das Bereitstellen ausreichender Warnungen in der Dokumentation / Benutzeroberfläche sollte hierfür in Ordnung sein.

Ohne diese Funktion müssen Benutzer auf einen zweiten Anmeldebildschirm stoßen, auf dem sie verwirrt sind, welchen Benutzernamen / welches Passwort sie eingeben sollen.

Dies ist ein großer Blocker für uns.

Klingt nach einer guten Funktion in Grafana. Ich würde gerne bei der PR helfen, da es so viele andere Dinge gibt, die momentan wirklich hohe Priorität haben

Schöne Erklärung @adamlwgriffiths das gleiche passiert mir.

Im Moment haben wir dieses Problem mit einem kleinen Hack gelöst und ein Javascript hinzugefügt, das sich automatisch bei grafana anmeldet, aber eine zeitliche Lösung darstellt

+10 dafür !!
Um dies zu gewährleisten, sollte im Token ein Hash des Benutzernamens + Passworts + Datums enthalten sein. Dies kann verwendet werden, um das Token nach x Stunden abzulaufen, um die Sicherheit zu verbessern.

Wenn ich etwas Zeit habe, werde ich ernsthaft darüber nachdenken, daran zu arbeiten

Wenn Sie das Erstellungsdatum des Tokens speichern, damit Sie es ablaufen lassen können, speichern Sie auch den Hash und das zugehörige Konto, sodass ich nicht denke, dass der Hash aus bestimmten Daten generiert werden muss. Es muss nur ein ausreichend großer Suchraum vorhanden sein, um das Erraten unmöglich zu machen.

@adamlwgriffiths , dies sollte auch einige grundlegende Rollen unterstützen .. wie Viewer, Editor .. usw., ähnlich wie bei den API-Schlüsseln .. Vielleicht könnten wir das einfach erweitern, damit wir einen API-Schlüssel per URL übergeben können?

Ich denke, auf lange Sicht muss das Benutzer- / Organisations- / API-Token konsolidiert werden, anstatt eine neue Methode hinzuzufügen.
Wenn die API-Token erweitert würden, um die Verwendung über die HTML-Oberfläche zu ermöglichen, wäre dies kein Problem.
Die API-Token haben bereits Rollen und können widerrufen werden. Sie müssen daher nur für die Webansicht und nicht für die reine API verwendet werden können.

IMO-API-Token sollten genauso funktionieren wie normale Benutzer. Es gibt eine willkürliche Trennung, die nicht dokumentiert ist, und ich finde sie kontraintuitiv. Ich denke, es wäre das Beste, alle Anmeldeprüfungen zu aktivieren, um auch nach API-Schlüsseln zu suchen.

Wurde diese Funktion implementiert? Ich habe versucht, einen Benutzer automatisch von meiner Website zum grafana-Dashboard umleiten zu lassen.

@comcomservices Als Folgemaßnahme zum Token selbst können Sie Informationen im Token definitiv mit der Benutzer-ID und der

Ich zögere, so etwas zu empfehlen. Ich bin der festen Überzeugung, dass Kryptografie schwierig ist, und ohne ein umfassendes Verständnis dessen, was Sie tun, ist es keine gute Idee, dies zu versuchen.

Das andere Problem bei verschlüsselten Token ist, dass sie ziemlich groß sind und je mehr Informationen, desto größer werden sie.
Wobei eine zufällige Zeichenkette auf eine beliebige Länge gebracht werden kann, solange der Raum groß genug ist, um rohe Gewalt unmöglich zu machen.

@adamlwgriffiths Was die Kryptographie völlig einig, dass ein Token am besten wäre für viel zu lange ... Ich werde es aber bekommen und dies ist zuerst auf meiner Liste

Ich freue mich auf diese Funktion! In Bezug auf den obigen Kommentar von zuzuordnen , die es anfordern sollte; Auf diese Weise funktioniert dieses Token nur, wenn der Ursprung übereinstimmt. Ein Beispiel dafür - wieder, wenn ich das Problem richtig verstehe - ist Sentrys Raben-js ; Es wird eine öffentliche URL erstellt und diese dann nach Herkunft eingeschränkt (siehe unten). Würde dies die Sicherheitsbedenken mindern?

@ Germanaz0 ist dein Auto-Login JS öffentlich verfügbar? Ich möchte etwas Ähnliches für den Master-Zweig implementieren, und es scheint, dass das Backend vor dem Aufrufen der Dashboard-Seite zum Anmeldebildschirm umleitet. Ich bin mit der Projektstruktur noch nicht besonders vertraut, daher stecke ich möglicherweise nicht in den richtigen Abschnitt des JS-Codes.

@rca ja, aber meine Lösung ist super einfach https://gist.github.com/Germanaz0/d41b5f60dd8097405b6b

Sie erhalten einen Eingabeparameter wie? T = base64 eines json mit {user: _USERNAME_, pass: _PASS_, redirect_to: _URL_TO_REDIRECT}

Sie müssen dieses Skript in die Anmeldeseite aufnehmen.

@ Germanaz0 , danke fürs Teilen! Nachdem ich meinen Kommentar gesendet hatte, begann ich einen Blick darauf zu werfen und stellte, wie Sie betonten, fest, dass ich die Anmeldeseite aktualisieren musste. Ich habe einen etwas anderen Ansatz gewählt und den Login-Controller aktualisiert, anstatt ein eigenständiges Skript zu erstellen. Meine Änderung ist hier: https://github.com/zymbit/grafana/tree/auto-login-by-cookie-redirect

Ist dies eine Pull-Anfrage wert? Ich würde gerne die Mods machen, die notwendig sind, um dies in einen zusammenführbaren Zustand zu bringen.

Gibt es hierzu Neuigkeiten?
@rca Hast du eine PR erstellt?

+1 für eine PR von @rca

@ Germanaz0 , in welcher Datei enthalten Sie Ihre .js-Datei?

@rca hast du

Übrigens, wenn jemand einen Weg braucht, um dies für Kioske usw. zu erreichen, suchen Sie Grafanas Authproxy heraus . Mit diesem und Apache konnte ich erreichen, was ich brauchte.

@scottfuhrman Nichts formelles geschrieben, aber hier ist mein Anwendungsfall und meine Implementierung:

Ich habe nicht nach dem Kioskmodus gesucht, sondern nach einer Möglichkeit, ein Dashboard als Iframe auf einer externen Seite einzubetten. Die Diagramme sind ziemlich sauber eingebettet, zum Beispiel:

Auf der Seite, auf der Sie das Dashboard einbetten möchten, benötigen Sie das folgende Markup:

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

Hoffe das hilft.

+1

Ich habe nicht die personellen Ressourcen dafür, aber ich würde gerne die Anstrengungen dafür über Crowdfunding finanzieren.

Ich dachte, ich hätte das gelöst, bis ich versuchte, eine Wiedergabeliste zu verwenden. Die Verwendung von authproxy funktioniert für ein bestimmtes Dashboard, aber als ich eine Wiedergabeliste mit mehreren Dashboards ausprobierte, stieß ich auf dasselbe Problem. Ich verstehe den Sinn eines Kiosk-Modus nicht, wenn es unmöglich ist, eine echte Kiosk-Anwendung zu implementieren, wenn wir die Anzeigesicherheit nicht vollständig deaktivieren.

@torkelo Ich habe @ over64 angeworben, um für mich

Wie empfehlen Sie die Implementierung? Grundsätzlich brauche ich ein Token in der URL-Zeichenfolge, das die Authentifizierung umgeht / löst. Was ist der beste Ansatz dafür?

Ich bin mir nicht sicher, müsste untersuchen, wie eine solche Funktion sicher implementiert werden sollte

Habe es. Wir sind bereit, sobald Sie einen Plan ausgearbeitet haben :)

Wenn Sie eine Idee haben, lassen Sie es mich bitte wissen und ich kann sie bewerten

In Ordung. @ over64 wird einen Blick darauf werfen und etwas vorschlagen.

@torkelo Können Sie sich die PR von @ over64 in # 7431 ansehen, um zu sehen, ob dies sinnvoll ist

Irgendeine einfache Problemumgehung? Ich versuche, die @ Germanaz0- Lösung zu implementieren, aber sie funktioniert bei mir nicht :(

Dies ist ein Muss, sonst wird das Einbetten von Snapshots in iframe blockiert. Die eingebettete Snapshot-URL sollte den Anmeldeschlüssel / das Token unterstützen.

Hallo allerseits,

Neuere Kommentare in diesem Thread beziehen sich auf:

• Sicherheit
• Einbettung in einen Iframe

In Bezug auf die Sicherheit beachten Sie bitte meinen alten Kommentar oben: https://github.com/grafana/grafana/issues/3752#issuecomment -200874453

Und zum Einbetten in einen Iframe: https://github.com/grafana/grafana/issues/3752#issuecomment -267062843

Dieser Zweig (wenn auch ziemlich alt) enthält Code, der aus dem Diskurs entlehnt wurde und die Größe eines Iframes gut festlegt sowie sich über ein Token authentifiziert, wie im obigen Kommentar beschrieben.

@torkelo Bitte lassen Sie mich wissen, wenn Sie eine Pull-Anfrage mit den oben genannten Elementen in Betracht ziehen würden.

@rca Was ist das Embed.js in Ihrem Code oben?

@zoell Es sind einige Js, die aus dem Discourse-Projekt entlehnt wurden, um die Größe eines Iframes auf der Seite basierend auf dem eingebetteten Inhalt mit dem Frame zu ändern.

@rca oh danke. Ich konnte diese Datei in dem von Ihnen erwähnten Zweig nicht finden. Ist das woanders erhältlich?

@zoell , ich werde dieses Repo einfügen , wie sie dort sein sollte.

@rca danke das wäre toll.

@rca Es tut mir leid, ich kann die Datei in dem zuvor erwähnten Zweig immer noch nicht finden.

@TinaRen @zoell Ich habe den Ball darauf fallen lassen, entschuldige.

Nach einem kurzen Blick sieht es jedoch so aus, als wäre die Datei die ganze Zeit dort gewesen! 😬

Ich werde weitere Arbeiten dazu durchführen unter:

https://github.com/rca/grafana

Und die Datei ist bei:

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

Wenn diese Datei nicht erstellt wird und im Verzeichnis public_gen/ landet, lassen Sie es mich bitte wissen.

Vielen Dank!

Ist es möglich, grafana zumindest auf localhost-Zugriffe zu beschränken? (um die Panel-Freigabe auf dieselbe Server-Site zu beschränken)

Ich würde gerne jemanden sehen, der dies mit einer ordnungsgemäßen Implementierung versucht, die vorgelagert werden kann. Die von uns vorgeschlagene Lösung (Nr. 7431) wurde nie akzeptiert :(

Ich bin froh, dass jemand von unserer Seite etwas Zeit damit verbringt, aber wir brauchen eine Anleitung, was stromaufwärts akzeptabel wäre.

Verwalten dies mit Erfolg Grafana des mit auth.proxy und Nginx von ngx_http_secure_link_module

Die von mir verwendeten Links haben das Format http://grafana/?user=nayar&md5=2tutcea9nfdsfdsfdsw&expires=1505386800

Sobald der Benutzer darauf klickt, wird das Sitzungscookie gesetzt und der Benutzer kann grafana durchsuchen, als ob er sich normal angemeldet hätte.

Vorteile:

• Link läuft nach einiger Zeit + Sicherheit ab
• Link generiert Hash mit Benutzer-ID, Zeitstempel und Passkey + Sicherheit
• Sie müssen kein Passwort und keine Bequemlichkeit eingeben

Mein Nginx Conf ist so

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

Nehmen Sie Kontakt mit mir auf, wenn Sie Hilfe benötigen

Sehr interessant, @Nayar. Mein Anliegen bei dieser Lösung ist jedoch, dass eine große Anzahl von Anpassungen erforderlich ist. Ich würde etwas bevorzugen, das von Haus aus in Grafana eingebaut ist.

Ich habe eine Aktie Grafana verwendet. Musste nur einen Stock Nginx mit aktiviertem Modul neu kompilieren und das wars.

Nayar, können Sie mir bitte mitteilen, ob die von Ihnen implementierte Lösung mit allen Versionen von grafana funktioniert. Ich bin neu in Grafana. In meiner Organisation haben sie bereits installiert

Einige Ideen (und Probleme) zur Lösung dieses Problems herausarbeiten.

Schnellste Lösung:

1) Fügen Sie einem API-Schlüssel einen speziellen Typ (Flag) hinzu, damit er in der URL verwendet werden kann, um Sie anzumelden.

Proos: API-Schlüssel können nur von Org-Administratoren hinzugefügt werden.

2) Ermöglichen Sie Benutzern das Erstellen von API-Schlüsseln und URL-Schlüsseln (Variante des API-Schlüssels).

Probleme dabei werden oauth-Setups sein, bei denen ein Benutzer, wenn er einen API-Schlüssel oder einen URL-Schlüssel erstellen kann, diesen verwenden kann, nachdem ihm der Zugriff von Grafana (vom oauth-System) entfernt wurde. Da der API-Schlüssel oder der URL-Schlüssel keine automatische Anmeldung erfordert. Dies wird ein großes Problem für Benutzer-API-Schlüssel sein, wenn wir sie schließlich tun. Eine mildernde Lösung könnte darin bestehen, nur Organisationsadministratoren oder Grafana-Serveradministratoren zu erlauben, Benutzer-API-Schlüssel zu erstellen.

Gedanken @DanCech ? Verwenden Sie einen API-Schlüssel mit einem AllowUrlLogin-Flag?

Ich denke nicht, dass die Verwendung der API-Schlüsselinfrastruktur der richtige Weg ist, da es schwierig ist, später weitere Funktionen hinzuzufügen (z. B. die URL auf einen bestimmten Satz von Dashboards zu beschränken, sodass Nicht-Administratoren Anmeldelinks erstellen können ) und ist wahrscheinlich für Benutzer verwirrend. Wir könnten sicherlich dieselben Konzepte verwenden und eine ähnliche Backend-Struktur haben, aber es gibt uns mehr Optionen, wenn wir sie trennen, und ich denke, dass dies für die Benutzer klarer sein wird.

Was die Frage nach dem Oauth-Login betrifft, müssen wir meiner Meinung nach herausfinden, welchen Umfang der Umfang hier haben sollte. Das gleiche Problem besteht für oauth-Benutzer, wenn Sie auch Kennwörter aktiviert haben, da diese ein lokales Kennwort festlegen können und sich auf diese Weise anmelden können, nachdem das oauth-Konto deaktiviert wurde. Die einzige wirkliche Lösung für dieses Problem besteht darin, diesen Link im Benutzerkonto zu speichern und immer einen oauth-Benutzer durch die oauth-Umleitungsschleife zu senden, bevor er seine Anmeldung akzeptiert.

Ich denke auch, dass wir einen vernünftigen Namen für diese Funktionalität finden müssen. "Anmelde-URL" ist möglicherweise zu breit und lässt in Zukunft keinen Platz mehr, um beispielsweise einen auf ein bestimmtes Dashboard beschränkten Live-Link freizugeben.

@mattttt würde gerne Ihre Gedanken bekommen

da es schwierig ist, später weitere Funktionen hinzuzufügen (z. B. Beschränkung der URL auf einen bestimmten Satz von Dashboards, sodass Nicht-Administratoren Anmeldelinks erstellen können)

Ich zögere, diese Anmeldefunktion mit Berechtigungen zu verknüpfen oder auf bestimmte Dashboards zu beschränken (außer sie mit einer Organisationsrolle oder einem Benutzer zu verknüpfen). Dies würde zu einer Freigabefunktion führen und Sicherheitserwartungen festlegen, die nicht erfüllt werden (da Sie alle Daten aus einer Datenquelle abfragen können, die von einer Organisation verwendet wird).

Die einzige wirkliche Lösung für dieses Problem besteht darin, diesen Link im Benutzerkonto zu speichern und immer einen oauth-Benutzer durch die oauth-Umleitungsschleife zu senden, bevor er seine Anmeldung akzeptiert.

Nicht sicher, wie dies das "Widerrufen" der Anmelde-URL / des Benutzer-API-Tokens löst. Wenn sie niemals versuchen würden, sich mit oauth anzumelden, nachdem ihr Zugriff entfernt wurde, würde Grafana es nie erfahren.

@hemsush Laut diesem Blog-Beitrag sollte es ab Grafana 2.0 funktionieren: https://grafana.com/blog/2015/12/07/grafana-authproxy-have-it-your-way/

Ich zögere, diese Anmeldefunktion mit Berechtigungen zu verknüpfen oder auf bestimmte Dashboards zu beschränken (außer sie mit einer Organisationsrolle oder einem Benutzer zu verknüpfen). Dies würde zu einer Freigabefunktion führen und Sicherheitserwartungen festlegen, die nicht erfüllt werden (da Sie alle Daten aus einer Datenquelle abfragen können, die von einer Organisation verwendet wird).

Das ist ein Problem, das gelöst werden muss. Mein Vorschlag wäre daher, dieses System unter Berücksichtigung dieses Anwendungsfalls für die Zukunft zu entwickeln.

Nicht sicher, wie dies das "Widerrufen" der Anmelde-URL / des Benutzer-API-Tokens löst. Wenn sie niemals versuchen würden, sich mit oauth anzumelden, nachdem ihr Zugriff entfernt wurde, würde Grafana es nie erfahren.

Meiner Meinung nach sollte die Ansicht, die der Client erhält, wenn er einen dieser Links verwendet, der des "anonymen" Benutzers ähneln, bei dem er nicht magisch als bestimmter Benutzer angemeldet ist, sondern ein eingeschränktes Viewer-Konto erhält, wodurch diese Funktion vollständig geschieden würde von einzelnen Benutzerkonten. Dies würde das Problem der Berechtigungen für einzelne Benutzerkonten umgehen, das Risiko verringern, da ein Link nicht für Änderungen verwendet werden kann, und eine zentrale Verwaltung aller aktiven Zugriffslinks durch Organisationsadministratoren ermöglichen.

Lösungsvorschlag

1) Führen Sie das neue Konzept "Viewer URL Token" ein, das Sie zur API-Schlüsselseite hinzufügen / daraus entfernen können (wir können später eine neue Seite dafür erstellen). Speichern Sie in der neuen Tabelle url_token und sie funktionieren aus Sicherheitsgründen sehr ähnlich wie API-Schlüssel. Das heißt, sie werden genauso generiert und validiert wie API-Schlüssel. Das kann jedoch verwendet werden, um Sie über die Verwendung in url mit "& url-auth-token =" anzumelden".
2) Option, das Token so einzuschränken, dass es nur mit der PNG-Render-API funktioniert (ist sicherer, da Benutzer mit URL-Token keine Abfrage ausgeben können, nur vorhandene Dashboards / Panels anzeigen).
3) In Zukunft müssen wir einen Weg finden, das Token mit Benutzergruppen und Dashboard-Berechtigungen zu verknüpfen. Wir sind uns noch nicht sicher, wie das funktionieren wird. Ich denke, es könnte gut sein, einen Dummy-Benutzer dafür zu erstellen, der verwendet werden kann, um den Benutzern des "URL-Tokens" Berechtigungen für bestimmte Dashboards und Datenquellen zu erteilen. Würde es hassen, explizite Überprüfungen / Verknüpfungen für URL-Token in Berechtigungsprüfungen haben zu müssen.

4) Stellen Sie klar, dass jeder Benutzer mit einem URL-Token Zugriff auf alle Datenquellen des Unternehmens hat (und technisch jede Abfrage ausgeben kann) (es sei denn, die Option "API rendern einschränken" wird verwendet).

Gedanken @bergquist @DanCech

Option, das Token so einzuschränken, dass es nur mit der PNG-Render-API funktioniert (ist sicherer, da Benutzer mit URL-Token keine Abfrage ausgeben können, nur vorhandene Dashboards / Panels anzeigen)

Ich denke nicht, dass PNG-Rendering eine gute Lösung ist. Es wird flackern und es wird nicht so schön aussehen wie echtes Grafana.

Ich mag die Idee, das Token mit einem Benutzer zu verbinden. Der einfachste Weg, um dieses Token / diese Anmeldung mit Benutzergruppen und Dashboard-Ordnerberechtigungen zu verbinden. Ich denke jedoch, dass die Anmeldung mit dem Token (TV-Anmeldung / Ansichtsmodus / TV-Modus) den Benutzer dazu zwingen sollte, die Rolle Viewer übernehmen.

Stellen Sie klar, dass jeder Benutzer mit einem URL-Token Zugriff auf alle Datenquellen des Unternehmens hat (und technisch jede Abfrage ausgeben kann) (es sei denn, die Option "API rendern einschränken" wird verwendet).

Das Hinzufügen von Informationen und Warnungen beim Erstellen neuer Token kann hilfreich sein.

Das Problem beim Binden eines Tokens an einen "normalen" Benutzer besteht darin, dass es alle möglichen Probleme verursacht, wenn der Benutzer geändert oder gelöscht wird. Wenn die URL-Token auf die gleiche Weise wie Benutzer Mitglieder einer Gruppe sein können, besteht eine enorme Flexibilität beim Einrichten einzelner URLs mit Zugriff auf bestimmte Dashboards usw.

Ich bin nicht sicher, ob dies die Berechtigungsprüfungen erheblich komplexer machen würde. Sie würden eine andere Tabelle für die Gruppenmitglieder verwenden, je nachdem, ob der Viewer ein regulärer Benutzer oder ein URL-Token ist, aber die Zugriffsprüfungen im gesamten System sollten dies nicht tun Änderungsbedarf.

In Bezug auf die tatsächliche Durchsetzung des Zugriffs auf die Datenquellen gibt es hier keinen Unterschied als bei normalen Benutzern. Die Endlösung für dieses Problem besteht darin, die Datenquellen-Plugins in das Backend zu verschieben und die Datenquellenanforderungen für das Frontend zu versenden, indem Dashboard-, Panel-, Zeitbereichs- und Vorlagenvariablenwerte angegeben werden und die tatsächlichen Abfragen auf dem Backend erstellt werden, nachdem der Benutzer überprüft hat hat Zugriff und dass die var-Werte der Vorlage legitim sind.

Das Problem beim Binden eines Tokens an einen "normalen" Benutzer besteht darin, dass es alle möglichen Probleme verursacht, wenn der Benutzer geändert oder gelöscht wird

Das Problem, dass jeder, der ein Token kennt (auch wenn das Konto geschlossen ist), Dashboards anzeigen kann, gilt für beide Lösungen. Das Widerrufen des Zugriffs kann durch Löschen eines Benutzers oder Tokens erfolgen.

Ich bin nicht sicher, ob dies die Berechtigungsprüfungen erheblich komplexer machen würde. Sie würden eine andere Tabelle für die Gruppenmitglieder verwenden, je nachdem, ob der Viewer ein regulärer Benutzer oder ein URL-Token ist, aber die Zugriffsprüfungen im gesamten System sollten dies nicht tun Änderungsbedarf.

Die Überprüfungen sollten unabhängig von der Authentifizierung gleich aussehen. Das wird also kein großes Problem sein. Die Benutzeroberfläche zum Hinzufügen von Token / Benutzern zu Gruppen, Dashboards usw. ist möglicherweise unübersichtlich und hilft nur einer sehr kleinen Anzahl von Benutzern.

In Bezug auf die tatsächliche Durchsetzung des Zugriffs auf die Datenquellen gibt es hier keinen Unterschied als bei normalen Benutzern. Die Endlösung für dieses Problem besteht darin, die Datenquellen-Plugins in das Backend zu verschieben und die Datenquellenanforderungen für das Frontend zu versenden, indem Dashboard-, Panel-, Zeitbereichs- und Vorlagenvariablenwerte angegeben werden und die tatsächlichen Abfragen auf dem Backend erstellt werden, nachdem der Benutzer überprüft hat hat Zugriff und dass die var-Werte der Vorlage legitim sind.

Hier sollten wir meiner Meinung nach anfangen, eine gute Erfahrung für die sichere Freigabe von Dashboards zu bieten. Ohne dies fühlt sich jede Lösung wie ein schlechter Kompromiss an. Ich denke, es sollte auf ein Minimum beschränkt werden, bis der Zugriff auf die Datenquelle gelöst ist.

Ich habe dieses Problem auch beim Einbetten des Dashboards im username+passwd+ldap auth -Modus festgestellt ...
Irgendwelche Updates dazu?

Ich bin sehr an der Viewer-Token-Option interessiert. Wenn ich in irgendeiner Weise helfen kann, würde ich gerne helfen.

Hallo Leute!
Ich versuche, einen authentifizierten Link für ein Dashbord zu erstellen. Ich habe ein Backend in Java und ein Frontend in JSF. Ich möchte einen Benutzer auf den Bildschirm bringen, der den Benutzer beim Klicken direkt zu seinem Dashboar I umleitet Ich verstehe das Konzept nicht gut, jemand. Haben Sie ein Beispiel dafür, wie ich das machen kann?

Hallo,

Nur eine Idee, um zu helfen. Fügen Sie eine neue Benutzer-API hinzu, indem Sie die Basisauthentifizierung wie folgt verwenden
? curl https://admin:admin<strong i="7">@localhost</strong>:3000/api/user/cookie
und erhalten Sie ein JSON-Ergebnis wie
{"user_name":"admin","cookie_name":"grafana_,session":"a0b1c2d3e4","remember":"da27ef425e9e0d"}

Es würde über https gesichert, und ich könnte diese Informationen verwenden, um Cookies zu fälschen und Benutzer zu autorisieren, ihre schönen Diagramme zu sehen.

Ich schaue aufmerksam auf Ihren Code und denke ( sehr respektvoll ), dass es nicht allzu schwierig sein würde.
Stattdessen senden:
user.Rands+user.Password, setting.CookieRememberName, user.Login, days, setting.AppSubUrl+"/"

Mit der SetSuperSecureCookie-Funktion können Sie eine neue Funktion erstellen, die von SetSuperSecureCookie inspiriert ist.

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

Die Antwort könnte ausführlich sein und wie in einer Ihrer Funktionen senden wie:

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

Ich weiß, dass Sie kein Zauberer sind und dass das Codieren kein Lego spielt, aber dies ist eine sehr wichtige Funktion für mich. Ich würde versuchen zu helfen.

Während der GrafanaCon erwähnte @DanCech die Idee, öffentliche Wiedergabelisten mit einem GUID-Schlüssel zu erstellen. Ähnlich wie Schnappschüsse heute funktionieren. Das Teilen / Speichern eines solchen Schlüssels kann als sicher wie ein API-Token angesehen werden, ist jedoch auf das Anzeigen von Wiedergabelisten beschränkt. Die Wiedergabeliste kann dem Ersteller / Updater zugeordnet werden, um die Berechtigungen für die Dashboard-Ansicht zu überprüfen.

Die URL könnte ungefähr so ​​aussehen wie https://play.grafana.com/playlists/public/<hash>

Eine Sache, die ich an dieser Lösung mag, ist, dass sie die Funktionalität darauf beschränkt, nur Wiedergabelisten (Dashboard) anzuzeigen, was meiner Meinung nach der größte Anwendungsfall für solche Token ist.

Aber wir müssten den Benutzer trotzdem irgendwie anmelden, da Dashboard-ACL / Anmerkungen usw. eine serverseitige Authentifizierung erfordern.

Ich denke, wir können mehr über diese Art von Lösung nachdenken. Ich wollte hauptsächlich unser Gespräch von GrafanaCon überdenken :)

Danke @bergquist , auf jeden Fall gut, dieses Zeug aufzuschreiben, solange es noch frisch ist!

Die nächste Entwicklung dieses Gedankens bestand darin, das Konzept eines "Bildschirms" hinzuzufügen, um die Dinge weiter zu entkoppeln, so dass der Benutzer einen "Bildschirm" erstellen konnte, der dann eine geheime Hash-URL hatte, mit der er sich verbinden würde. Dies würde dem gleichen Zweck dienen, würde jedoch die Verwaltung der Bildschirme innerhalb von Grafana ermöglichen, so dass der Benutzer steuern kann, welche Wiedergabeliste usw. angezeigt wird.

Das Endziel hier wäre, einen Mechanismus zu unterstützen, mit dem ein Benutzer auf einfache Weise eine SD-Karte oder ein USB-Image erstellen kann, mit dem ein dedizierter Himbeer-Pi gestartet und die gewünschte Wiedergabeliste sicher von Grafana angezeigt werden kann, ohne durch Authentifizierungsrahmen springen zu müssen.

Das Endziel hier wäre, einen Mechanismus zu unterstützen, mit dem ein Benutzer auf einfache Weise eine SD-Karte oder ein USB-Image erstellen kann, mit dem ein dedizierter Himbeer-Pi gestartet und die gewünschte Wiedergabeliste sicher von Grafana angezeigt werden kann, ohne durch Authentifizierungsrahmen springen zu müssen.

@DanCech Dies ist genau der Anwendungsfall, den ich suche.

Die nächste Entwicklung dieses Gedankens bestand darin, das Konzept eines "Bildschirms" hinzuzufügen, um die Dinge weiter zu entkoppeln, so dass der Benutzer einen "Bildschirm" erstellen konnte, der dann eine geheime Hash-URL hatte, mit der er sich verbinden würde.

@ DanCech Das klingt perfekt!

Hallo allerseits,

Dies scheint ein wenig weit von der ursprünglichen Ausgabe von Germanaz0 entfernt zu sein

Sollte es schön sein, wenn eine automatische Anmeldung ein Benutzertoken über die URL weiterleitet, könnte dies eine Teillösung zum Einbetten von Iframes auf Websites sein.

und von adamlwgriffiths erklärt

Wir haben unsere eigene Authentifizierung und Dashboards. Wir möchten die Möglichkeit bieten, einen Benutzer von unserem Dashboard an Grafana weiterzuleiten - ähnlich wie Heroku mit New Relic und anderen Diensten mit Null-Passwörtern zusammenarbeitet. Das Bereitstellen einer URL + Token-Authentifizierungsmethode ist selbstverständlich.

Germanaz0 entwickelt ein js-Skript

Im Moment haben wir dieses Problem mit einem kleinen Hack gelöst und ein Javascript hinzugefügt, das sich automatisch bei grafana anmeldet, aber eine zeitliche Lösung darstellt

Ich verstehe, dass sie ein automatisches Login benötigen, um grafana chart auf ihrer eigenen Seite zu verwenden. Das brauche ich auch ohne Playlist ... Wäre es möglich?

Wenn Sie einen Benutzer nur automatisch anmelden möchten, verwenden Sie am besten http://docs.grafana.org/tutorials/authproxy/.

@DanCech Das Problem ist, dass sich alle Benutzer automatisch anmelden können. Wir möchten eine Möglichkeit, nur Benutzer automatisch anzumelden, die eine bestimmte URL haben.

@gzzo , das vom Design des Proxys abhängt

Ich suche diese Funktion auch in Grafana.
Ich denke, Microsoft Power BI Embed ist die gute Lösung. Siehe Links unten.
https://github.com/Microsoft/PowerBI-JavaScript/wiki/Embedding-Basics
https://microsoft.github.io/PowerBI-JavaScript/demo/v2-demo/index.html

Ich denke, die obige PowerBi-Lösung basiert auf OAuth2.
Die Grafana-Serverseite soll OAuth2 unterstützen und CORS aktivieren.

@ Nayar Ich bin neu in Grafana. Was meinst du mit Aktien Grafana und Aktien Nginx, die du am 14. September 2017 kommentiert hast? Hast du einen Link zu beiden?

Ich denke, ich warte gespannt auf die Veröffentlichung von 5.4.

Verwalten dies mit Erfolg Grafana des mit auth.proxy und Nginx von ngx_http_secure_link_module

Die von mir verwendeten Links haben das Format http://grafana/?user=nayar&md5=2tutcea9nfdsfdsfdsw&expires=1505386800

Sobald der Benutzer darauf klickt, wird das Sitzungscookie gesetzt und der Benutzer kann grafana durchsuchen, als ob er sich normal angemeldet hätte.

Vorteile:

• Link läuft nach einiger Zeit + Sicherheit ab
• Link generiert Hash mit Benutzer-ID, Zeitstempel und Passkey + Sicherheit
• Sie müssen kein Passwort und keine Bequemlichkeit eingeben

Mein Nginx Conf ist so

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

Nehmen Sie Kontakt mit mir auf, wenn Sie Hilfe benötigen

Hallo Nayar,
Ich versuche die Integrationsgrafana mit dem SaaS zu machen.
Nachdem sich der Benutzer in meiner Webanwendung angemeldet und dann auf meiner Seite auf den Link "grafana" geklickt hat, wird er ohne Eingabe von Benutzername und Passwort zum grafana-Dashboard weitergeleitet.

Ihr Kommentar scheint meine Anforderung zu erfüllen. Der Authentifizierungsprozess ist mir jedoch immer noch nicht klar.
Wenn proxy_pass an grafana gesendet wird, wird überprüft, wie der Benutzer von meiner eigenen Anwendung authentifiziert wird.

Meine Webanwendung erfolgt über X-XSRF-TOKEN, um die Benutzerberechtigung zu überprüfen.

Ich bin neu in der Serverkonfiguration. Es wird für Ihre Hilfe geschätzt.

@torkelo / @bergquist Nur ein Heads-up - so haben wir das in Screenly umgangen . Es ist live und funktioniert super! Danke für die harte Arbeit, Leute!

@torkelo / @bergquist Nur ein Heads-up - so haben wir das in Screenly umgangen . Es ist live und funktioniert super! Danke für die harte Arbeit, Leute!

@vpetersson Ich verwende nicht Screenly, aber ich bin gespannt, wie Sie dies implementieren konnten. Ich verstehe das Generieren eines API-Tokens. Hast du noch iframe in der URL? Wie haben Sie das Authentifizierungstoken an die Anforderungsheader angehängt?

@GimpMaster Wir verwenden nur den Auth-Header, daher sind keine Iframes erforderlich. Seit wir den Player / Browser geschrieben haben, konnten wir den Auth-Header in das Laden der Seite einfügen.

Ich habe gerade meinen Kiosk-Modus mit dem Ansatz von Screenly, den @GimpMaster verknüpft hat, zum ModHeader verwendet, bei dem ich den Authorization-Header mit dem Bearer-API-Schlüssel hinzugefügt habe. Aber da Extensions einige Zeit brauchen, um den Schlaf 10s zu laden, machte das Einrichten eines Kiosks auf Himbeer-Pi den Trick. Diese Lösung würde auch für iframes funktionieren, muss dann aber auf jedem Client konfiguriert werden.

@Nayar Ich habe Ihre vorgeschlagene ngnix-Konfiguration erfolgreich angepasst, um _unsecure_ access zu verwenden. Das heißt, es wird nur der Benutzername aus der Abfragezeichenfolge genommen und in den X-WEBAUTH-USER eingefügt. Dies erhält dann die ID einer Grafana-Sitzung und wir sind weg. Vielen Dank!

Ich kann die md5-Methode nicht zum Laufen bringen. Ich bin mir nicht sicher, was genau ich brauche, um einen MD5-Fingerabdruck zu erstellen. Könnten Sie näher darauf eingehen? Gibt es irgendwelche Tricks bei der Herstellung des MD5?

Ist es möglich, Lösungen für die Anmeldung per Token / Cookie / Header / ... in grafana 6 zu implementieren? *?

Ich kann es nicht mit einem einfachen Link-Panel in einem leeren PHP machen

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

Ich habe getestet, meine Nginx-Konfiguration auf diese zu ändern und "? User = myUser" in der URL festzulegen, aber nur eine nicht autorisierte Antwort erhalten

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 Alles rund um den Auth-Proxy wird in der Dokumentation erklärt . Ich habe noch nie eine Lösung gesehen, bei der Sie den Proxy mit "X-WEBAUTH-USER aufrufen. Normalerweise authentifizieren Sie sich in Ihrem Proxy, der wiederum die X-WEBAUTH-USER für grafana ausfüllt und bereitstellt.

@marefr danke für die Antwort.
Ich habe die Dokumentation gelesen und meine API funktioniert, aber ich benötige eine dynamische Benutzerauthentifizierung (nicht die gleiche Berechtigung für alle Benutzer der Seite).

Diese Lösung von @Nayar enthält den X-WEBAUTH-USER im Header, ohne ihn fest zu codieren, aber ich kann ihn nicht zum Laufen bringen

Ich denke, in 6.0 oder 6.1 ist etwas kaputt gegangen.
Ich habe gestern eine voll funktionsfähige Installation mit Auth Proxy in Apache2 auf 6.1 aktualisiert (von 5.3) und erhalte genau die gleichen Bildschirme wie

Bitte beachten Sie, dass Grafana den Proxy-Header zu verstehen scheint: Er meldet den Benutzer zunächst an, aber nachfolgende Anforderungen erhalten eine 401-Antwort.

@Bitblade Wir haben keine ähnlichen Berichte erhalten. Bitte öffnen Sie einen neuen Fehlerbericht, da dieses Problem eine Funktionsanforderung betrifft.

Verwalten dies mit Erfolg Grafana des mit auth.proxy und Nginx von ngx_http_secure_link_module

Die von mir verwendeten Links haben das Format http://grafana/?user=nayar&md5=2tutcea9nfdsfdsfdsw&expires=1505386800

Sobald der Benutzer darauf klickt, wird das Sitzungscookie gesetzt und der Benutzer kann grafana durchsuchen, als ob er sich normal angemeldet hätte.

Vorteile:

• Link läuft nach einiger Zeit + Sicherheit ab
• Link generiert Hash mit Benutzer-ID, Zeitstempel und Passkey + Sicherheit
• Sie müssen kein Passwort und keine Bequemlichkeit eingeben

Mein Nginx Conf ist so

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

Nehmen Sie Kontakt mit mir auf, wenn Sie Hilfe benötigen

Diese Lösung funktioniert bei mir nicht. Weil ich denke, dass jede Anfrage einen gültigen X-WEBAUTH-USER-Header enthalten sollte. Es funktioniert nicht, wenn Sie den Header bei der ersten Anfrage ausfüllen, Cookies erhalten und mit ihnen gehen.

Ich endete mit der nächsten Lösung:

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

Die Lösung verwendet also das Nginx-Modul auth_request. Meine App ist für die Zugriffskontrolle verantwortlich (/ gauth request) und gibt den Benutzernamen im Antwortheader User .

Hallo, in der Zwischenzeit können Sie meine hier beschriebene Lösung verwenden: https://github.com/guysoft/FullPageOS/issues/175

Hier ist meine Problemumgehung mit Grafanas generischer OAuth-Authentifizierung und PHP: https://github.com/nbayramberdiyev/grafana-generic-oauth

Hoffe das wird dir helfen.

Ich wollte nur kommentieren, wie ich das mit http basic auth https://github.com/grafana/grafana/issues/13706#issuecomment -540958284 gelöst habe

Sollte es schön sein, wenn eine automatische Anmeldung ein Benutzertoken über die URL weiterleitet, könnte dies eine Teillösung zum Einbetten von Iframes auf Websites sein.

@rca können Sie ein Beispiel mit Ihrem Code geben? Ich kopiere Ihren Code und embedded.js, aber es hat nicht funktioniert.

Wenn Sie oauth verwenden, können Sie eine eingebettete Grafik ohne doppelte Anmeldung abrufen

1. Richten Sie grafana mit einem einzigen oauth-Anbieter und ohne andere Anmeldemechanismen ein
2. Setzen Sie GF_AUTH_OAUTH_AUTO_LOGIN auf true
3. Hosten Sie grafana in einem Unterpfad und verwenden Sie einen Reverse-Proxy, damit grafana auf demselben Host wie Ihre Haupt-App bereitgestellt wird
4. Verbinden Sie Ihre Haupt-App und grafana mit demselben oauth-Anbieter (für den oauth-Anbieter sind sie dieselbe "App").
5. Gravana einbetten
6. Wenn der Iframe geladen wird, versucht grafana, sich automatisch mit oauth anzumelden (was erfolgreich sein sollte, da es sich in derselben Domain wie Ihre Haupt-App befindet und somit dasselbe Auth-Cookie verwendet).

BEARBEITEN: Möglicherweise müssen Sie in grafana security.cookie_samesite=none festlegen, damit dies in einigen Browsern ordnungsgemäß funktioniert grafana domain. Derzeit lässt Firefox nicht zu, dass ein Samesite-Cookie, das auf lax , auf diese Weise fortbesteht. https://bugzilla.mozilla.org/show_bug.cgi?id=1454027 was bedeutet, dass grafana sein oauth_state verliert none )

@seanlaff Ich habe Ihre Lösung mit AWS Cognito ausprobiert, aber es wird ein Header zurückgegeben, der es nicht erlaubt, sie in einen Iframe zu setzen (X-Frame-Optionen: Verweigern). Gibt es Tipps dazu?

Verwalten dies mit Erfolg Grafana des mit auth.proxy und Nginx von ngx_http_secure_link_module
Die von mir verwendeten Links haben das Format http://grafana/?user=nayar&md5=2tutcea9nfdsfdsfdsw&expires=1505386800
Sobald der Benutzer darauf klickt, wird das Sitzungscookie gesetzt und der Benutzer kann grafana durchsuchen, als ob er sich normal angemeldet hätte.
Vorteile:

• Link läuft nach einiger Zeit + Sicherheit ab
• Link generiert Hash mit Benutzer-ID, Zeitstempel und Passkey + Sicherheit
• Sie müssen kein Passwort und keine Bequemlichkeit eingeben

Mein Nginx Conf ist so

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

Nehmen Sie Kontakt mit mir auf, wenn Sie Hilfe benötigen

Diese Lösung funktioniert bei mir nicht. Weil ich denke, dass jede Anfrage einen gültigen X-WEBAUTH-USER-Header enthalten sollte. Es funktioniert nicht, wenn Sie den Header bei der ersten Anfrage ausfüllen, Cookies erhalten und mit ihnen gehen.

Ich endete mit der nächsten Lösung:

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

Die Lösung verwendet also das Nginx-Modul auth_request. Meine App ist für die Zugriffskontrolle verantwortlich (/ gauth request) und gibt den Benutzernamen im Antwortheader User .

Wie benutzt man es mit iframe?
Ich bin neu bei Grafana und NGINX
Bitte teilen Sie uns jetzt die maximalen Details mit, die Sie ändern möchten

Wie benutzt man es mit iframe?

@pgsekaran Diese Lösung ist nicht für Iframe, sondern für das Abrufen der grafana-Benutzeroberfläche ohne explizite grafana-Anmeldung für Benutzer Ihrer App. Die App ist in diesem Fall ein Proxy, der weiß, wie man sich bei grafana anmeldet.

Hallo,
Danke für die schnelle Antwort. Haben Sie einen Link mit Bezug zum Hinzufügen der Grafana mit einer anderen App mithilfe von iframe.Ich füge Grafana zu meiner App hinzu, aber ich kann die Nutzungsverwaltung nicht festlegen.
GrüßeGuna
Am Dienstag, 23. Juni 2020, 21:54:57 Uhr GMT + 17:30 Uhr schrieb Konstantin Kolotyuk [email protected] :

Wie benutzt man es mit iframe?

@pgsekaran Diese Lösung ist nicht für Iframe, sondern für das Abrufen der grafana-Benutzeroberfläche ohne explizite grafana-Anmeldung für Benutzer Ihrer App. Die App ist in diesem Fall ein Proxy, der weiß, wie man sich bei grafana anmeldet.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an oder melden Sie sich ab.

Ist es immer noch nicht implementiert? Im Ernst, das ist eine gute Funktion.

@pgsekaran Ich habe eine Lösung für Iframe, die nicht sehr sicher ist, da sie ein auf Benutzernamen basierendes Login verwendet und darauf beruht, dass Benutzernamen nicht leicht zu erraten sind. Grundsätzlich ist der Benutzername das Token.
Ich habe hier darüber geschrieben, nicht sehr detailliert, aber eouhg, um Ihnen den Einstieg zu erleichtern
https://blog.yadamiel.com/tutorials/embed-and-authenticate-grafana-in-a-iframe

@pgsekaran Ich habe eine Lösung für Iframe, die nicht sehr sicher ist, da sie ein auf Benutzernamen basierendes Login verwendet und darauf beruht, dass Benutzernamen nicht leicht zu erraten sind. Grundsätzlich ist der Benutzername das Token.
Ich habe hier darüber geschrieben, nicht sehr detailliert, aber eouhg, um Ihnen den Einstieg zu erleichtern
https://blog.yadamiel.com/tutorials/embed-and-authenticate-grafana-in-a-iframe

Hallo,

Ich muss mit NGINX und iframe mit automatischer Anmeldung einrichten

Das genaue Problem wurde unter https://github.com/grafana/grafana/issues/16319#issuecomment -483272921 erläutert: Die Sitzungs-ID wird nicht mit der ersten Antwort zurückgegeben, die die Seite "Skelett" enthält. Nachfolgende Anforderungen enthalten kein Auto-Login-Token und schlagen daher fehl.

Wir verwenden Chrom im Kioskmodus, um Grafana-Dashboards an verschiedenen Stellen anzuzeigen. Da dieselbe Grafana-Instanz auch für Benutzer verfügbar ist, verwenden wir auth.generic_oauth ( auth.basic bis 5.x), um Menschen anzumelden, und auth.proxy um sich an den Maschinen im Kioskmodus anzumelden:

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

Wie andere angemerkt haben, funktioniert dies nicht einfach. Was funktionieren würde, wäre , zuerst die URL http://prometheus.localdomain/grafana/login?autologin=lHOrdypkhxzNYb2lRaIjbNPlOCZw9gWE aufzurufen (die jetzt das Cookie grafana_session ) und dann zum echten Dashboard umzuleiten. Aber ... Kiosk-Modus if und Iframes 🤦‍♂️

Unsere endgültige Arbeitslösung besteht darin, den Abfrageparameter autologin mit einem benutzerdefinierten Cookie zu kombinieren. Ja, Sie können sich nicht über die GUI abmelden, da das benutzerdefinierte Cookie nicht gelöscht wird. Da dieser Mechanismus jedoch nur auf Computern im Kioskmodus verwendet wird, war dies nicht erforderlich.

Hier ist die Nginx-Konfiguration für den Grafana Server:

# 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;
    }
}