Grafana: トークンURLによる自動ログイン

誰もがトークンを見ることができるため、かなり安全ではありません。表示されているデータのスナップショットを作成して埋め込むことができます。

はい。ただし、スナップショットを使用する場合、スナップショットを編集する権限がありません。または、スナップショットを介してダッシュボードを編集する方法はありますか？

これは、SaaSとの相互運用性にとって非常に重要です。
独自の認証とダッシュボードがあります。HerokuがパスワードなしでNewRelicやその他のサービスと相互運用するのと同じように、ダッシュボードからGrafanaにユーザーを渡す機能を提供したいと考えています。

URL +トークン認証方式を提供することは当然のことです。
その後、誰かが行ってそれを公開Webサイトに埋め込んだ場合、その人を自分自身から救うセキュリティはありません。 それは彼らのせいです。
ドキュメント/ UIで十分な警告を提供することは、これには問題ないはずです。

この機能がないと、ユーザーは2番目のログイン画面に遭遇する必要があり、入力するユーザー名/パスワードについて混乱します。

これは私たちにとって大きなブロッカーです。

グラファナにある良い機能のように聞こえます。 今、本当に優先度の高いものが他にもたくさんあるので、PRの手助けをしたいです

いい説明@adamlwgriffiths同じことが私にも起こります。

今、私たちは少しハックしてこの問題を解決し、grafanaに自動ログインするjavascriptを追加しましたが、これは一時的な解決策です

これは+10 !!
これを安全にするには、トークンにユーザー名+パスワード+日付のハッシュが含まれている必要があります。 これは、セキュリティを向上させるために、x時間後にトークンを期限切れにするために使用できます。

時間があれば、これに取り組むことを真剣に検討します

トークンの作成日を保存して期限切れにできる場合は、ハッシュと関連するアカウントも保存するので、特定のデータからハッシュを生成する必要はないと思います。 推測を実行不可能にするのに十分な大きさの検索スペースである必要があります。

@adamlwgriffiths 、これはAPIキーで行われるのと同様に、ビューア、エディタなどのいくつかの基本的なロールもサポートする必要があります。おそらく、URLを介してAPIキーを渡すことができるようにそれを拡張することができますか？

長期的には、新しいメソッドを追加するのではなく、user / org / apiトークンを統合する必要があると思います。
APIトークンがHTMLインターフェースから使用できるように拡張されている場合、これは問題にはなりません。
APIトークンにはすでに役割があり、取り消すことができるため、純粋なAPIではなくWebビューで使用できる必要があります。

IMO APIトークンは、通常のユーザーと同じように機能するはずです。 文書化されていない任意の分離があり、直感に反していることがわかりました。 すべてのログインチェックを有効にしてAPIキーもチェックできるようにするのが最善だと思います。

この機能は実装されていますか？ ユーザーが自分のサイトからgrafanaダッシュボードに自動的にリダイレクトされるようにしようとしていました。

@comcomservicesトークン自体のフォローアップとして、トークン内の情報をユーザーIDとトークンの

私はそのようなことを勧めるのをためらっています。暗号化は難しいと固く信じています。あなたが何をしているのかを完全に理解していないと、それを試みるのは良い考えではありません。

暗号化されたトークンに関するもう1つの問題は、トークンがかなり大きく、情報が多いほどトークンが大きくなることです。
スペースがブルートフォースを実行不可能にするのに十分な大きさである限り、ランダムな文字列を任意の長さに作成できます。

@adamlwgriffiths暗号化

この機能を楽しみにしています！ サイトへのトークンの埋め込みに関する上記の@adamlwgriffithsのコメントに関して、トークンを要求する必要のあるドメインにそのトークンを関連付けることを軽減する方法を信じています。 そうすれば、そのトークンはオリジンが一致する場合にのみ機能します。 この例は、問題を正しく理解していれば、 Sentryのraven-jsです。 パブリックURLを作成し、発信元によって制限します（以下を参照）。 これにより、セキュリティ上の懸念が緩和されますか？

@ Germanaz0は、自動ログインJSを公開していますか？ マスターブランチに対して同様の実装を探していますが、ダッシュボードページにアクセスする前にバックエンドがログイン画面にリダイレクトされているようです。 私はまだプロジェクトの構造に精通していないので、JSコードの正しいセクションに接続していない可能性があります。

@rcaはい、しかし私の解決策は非常に単純ですhttps://gist.github.com/Germanaz0/d41b5f60dd8097405b6b

{user：_USERNAME_、pass：_PASS_、redirect_to：_URL_TO_REDIRECT}のjsonの？t = base64のような入力パラメーターを受け取ります。

そのスクリプトをログインページに含める必要があります。

@ Germanaz0 、共有してくれてありがとう！ コメントを送った後、調べ始めましたが、ご指摘のとおり、ログインページを更新する必要があることがわかりました。 スタンドアロンのスクリプトを作成する代わりに、少し異なるアプローチを取り、ログインコントローラーを更新しました。 私の変更はここにあります： https ：

これはプルリクエストに値しますか？ これをマージ可能な状態にするために必要なmodを作成できれば幸いです。

これに関する更新はありますか？
@rca PRを作成しましたか？

@rcaからのPRの+1

@ Germanaz0 、.jsファイルをどのファイルに含めていますか？

@rcaログインコントローラーmodの使用方法について何か説明はありますか？ 私はgrafanaを初めて使用し、無人のキオスクでこれを機能させようとしています。

ところで、キオスクなどでこれを実現する方法が他に必要な場合は、Grafanaのauthproxyをチェックしてください。 これとapacheで必要なことを達成することができました。

@scottfuhrman正式には何も書かれていませんが、私のユースケースと実装は次のとおりです。

私はキオスクモードを探していませんでしたが、ダッシュボードをiframeとして外部ページに埋め込む方法を探していました。 チャートはかなりきれいに埋め込まれています。例：

ダッシュボードを埋め込む場合は、次のマークアップが必要です。

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

お役に立てれば。

+1

このための人員リソースはありませんが、この取り組みをクラウドファンディングで喜んで提供します。

プレイリストを使おうとするまで、これは解決したと思いました。 authproxyの使用は特定のダッシュボードで機能しますが、複数のダッシュボードでプレイリストを試してみると、同じ問題が発生しました。 表示セキュリティを完全に無効にしない限り、実際のキオスクアプリケーションを実装できない場合にキオスクモードを使用する意味がわかりませんか？

@torkeloこれに取り組むために

これをどのように実装することをお勧めしますか？ 基本的に必要なのは、認証をバイパス/解決するトークンをURL文字列に含めることです。 これに対する最善のアプローチは何ですか？

わからない、そのような機能を安全に実装する方法を研究する必要があります

とった。 あなたが計画を立てたら、私たちは準備ができています:)

方法についてアイデアがあれば教えてください。評価できます。

了解しました。 @ over64を見て、何かを提案します。

缶@torkeloあなたはそれが理にかなっているかどうかを確認するために＃7431で@ over64のPRを見てください。

簡単な回避策はありますか？ @ Germanaz0ソリューションを実装しようとしていますが、機能しません:(

これは必須です。そうでない場合、iframe内にスナップショットを埋め込む際にブロックされます。 埋め込まれたスナップショットURLは、ログインキー/トークンをサポートする必要があります。

こんにちは、みなさん、

このスレッドの最近のコメントは次のとおりです。

• セキュリティ
• iframe内への埋め込み

セキュリティに関しては、上記の私の古いコメントを検討してください： https ：

また、iframeへの埋め込みについて： https ：

このブランチ（かなり古いですが）には、上記のコメントで説明されているように、iframeのサイズを適切に設定し、トークンを介して認証するDiscourseから借用したコードが含まれています。

@torkelo上記の要素を組み込んだプルリクエストを検討する場合は

@rca上記のコードのembed.jsは何ですか？

@zoellこれは、Discourseプロジェクトから借用したいくつかのjsであり、フレームに埋め込まれたコンテンツに基づいてページ上のiframeのサイズを

@rcaああありがとう。 あなたが言及したブランチでそのファイルを見つけることができませんでした。 それはどこかで利用できますか？

@zoell 、私はそのリポジトリをフォークし、そこにあるはずのファイルを含めます。

@rcaありがとう

@rca申し訳ありませんが、前に説明したブランチでファイルが見つかりません。

@TinaRen @zoellこれにボールを落としました、お詫びします。

しかし、今見てみると、ファイルはずっとそこにあったようです！ 😬

私はこれについて追加の作業を次の場所で行います。

https://github.com/rca/grafana

そして、ファイルは次の場所にあります。

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

このファイルが作成されておらず、 public_gen/ディレクトリに配置されていない場合は、お知らせください。

ありがとう！

少なくともgrafanaをlocalhostアクセスに制限することは可能ですか？ （パネル共有を同じサーバーサイトに絞り込むため）

私は誰かが上流に行くことができる適切な実装でこれを突き刺すのを見たいと思います。 私たちが提案した解決策（＃7431）は、決して受け入れられませんでした:(

私たちの側の誰かがこれに時間を費やしてくれることを嬉しく思いますが、上流で何が受け入れられるかについてのガイダンスが必要です。

Grafanaのauth.proxyとNginxのngx_http_secure_link_moduleを使用して、これを成功させることができました

私が使用するリンクはhttp://grafana/?user=nayar&md5=2tutcea9nfdsfdsfdsw&expires=1505386800形式です

ユーザーがそれをクリックすると、セッションCookieが設定され、ユーザーは通常のログインのようにgrafanaを参照できます。

利点：

• リンクはしばらくすると期限切れになります+セキュリティ
• リンクは、ユーザーID、タイムスタンプ、パスキー+セキュリティを使用してハッシュを生成します
• パスワードを入力する必要はありません+便利

私のnginxconfはこんな感じです

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

これについてサポートが必要な場合は、お気軽にご連絡ください

非常に興味深い、@ Nayar。 ただし、このソリューションに関する私の懸念は、かなり大量のカスタマイズが必要になることです。 Grafanaにネイティブに組み込まれているものが好きです。

在庫のグラファナを使用しました。 モジュールを有効にしてストックnginxを再コンパイルする必要がありました。それだけです。

Nayar、実装したソリューションがすべてのバージョンのgrafana.iで機能するかどうかを教えてください。Grafanaは初めてです。 私の組織では、彼らはすでにインストールしています

これを解決する方法のいくつかのアイデア（および問題）を引き出します。

最速の解決策：

1）APIキーに特別なタイプ（フラグ）を追加して、URLで使用してサインインできるようにします。

Proos：APIキーは組織管理者のみが追加できます。

2）ユーザーがAPIキーとURLキー（APIキーのバリエーション）を作成できるようにします。

これに関する問題は、ユーザーがapiキーまたはurlキーを作成できる場合、Grafanaから（oauthシステムから）アクセスが削除された後にこれを使用できるようになるoauthセットアップになります。 apiキーまたはurlキーはoauthログインを必要としないため。 これは、最終的にユーザーAPIキーを実行するときに、ユーザーAPIキーにとって大きな問題になります。 緩和策の1つは、組織管理者またはgrafanaサーバー管理者のみにユーザーAPIキーの作成を許可することです。

@DanCechの考え？ AllowUrlLoginフラグ付きのAPIキーの使用を続行しますか？

APIキーインフラストラクチャを使用するのが正しい方法だとは思いません。後で機能を追加するのが難しくなるためです（たとえば、URLを特定のダッシュボードのセットに制限し、管理者以外のユーザーがログインリンクを作成できるようにするなど）。 ）そしてユーザーを混乱させる可能性があります。 確かに同じ概念を使用し、同様のバックエンド構造を持つこともできますが、それを分離すると、より多くのオプションが得られ、ユーザーにとってより明確になると思います。

oauthログインの質問に関しては、ここでスコープを理解する必要があると思います。 パスワードも有効にしている場合、oauthユーザーにも同じ問題が存在します。これは、ローカルパスワードを設定でき、oauthアカウントが無効になった後でもその方法でログインできるためです。 この問題の唯一の実際の解決策は、そのリンクをユーザーアカウントに保存し、ログインを受け入れる前に常にoauthリダイレクトループを介してoauthユーザーを送信することです。

また、この機能の適切な名前を考え出す必要があると思います。 「ログインURL」は広すぎる可能性があり、たとえば特定のダッシュボードに限定されたライブリンクを共有する方法として、将来使用する余地が実際にはありません。

@matttttはあなたの考えを取得したいと思います

後で機能を追加するのが難しくなるため（たとえば、URLを特定のダッシュボードのセットに制限し、管理者以外のユーザーがログインリンクを作成できるようにする）

このログイン機能を権限にリンクしたり、特定のダッシュボードに制限したりすることを躊躇しています（組織の役割またはユーザーにリンクする以外）。 これが共有機能に変わり、満たされていないセキュリティの期待値が設定されるためです（組織が使用するデータソースからすべてのデータをクエリできるため）。

この問題の唯一の実際の解決策は、そのリンクをユーザーアカウントに保存し、ログインを受け入れる前に常にoauthリダイレクトループを介してoauthユーザーを送信することです。

ログインURL /ユーザーAPIトークンの「取り消し」をどのように解決するかわからない。 アクセスが削除された後、oauthでログインしようとしない場合、Grafanaはそれを知りません。

@hemsushこのブログ投稿によると、Grafana 2.0以降のように機能するはずです： https ：//grafana.com/blog/2015/12/07/grafana-authproxy-have-it-your-way/

このログイン機能を権限にリンクしたり、特定のダッシュボードに制限したりすることを躊躇しています（組織の役割またはユーザーにリンクする以外）。 これが共有機能に変わり、満たされていないセキュリティの期待値が設定されるためです（組織が使用するデータソースからすべてのデータをクエリできるため）。

それは解決する必要のある問題なので、このシステムは将来のためにそのユースケースを念頭に置いて設計することをお勧めします。

ログインURL /ユーザーAPIトークンの「取り消し」をどのように解決するかわからない。 アクセスが削除された後、oauthでログインしようとしない場合、Grafanaはそれを知りません。

私の考えでは、これらのリンクの1つを使用したときにクライアントが取得するビューは、特定のユーザーとして魔法のようにログインするのではなく、制限されたViewerアカウントを取得する「匿名」ユーザーに似ている必要があり、この機能は完全に切り離されます。個々のユーザーアカウントから。 これにより、個々のユーザーアカウントのアクセス許可の問題が回避され、リンクを使用して変更を加えることができなかったためリスクレベルが低下し、組織管理者によるすべてのアクティブなアクセスリンクの集中管理が可能になります。

ソリューションの提案

1）APIキーページに追加/削除できる新しい概念「ビューアURLトークン」を導入します（これについては後で新しいページを作成できます）。 新しいテーブルurl_tokenに保存すると、APIキーと非常によく似たセキュリティの観点から機能します。 つまり、APIキーと同じ方法で生成および検証されます。 ただし、は「＆url-auth-token =」を使用して、URLでの使用を介してログインするために使用できます。"。
2）トークンをPNGレンダリングAPIでのみ機能するように制限するオプション（URLトークンを持つユーザーはクエリを発行できず、既存のダッシュボード/パネルのみを表示できるため、より安全になります）
3）将来的には、トークンをユーザーグループとダッシュボードのアクセス許可にリンクする方法を見つける必要がありますが、それがどのように機能するかはまだわかりません。 これに使用できるダミーユーザーを作成して、「URLトークン」ユーザーに特定のダッシュボードとデータソースへのアクセス許可を与えるとよいと思います。 パーミッションチェックでURLトークンの明示的なチェック/結合が必要になるのは嫌だろう。

4）URLトークンを持っている人は誰でも、すべての組織のデータソースにアクセスできる（そして技術的に任意のクエリを発行できる）ことを明確にします（APIのレンダリングに制限オプションが使用されている場合を除く）。

考え@ bergquist @ DanCech

トークンをPNGレンダリングAPIでのみ機能するように制限するオプション（URLトークンを持つユーザーはクエリを発行できず、既存のダッシュボード/パネルのみを表示できるため、より安全になります）

PNGレンダリングは良い解決策ではないと思います。 ちらつき、本物のグラファナほど見栄えがしません。

トークンをユーザーに接続するというアイデアが好きです。 そのトークン/ログインをユーザーグループとダッシュボードフォルダーのアクセス許可に接続する最も簡単な方法。 しかし、トークン（tv login / view mode / tv mode）を使用してログインすると、ユーザーはViewer役割になります。

URLトークンを持っている人は誰でも、すべての組織のデータソースにアクセスできる（そして技術的には任意のクエリを発行できる）ことを明確にします（APIのレンダリングに制限オプションが使用されている場合を除く）。

新しいトークンを作成するときに情報と警告を追加すると役立つ場合があります。

トークンを「通常の」ユーザーに結び付けることの問題は、ユーザーが変更または削除されると、あらゆる種類の問題が発生することです。 ユーザーと同じようにURLトークンをグループのメンバーにできる場合は、特定のダッシュボードなどにアクセスできる個々のURLを設定する際に非常に柔軟性があります。

権限チェックが非常に複雑になるかどうかはわかりません。ビューアが通常のユーザーであるかURLトークンであるかに応じて、グループメンバーに異なるテーブルを使用しますが、システム全体のアクセスチェックでは使用しないでください。変更する必要があります。

実際にデータソースへのアクセスを強制する限り、ここでは通常のユーザーとの違いはありません。 この問題の最終的な解決策は、データソースプラグインをバックエンドに移動し、ダッシュボード、パネル、時間範囲、テンプレートの変数値を指定し、ユーザーを検証した後に実際のクエリをバックエンドで構築することで、フロントエンドにデータソースリクエストをディスパッチさせることですアクセス権があり、テンプレートの変数値が正当であること。

トークンを「通常の」ユーザーに結び付けることの問題は、ユーザーが変更または削除されると、あらゆる種類の問題が発生することです。

トークンを知っている人なら誰でも（アカウントがシャットダウンされていても）ダッシュボードを表示できるという問題は、どちらのソリューションにも当てはまります。 アクセスの取り消しは、ユーザーまたはトークンを削除することで実行できます。

権限チェックが非常に複雑になるかどうかはわかりません。ビューアが通常のユーザーであるかURLトークンであるかに応じて、グループメンバーに異なるテーブルを使用しますが、システム全体のアクセスチェックでは使用しないでください。変更する必要があります。

認証に関係なく、チェックは同じように見えるはずです。 ですから、それは大きな問題にはなりません。 トークン/ユーザーをグループやダッシュボードなどに追加するためのUIは煩雑で、ごく少数のユーザーにしか役立ちません。

実際にデータソースへのアクセスを強制する限り、ここでは通常のユーザーとの違いはありません。 この問題の最終的な解決策は、データソースプラグインをバックエンドに移動し、ダッシュボード、パネル、時間範囲、テンプレートの変数値を指定し、ユーザーを検証した後に実際のクエリをバックエンドで構築することで、フロントエンドにデータソースリクエストをディスパッチさせることですアクセス権があり、テンプレートの変数値が正当であること。

ここから、ダッシュボードを安全な方法で共有するための優れたエクスペリエンスを提供するための作業を開始する必要があると思います。 これがなければ、すべての解決策は悪いトレードオフのように感じます。 データソースへのアクセスが解決されるまで、最小限に抑える必要があると思います。

username+passwd+ldap authモードの埋め込みダッシュボードでもこの問題に遭遇しました...
これに関する更新はありますか？

ビューアトークンオプションに非常に興味があります。 なんらかの形でお手伝いできれば、喜んでお手伝いさせていただきます。

こんにちはみんな！
ダッシュボードの認証済みリンクを作成しようとしています。Javaにバックエンドがあり、JSFにフロントエンドがあります。クリックすると、ユーザーをダッシュ​​ボードに直接リダイレクトする画面にユーザーを配置したいと思います。概念をよく理解していません、誰か私がこれを行う方法の例がありますか？

こんにちは、

ただのアイデア、助けようとしています。 このような基本認証を使用して、新しいユーザーAPIを追加してみませんか
? curl https://admin:admin<strong i="7">@localhost</strong>:3000/api/user/cookie
次のようなJSON結果を取得します
{"user_name":"admin","cookie_name":"grafana_,session":"a0b1c2d3e4","remember":"da27ef425e9e0d"}

httpsで保護され、この情報を使用してCookieを偽造し、ユーザーが美しいグラフを表示できるようにすることができます。

私はあなたのコードを注意深く見て、（非常に敬意を表して）それはそれほど難しくないと思います。
代わりに：
user.Rands+user.Password, setting.CookieRememberName, user.Login, days, setting.AppSubUrl+"/"

SetSuperSecureCookie関数に、次のようなSetSuperSecureCookieに触発された新しい関数を作成できます。

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

答えは手の込んだもので、次のような関数の1つで送信できます。

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

あなたが魔術師ではなく、コーディングがレゴをプレイしていないことは知っていますが、これは私にとって非常に重要な機能です。 私は助けようとします。

GrafanaConの期間中、@ DanCechは、GUIDキーを使用して公開プレイリストを作成するというアイデアについて言及しました。 今日のスナップショットの仕組みに似ています。 このようなキーの共有/保存は、APIトークンと同じくらい安全であると見なすことができますが、プレイリストの表示に限定されます。 プレイリストを作成者/アップデーターに関連付けて、ダッシュボードの表示権限を検証できます。

URLはhttps://play.grafana.com/playlists/public/<hash>

このソリューションで私が気に入っていることの1つは、このようなトークンの最大のユースケースであると思うプレイリスト（ダッシュボード）の表示のみに機能を制限することです。

ただし、ダッシュボードのACL /注釈などにはサーバー側の認証が必要になるため、何らかの方法でユーザーにログインする必要があります。

この種の解決策についてもっと考えることができると思います。 私は主にGrafanaConからの会話をブレインダンプしたかった:)

@bergquistに感謝します。まだ新鮮なうちに、このようなものを

その考えの次の進化は、物事をさらに分離するための「画面」の概念を追加することでした。これにより、ユーザーは、接続する秘密のハッシュURLを持つ「画面」を作成できます。 これは同じ目的を果たしますが、Grafana内から画面を管理できるため、ユーザーはどのプレイリストを表示するかなどを制御できます。

ここでの最終目標は、ユーザーがsdカードまたはusbイメージを簡単に作成できるメカニズムをサポートすることです。このメカニズムを使用して、専用のラズベリーpiを起動し、認証フープを飛び越えずにGrafanaから目的のプレイリストを安全に表示できます。

ここでの最終目標は、ユーザーがsdカードまたはusbイメージを簡単に作成できるメカニズムをサポートすることです。このメカニズムを使用して、専用のラズベリーpiを起動し、認証フープを飛び越えずにGrafanaから目的のプレイリストを安全に表示できます。

@DanCechこれはまさに私が探しているユースケースです。

その考えの次の進化は、物事をさらに分離するための「画面」の概念を追加することでした。これにより、ユーザーは、接続する秘密のハッシュURLを持つ「画面」を作成できます。

@DanCechこれは完璧ですね！

皆さんこんにちは、

これは、Germanaz0によって開かれた元の問題から少し離れているようです

URLを介してユーザートークンを渡す自動ログインがあると便利です。これは、サイトにiframeを埋め込むための部分的な解決策になる可能性があります。

adamlwgriffithsによって説明されました

独自の認証とダッシュボードがあります。HerokuがパスワードなしでNewRelicやその他のサービスと相互運用するのと同じように、ダッシュボードからGrafanaにユーザーを渡す機能を提供したいと考えています。 URL +トークン認証方式を提供することは当然のことです。

Germanaz0はjsスクリプトを開発します

今、私たちは少しハックしてこの問題を解決し、grafanaに自動ログインするjavascriptを追加しましたが、これは一時的な解決策です

自分のサイトでグラファナチャートを使用するには、自動ログインが必要であることを理解しています。 これは私がプレイリストを使わずに必要なものです...それは可能でしょうか？

ユーザーを自動的にログインさせるのが最善の策である場合は、 http：//docs.grafana.org/tutorials/authproxy/を使用することです。

@DanCechの問題は、すべてのユーザーが自動的にログインできるようになることです。特定のURLを持つユーザーのみに自動的にログインする方法が必要です。

プロキシの設計に依存する@gzzo

Grafanaでもこの機能を探しています。
Microsoft PowerBIの埋め込みが優れたソリューションだと思います。 以下のリンクを参照してください。
https://github.com/Microsoft/PowerBI-JavaScript/wiki/Embedding-Basics
https://microsoft.github.io/PowerBI-JavaScript/demo/v2-demo/index.html

上記のPowerBiソリューションはOAuth2に基づいていると思います。
Grafanaサーバー側はOAuth2をサポートし、CORSを有効にする必要があります。

@NayarGrafanaは初めてです。 2017年9月14日にコメントしたGrafana株とNginx株とはどういう意味ですか？ 両方にリンクはありますか？

5.4のリリースを熱心に待っていると思います。

Grafanaのauth.proxyとNginxのngx_http_secure_link_moduleを使用して、これを成功させることができました

私が使用するリンクはhttp://grafana/?user=nayar&md5=2tutcea9nfdsfdsfdsw&expires=1505386800形式です

ユーザーがそれをクリックすると、セッションCookieが設定され、ユーザーは通常のログインのようにgrafanaを参照できます。

利点：

• リンクはしばらくすると期限切れになります+セキュリティ
• リンクは、ユーザーID、タイムスタンプ、パスキー+セキュリティを使用してハッシュを生成します
• パスワードを入力する必要はありません+便利

私のnginxconfはこんな感じです

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

これについてサポートが必要な場合は、お気軽にご連絡ください

こんにちはナヤル、
私はSaaSとの統合グラファナを実行しようとしています。
要件は、ユーザーがWebアプリケーションにログインし、ページの[grafana]リンクをクリックした後、ユーザー名とパスワードを入力せずにgrafanaダッシュボードにリダイレクトされることです。

あなたのコメントは私の要件を満たしているようです。 しかし、私はまだ認証プロセスについてはっきりしていません。
grafanaにproxy_passする場合、ユーザーが自分のアプリケーションによって認証されていることを確認する方法。

私のWebアプリケーションは、X-XSRF-TOKENを介してユーザー権限を確認しています。

私はサーバー構成に不慣れです。あなたの助けに感謝します。

@torkelo / @bergquistただのこれは、Screenlyでこれを回避する方法です。 ライブでうまく機能します！ 頑張ってくれてありがとう！

@torkelo / @bergquistただのこれは、Screenlyでこれを回避する方法です。 ライブでうまく機能します！ 頑張ってくれてありがとう！

@vpetersson私は

@GimpMaster authヘッダーを使用するだけなので、iframeは必要ありません。 プレーヤー/ブラウザを作成したので、ページの読み込みに認証ヘッダーを挿入することができました。

@GimpMasterがリンクしたScreenlyのアプローチを使用して、キオスクモードをModHeaderを使用しました。 しかし、Extensionsは、ラズベリーパイにキオスクをセットアップしてから10秒間のスリープをロードするのに時間がかかるため、うまく

@Nayar_unsecure_アクセスを使用するように提案されたngnix構成を正常に適合させました。 つまり、クエリ文字列からユーザー名を取得して、X-WEBAUTH-USERに配置するだけです。 次に、これはgrafanaセッションIDを取得し、私たちは離れています。 ありがとう！

md5メソッドを機能させることができません。 md5フィンガープリントを作成するために正確に何が必要かわかりません。 詳しく教えていただけますか？ md5を作成する上で何かトリックはありますか？

grafana 6. *でtoken / cookie / header / ...でログインするためのソリューションを実装することは可能ですか？

空白のPHPの単純なリンクパネルではそれを行うことができません

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

nginxの設定をこれに変更し、URLに「？user = myUser」を設定してテストしましたが、不正な応答しか得られません

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認証プロキシドキュメントで説明されてい"X-WEBAUTH-USERてプロキシを呼び出すソリューションはこれまで見たことがありません。通常はプロキシで認証し、プロキシでX-WEBAUTH-USERを入力してgrafanaに提供します。

@marefr回答ありがとう
ドキュメントを読み、APIが機能しますが、動的ユーザー認証が必要です（ページのすべてのユーザーに同じ権限ではありません）

@Nayarのこのソリューションは、ハードコードせずにヘッダーにX-WEBAUTH-USERを含めますが、機能させることはできません

6.0または6.1で何かが壊れたと思います。
昨日（5.3から）Apache2の認証プロキシを使用して完全に機能するインストールを6.1に更新し、 @ mr0blesとまったく同じ画面が表示され

Grafanaはプロキシヘッダーを理解しているように見えることに注意してください。最初はユーザーをログインさせますが、その後のリクエストは401応答を受け取ります。

@Bitbladeあなたと同様の報告は他にありません。 この問題は機能のリクエストに関するものなので、新しいバグレポートを開いてください。

Grafanaのauth.proxyとNginxのngx_http_secure_link_moduleを使用して、これを成功させることができました

私が使用するリンクはhttp://grafana/?user=nayar&md5=2tutcea9nfdsfdsfdsw&expires=1505386800形式です

ユーザーがそれをクリックすると、セッションCookieが設定され、ユーザーは通常のログインのようにgrafanaを参照できます。

利点：

• リンクはしばらくすると期限切れになります+セキュリティ
• リンクは、ユーザーID、タイムスタンプ、パスキー+セキュリティを使用してハッシュを生成します
• パスワードを入力する必要はありません+便利

私のnginxconfはこんな感じです

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

これについてサポートが必要な場合は、お気軽にご連絡ください

この解決策は私にはうまくいきません。 各リクエストには有効なX-WEBAUTH-USERヘッダーが含まれている必要があると思うからです。 最初のリクエストでヘッダーに入力し、Cookieを取得して、それを使用すると機能しません。

私は次の解決策で終わりました：

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

そのため、ソリューションはauth_requestnginxモジュールを使用します。 私のアプリはアクセス制御（/ gauthリクエスト）を担当し、 User応答ヘッダーでユーザー名を返します。

こんにちは、それまでの間、ここで説明されている私のソリューションを使用できます： https ：

Grafanaの汎用OAuth認証とPHPを使用した回避策は次のとおりです： https ：

これがお役に立てば幸いです。

http basic auth https://github.com/grafana/grafana/issues/13706#issuecomment-540958284を使用してこれをどのように解決したかについてコメントしたかっただけです。

URLを介してユーザートークンを渡す自動ログインがあると便利です。これは、サイトにiframeを埋め込むための部分的な解決策になる可能性があります。

@rcaコードの例を挙げていただけますか？コードとembed.jsをコピーしましたが、機能しませんでした。

oauthを使用している場合は、ダブルログインせずに埋め込まれたグラファナを実行する方法があります

1. 単一のoauthプロバイダーを使用し、他のログインメカニズムを使用せずにgrafanaをセットアップします
2. GF_AUTH_OAUTH_AUTO_LOGINをtrueに設定します
3. サブパスでgrafanaをホストし、リバースプロキシを使用して、grafanaがメインアプリと同じホストで提供されるようにします。
4. メインアプリとグラファナを同じoauthプロバイダーにフックします（oauthプロバイダーにとっては同じ「アプリ」になります）
5. グラファナを埋め込む
6. iframeが読み込まれると、grafanaはoauthを使用して自動的にログインしようとします（メインアプリと同じドメインにあるため、同じ認証Cookieを共有するため成功するはずです）

編集：これが一部のブラウザで正しく機能するために、grafanaでsecurity.cookie_samesite=noneを設定する必要がある場合があります（これは、iframeで、oauthプロバイダー（別のドメイン）へのリダイレクトが発生してから、 grafanaドメイン。現在、firefoxはlaxに設定された同じサイトのCookieをこの方法で保持することを許可しません。https：//bugzilla.mozilla.org/show_bug.cgi？id = 1454027これは、grafanaがoauth_state失うことを意味します。 cookie_samesiteがnone設定されていない場合、 oauth_state cookie）

@seanlaff AWS Cognitoでソリューションを試しましたが、iframe（X-Frame-Options：deny）に配置できないヘッダーが返されます。これに関するヒントはありますか？

Grafanaのauth.proxyとNginxのngx_http_secure_link_moduleを使用して、これを成功させることができました
私が使用するリンクはhttp://grafana/?user=nayar&md5=2tutcea9nfdsfdsfdsw&expires=1505386800形式です
ユーザーがそれをクリックすると、セッションCookieが設定され、ユーザーは通常のログインのようにgrafanaを参照できます。
利点：

• リンクはしばらくすると期限切れになります+セキュリティ
• リンクは、ユーザーID、タイムスタンプ、パスキー+セキュリティを使用してハッシュを生成します
• パスワードを入力する必要はありません+便利

私のnginxconfはこんな感じです

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

これについてサポートが必要な場合は、お気軽にご連絡ください

この解決策は私にはうまくいきません。 各リクエストには有効なX-WEBAUTH-USERヘッダーが含まれている必要があると思うからです。 最初のリクエストでヘッダーに入力し、Cookieを取得して、それを使用すると機能しません。

私は次の解決策で終わりました：

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

そのため、ソリューションはauth_requestnginxモジュールを使用します。 私のアプリはアクセス制御（/ gauthリクエスト）を担当し、 User応答ヘッダーでユーザー名を返します。

iframeでの使用方法は？
GrafanaとNGINXは初めてです
変更するには、今すぐ最大の詳細を共有してください

iframeでの使用方法は？

@pgsekaranこのソリューションはiframe用ではありませんが、アプリのユーザーに明示的なgrafanaログインなしでgrafanaUIを取得するためのものです。 この場合のアプリは、grafanaにログインする方法を知っているプロキシです。

こんにちは、
迅速な返信ありがとうございます。 iframeを使用して他のアプリでGrafanaを追加するためのリンクはありますか？アプリにGrafanaを追加しましたが、使用管理を設定できません。
よろしくグナ
火曜日に、2020年6月23日、午前9時54分57秒PM GMT + 5：30、コンスタンチンKolotyuk [email protected]書きました：

iframeでの使用方法は？

@pgsekaranこのソリューションはiframe用ではありませんが、アプリのユーザーに明示的なgrafanaログインなしでgrafanaUIを取得するためのものです。 この場合のアプリは、grafanaにログインする方法を知っているプロキシです。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示するか、登録を解除してください。

それでも実装されていませんか？ 真剣にこれは機能を持っているのは良いことです。

@pgsekaran私はiframeのソリューションを持っていますが、これはユーザー名ベースのログインを使用し、ユーザー名を簡単に推測できないことに依存しているため、あまり安全ではありません。 基本的に、ユーザー名はトークンです。
iveはここにそれについて書いていますが、詳細ではありませんが、始めるために
https://blog.yadamiel.com/tutorials/embed-and-authenticate-grafana-in-a-iframe

@pgsekaran私はiframeのソリューションを持っていますが、これはユーザー名ベースのログインを使用し、ユーザー名を簡単に推測できないことに依存しているため、あまり安全ではありません。 基本的に、ユーザー名はトークンです。
iveはここにそれについて書いていますが、詳細ではありませんが、始めるために
https://blog.yadamiel.com/tutorials/embed-and-authenticate-grafana-in-a-iframe

こんにちは、

自動ログインでNGINXとiframeをセットアップする必要があります

正確な問題については、 https ： ます。セッションIDは、ページ「スケルトン」を含む最初の応答では返されません。 後続のリクエストには自動ログイントークンが含まれていないため、失敗します。

キオスクモードでクロムを使用して、さまざまな場所にGrafanaダッシュボードを表示します。 同じGrafanaインスタンスもユーザーが利用できるため、 auth.generic_oauth （5.xまではauth.basic ）を使用して人間にログインし、 auth.proxyを使用してキオスクモードのマシンにログインします。

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

他の人が指摘しているように、これは単に機能するだけではありません。 何に働くだろうと、URLの最初の呼び出しにあるhttp://prometheus.localdomain/grafana/login?autologin=lHOrdypkhxzNYb2lRaIjbNPlOCZw9gWE （今設定するgrafana_sessionクッキー）、その後、実際のダッシュボードにリダイレクトに。 しかし...キオスクモード🤷とiframe🤦‍♂️

最終的な解決策は、 autologinクエリパラメータをカスタムCookieと組み合わせることです。 はい、カスタムCookieは削除されないため、GUIからログアウトすることはできませんが、このメカニズムはキオスクモードのマシンでのみ使用されるため、これは必要ありませんでした。

したがって、Grafanaサーバーのnginx構成は次のとおりです。

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