Grafana: تسجيل الدخول التلقائي عن طريق عنوان url المميز

سيكون غير آمن إلى حد كبير حيث يمكن لأي شخص رؤية الرمز المميز ، يمكنك إنشاء لقطة للبيانات المرئية وتضمين ذلك ، سيكون أكثر أمانًا

نعم ، ولكن باستخدام اللقطات ليس لديك إذن بتعديلها ، أو هل هناك أي طريقة لتحرير لوحة المعلومات من خلال اللقطات؟

هذا مهم جدًا للتشغيل البيني مع SaaS.
لدينا المصادقة ولوحات المعلومات الخاصة بنا ، ونريد توفير القدرة على تمرير المستخدم من لوحة القيادة الخاصة بنا إلى Grafana - في سياق مماثل لكيفية تعامل Heroku مع New Relic والخدمات الأخرى بدون كلمات مرور.

يعد توفير طريقة مصادقة url + الرمز المميز أمرًا مكافئًا للدورة التدريبية.
إذا قام شخص ما بعد ذلك بتضمين ذلك على موقع ويب عام ، فلن ينقذ أي قدر من الأمان هذا الشخص من نفسه. هذا خطأهم.
يجب أن يكون تقديم تحذيرات كافية في الوثائق / واجهة المستخدم جيدًا لهذا الغرض.

بدون هذه الوظيفة ، يجب أن يواجه المستخدمون شاشة تسجيل دخول ثانية ، حيث سيتم الخلط بينهم بشأن اسم المستخدم / كلمة المرور للدخول.

هذا مانع كبير بالنسبة لنا.

تبدو ميزة جيدة في Grafana. أرغب في المساعدة في العلاقات العامة حيث يوجد الكثير من الأشياء الأخرى التي تحظى بأولوية عالية في الوقت الحالي

تفسير جميل adamlwgriffiths يحدث نفس الشيء لي.

في الوقت الحالي ، قمنا بحل هذه المشكلة بقليل من الاختراق ، بإضافة جافا سكريبت لتسجيل الدخول التلقائي إلى غرافانا ، ولكنه حل مؤقت

+10 لهذا !!
لجعل هذا آمنًا ، يجب أن يكون هناك تجزئة لاسم المستخدم + كلمة المرور + التاريخ ، الموجودة في الرمز المميز. يمكن استخدام هذا لإنهاء صلاحية الرمز المميز بعد عدد x من الساعات لتحسين الأمان.

إذا حصلت على بعض الوقت ، فسأفكر بجدية في العمل على هذا الأمر

إذا كنت تقوم بتخزين تاريخ إنشاء الرمز المميز حتى تتمكن من انتهاء صلاحيته ، فأنت تقوم أيضًا بتخزين التجزئة والحساب المرتبط ، لذلك لا أعتقد أنه يجب إنشاء التجزئة من أي بيانات معينة. تحتاج فقط إلى مساحة بحث كبيرة بما يكفي لجعل التخمين غير مجدٍ.

adamlwgriffiths ، يجب أن يدعم هذا بعض الأدوار الأساسية أيضًا .. مثل المشاهد والمحرر .. إلخ ، على غرار ما يتم عمله مع مفاتيح واجهة برمجة التطبيقات .. ربما يمكننا فقط توسيع ذلك حتى نتمكن من تمرير مفتاح api في عبر عنوان url؟

أعتقد - على المدى الطويل - أن رمز المستخدم / org / api بحاجة إلى التوحيد ، بدلاً من إضافة طريقة جديدة.
إذا تم توسيع الرموز المميزة لواجهة برمجة التطبيقات للسماح بالاستخدام من واجهة HTML ، فلن تكون هذه مشكلة.
الرموز المميزة لواجهة برمجة التطبيقات لها أدوار بالفعل ، ويمكن إبطالها ، لذلك يجب أن تكون قابلة للاستخدام في عرض الويب بدلاً من واجهة برمجة التطبيقات البحتة.

يجب أن تعمل الرموز المميزة IMO API مثل المستخدمين العاديين. هناك فصل تعسفي غير موثق وأجده غير بديهي. سيكون تمكين جميع عمليات التحقق من تسجيل الدخول للتحقق أيضًا من مفاتيح واجهة برمجة التطبيقات هو الأفضل على ما أعتقد.

هل تم تنفيذ هذه الميزة؟ كنت أحاول إعادة توجيه المستخدم تلقائيًا إلى لوحة تحكم grafana من موقعي ..

comcomservices كمتابعة للرمز المميز نفسه ، يمكنك بالتأكيد تشفير المعلومات داخل الرمز المميز بمعرف المستخدم ، ووقت انتهاء صلاحية الرمز المميز. بهذه الطريقة يمكنك فقط قراءة الرمز المميز نفسه والحصول على المعلومات دون الحاجة إلى تخزين الرموز المميزة في db وتشغيل "المسح والمسح" على الرموز القديمة.

أنا متردد في التوصية بمثل هذا الشيء ، وأعتقد اعتقادًا راسخًا أن التشفير صعب ، وبدون الفهم الكامل لما تفعله ، فليس من الجيد محاولة القيام بذلك.

المشكلة الأخرى مع الرموز المميزة المشفرة ، هي أنها كبيرة نوعًا ما ، وكلما زادت المعلومات كلما أصبحت أكبر.
حيث يمكن عمل سلسلة عشوائية بأي طول ، طالما أن المساحة كبيرة بما يكفي لجعل القوة الغاشمة غير ممكنة.

adamlwgriffiths بقدر ما يذهب التشفير ، لدي خلفية رسمية فيه وأستمتع به ولكن في هذه الحالة أنا أوافق تمامًا على أن الرمز المميز سيكون أفضل .. فقط أحاول اكتشاف هذه الأشياء ، كنت أفعل c ++ و asm لفترة طويلة جدًا ... سأحصل عليها رغم ذلك وهذا هو الأول في قائمتي

أنا أتطلع إلى هذه الميزة! فيما يتعلق بتعليق adamlwgriffiths أعلاه فيما يتعلق بتضمين الرمز المميز على موقع ما ، أعتقد أن طريقة التخفيف من ذلك هي ربط هذا الرمز بالمجال الذي يجب أن يطلبه ؛ بهذه الطريقة لا يعمل هذا الرمز المميز إلا عندما يتطابق الأصل. مثال على ذلك - مرة أخرى ، إذا فهمت المشكلة بشكل صحيح - هو Sentry's raven-js ؛ سيُنشئ عنوان URL عامًا ثم يقيده حسب الأصل (انظر أدناه). هل سيؤدي ذلك إلى تخفيف القلق الأمني؟

@ Germanaz0 هل JS تسجيل الدخول التلقائي الخاص بك متاح للجمهور؟ أتطلع إلى تنفيذ شيء مشابه على الفرع الرئيسي ويبدو أن الواجهة الخلفية تعيد التوجيه إلى شاشة تسجيل الدخول قبل الوصول إلى صفحة لوحة المعلومات. لست على دراية بهيكل المشروع حتى الآن ، لذلك قد لا أقوم بتوصيل القسم الصحيح في كود JS.

rca نعم ، لكن الحل الخاص بي بسيط للغاية https://gist.github.com/Germanaz0/d41b5f60dd8097405b6b

تتلقى معلمة إدخال مثل؟ t = base64 من json مع {user: _USERNAME_ ، تمرير: _PASS_ ، redirect_to: _URL_TO_REDIRECT}

يجب عليك تضمين هذا البرنامج النصي في صفحة تسجيل الدخول.

@ Germanaz0 ، شكرا للمشاركة! بعد إرسال تعليقي ، بدأت في إلقاء نظرة ، وكما أشرت ، وجدت أنني بحاجة إلى تحديث صفحة تسجيل الدخول. لقد اتبعت نهجًا مختلفًا قليلاً وقمت بتحديث وحدة التحكم في تسجيل الدخول بدلاً من إنشاء نص برمجي مستقل ؛ التغيير الذي أجريته هنا: https://github.com/zymbit/grafana/tree/auto-login-by-cookie-redirect

هل هذا يستحق طلب سحب؟ سأكون سعيدًا لإجراء التعديلات اللازمة لإدخال هذا في حالة قابلة للدمج.

أي تحديث على هذا؟
rca هل قمت بإنشاء

+1 للعلاقات العامة من rca

@ Germanaz0 ، ما الملف الذي تريد تضمين ملف .js فيه؟

rca هل لديك أي تعليمات حول كيفية استخدام

BTW إذا كان أي شخص آخر يحتاج إلى وسيلة لتحقيق ذلك لكشك، وما إلى ذلك، تشيك من Grafana في authproxy . تمكنت من تحقيق ما أحتاجه مع هذا و apache.

scottfuhrman لا

لم أكن أبحث عن وضع kiosk ، بل كنت أبحث عن طريقة لتضمين لوحة تحكم كإطار 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 مع لوحة تحكم معينة ، ولكن بمجرد أن جربت قائمة تشغيل بها لوحات معلومات متعددة واجهت نفس المشكلة. لا أفهم الهدف من وجود وضع kiosk عندما يكون من المستحيل تنفيذ تطبيق kiosk حقيقي ما لم نعطل أمان العرض تمامًا؟

torkelo لقد جندت @ over64 للعمل على هذا بالنسبة لي.

كيف توصي هذا ليتم تنفيذه؟ ما أحتاجه بشكل أساسي هو أن يكون لدي رمز مميز في سلسلة عنوان URL يتجاوز / يحل المصادقة. ما هو أفضل نهج لهذا؟

لست متأكدًا ، سيتعين علينا البحث في كيفية تنفيذ هذه الميزة بشكل آمن

فهمتك. نحن جاهزون بمجرد وضع خطة :)

إذا كانت لديك فكرة عن كيفية القيام بذلك ، فيرجى إبلاغي بذلك ويمكنني تقييمها

حسنا. @ over64 سيلقي نظرة ويقترح شيئاً.

torkelo هل يمكنك إلقاء نظرة على العلاقات العامة لـ @ over64 في # 7431 لمعرفة ما إذا كان ذلك منطقيًا.

أي حل سهل؟ أحاول تنفيذ حل @ Germanaz0 لكنه لا يعمل بالنسبة لي :(

هذا أمر لا بد منه ، وإلا فسيتم حظر أحد تضمين لقطة داخل إطار iframe. يجب أن يدعم عنوان url الخاص باللقطة المضمنة مفتاح / رمز تسجيل الدخول.

مرحبا جميعا،

تتعلق التعليقات الأحدث في هذا الموضوع بما يلي:

• الأمان
• التضمين داخل إطار iframe

فيما يتعلق بالأمان ، يرجى النظر في تعليقي القديم أعلاه: https://github.com/grafana/grafana/issues/3752#issuecomment -200874453

وفيما يتعلق بالتضمين في iframe: https://github.com/grafana/grafana/issues/3752#issuecomment -267062843

يحتوي هذا الفرع (على الرغم من أنه قديم جدًا) على رمز مستعار من Discourse يحجم بشكل جيد إطار iframe بالإضافة إلى المصادقة عبر الرمز المميز كما هو موضح في التعليق أعلاه.

torkelo يرجى إعلامي إذا كنت

rca ما هو هذا embed.js في التعليمات البرمجية أعلاه؟

zoell ، تم استعارة بعض js من مشروع Discourse

@ rca شكرا. لم أتمكن من العثور على هذا الملف في الفرع الذي ذكرته. هل هذا متاح في مكان آخر؟

zoell ، وأدرج هذا الملف كما ينبغي أن يكون هناك.

rca شكرا سيكون ذلك رائعا.

rca أنا آسف ، ما زلت لا أستطيع العثور على الملف في الفرع الذي ذكرته من قبل.

TinaRenzoell لقد أسقطت الكرة على هذا ، معذرة .

ومع ذلك ، بعد إلقاء نظرة الآن ، يبدو أن الملف كان موجودًا طوال الوقت! 😬

سأقوم بأي عمل إضافي في هذا الشأن في:

https://github.com/rca/grafana

والملف موجود في:

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

إذا لم يتم إنشاء هذا الملف وانتهى به الأمر في الدليل public_gen/ ، فيرجى إبلاغي بذلك.

شكر!

هل من الممكن على الأقل تقييد grafana لوصول المضيف المحلي؟ (لتضييق مشاركة اللوحة في نفس موقع الخادم)

أود أن أرى شخصًا ما يتعامل مع هذا بالتطبيق المناسب الذي يمكن أن يذهب إلى المنبع. الحل الذي اقترحناه (# 7431) لم يُقبل:

يسعدني أن يكون هناك شخص من جانبنا يقضي بعض الوقت في هذا الأمر ، لكننا نحتاج إلى إرشادات حول ما سيكون مقبولًا في المنبع.

تمكنت من القيام بذلك بنجاح باستخدام Grafana auth.proxy و Nginx's ngx_http_secure_link_module

الروابط التي أستخدمها هي بالتنسيق http://grafana/?user=nayar&md5=2tutcea9nfdsfdsfdsw&expires=1505386800

بمجرد أن ينقر المستخدم عليه ، يتم تعيين ملف تعريف ارتباط الجلسة ويمكن للمستخدم تصفح grafana كما لو أنه قام بتسجيل الدخول بشكل طبيعي.

مزايا:

• تنتهي صلاحية الرابط بعد مرور بعض الوقت + الأمان
• يقوم الارتباط بإنشاء تجزئة مع معرف المستخدم والطابع الزمني ومفتاح المرور + الأمان
• لا حاجة لكتابة كلمة المرور + الراحة

إن nginx الخاص بي هو مثل هذا

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. ومع ذلك ، فإن اهتمامي بهذا الحل هو أنه يتطلب قدرًا كبيرًا من التخصيصات. أفضل شيئًا مدمجًا في غرافانا أصلاً.

لقد استخدمت جرافانا الأسهم. كان علينا فقط إعادة تجميع nginx للأسهم مع تمكين الوحدة النمطية وهذا كل شيء.

Nayar ، هل يمكنك السماح لي بمعرفة ما إذا كان الحل الذي نفذته يمكن أن يعمل مع جميع إصدارات grafana. أنا جديد في Grafana. في مؤسستي ، تم تثبيتها بالفعل

طرح بعض الأفكار (والمشكلات) حول كيفية حل هذه المشكلة.

أسرع حل:

1) أضف نوعًا خاصًا (علامة) على مفتاح API بحيث يمكن استخدامه في عنوان url لتسجيل دخولك.

Proos: لا يمكن إضافة مفاتيح API إلا بواسطة مسؤولي المؤسسة.

2) اجعل من الممكن للمستخدمين إنشاء مفاتيح api ومفاتيح url (البديل لمفتاح api).

ستكون المشكلات في هذا الأمر هي إعدادات oauth حيث إذا كان بإمكان المستخدم إنشاء مفتاح api أو مفتاح url ، فسيكون قادرًا على استخدام هذا بعد إزالة الوصول من Grafana (من نظام oauth). نظرًا لأن مفتاح api أو مفتاح url لن يتطلب تسجيل دخول oauth. ستكون هذه مشكلة كبيرة لمفاتيح واجهة برمجة التطبيقات للمستخدم عندما نقوم بها في النهاية. يمكن أن يكون أحد حلول التخفيف هو السماح فقط لمسؤولي المؤسسة أو مسؤولي خادم grafana بإنشاء مفاتيح واجهة برمجة تطبيقات للمستخدم.

أفكار @ DanCech ؟ هل تريد المضي قدمًا في استخدام مفتاح API مع علامة AllowUrlLogin؟

لا أعتقد أن استخدام البنية الأساسية لمفتاح واجهة برمجة التطبيقات هو الطريقة الصحيحة للذهاب ، لأنه يجعل من الصعب إضافة المزيد من الوظائف لاحقًا (على سبيل المثال ، قصر عنوان URL على مجموعة معينة من لوحات المعلومات ، مما يسمح لغير المسؤولين بإنشاء روابط تسجيل الدخول ) ومن المحتمل أن تكون مربكة للمستخدمين. يمكننا بالتأكيد استخدام نفس المفاهيم ولدينا بنية خلفية مماثلة ، لكنها تمنحنا المزيد من الخيارات إذا قمنا بفصلها ، وأعتقد أنها ستكون أكثر وضوحًا للمستخدمين.

فيما يتعلق بسؤال تسجيل الدخول إلى oauth ، أعتقد أنه يتعين علينا معرفة النطاق الذي يجب أن يكون هنا. توجد نفس المشكلة لمستخدمي oauth إذا كان لديك أيضًا تمكين كلمات المرور ، حيث يمكنهم تعيين كلمة مرور محلية وسيكونون قادرين على تسجيل الدخول بهذه الطريقة بعد تعطيل حساب oauth. الحل الحقيقي الوحيد لهذه المشكلة هو تخزين هذا الرابط في حساب المستخدم وإرسال مستخدم oauth دائمًا من خلال حلقة إعادة توجيه oauth قبل قبول تسجيل الدخول.

أعتقد أيضًا أننا بحاجة إلى التوصل إلى اسم معقول لهذه الوظيفة. قد يكون "عنوان URL لتسجيل الدخول" واسعًا جدًا ولا يترك حقًا مجالًا للاستخدام في المستقبل كطريقة على سبيل المثال لمشاركة رابط مباشر يقتصر على لوحة تحكم معينة.

mattttt أحب الحصول على أفكارك

نظرًا لأنه يجعل من الصعب إضافة المزيد من الوظائف لاحقًا (على سبيل المثال ، قصر عنوان URL على مجموعة معينة من لوحات المعلومات ، مما يسمح لغير المسؤولين بإنشاء روابط تسجيل الدخول)

أنا متردد في ربط ميزة تسجيل الدخول هذه بالأذونات أو تقييدها بلوحات معلومات محددة (بخلاف ربطها بدور مؤسسة أو مستخدم). لأنها ستحول هذا إلى ميزة مشاركة وتعيين توقعات الأمان التي لم يتم الوفاء بها (حيث يمكنك الاستعلام عن جميع البيانات من مصدر البيانات الذي تستخدمه مؤسسة).

الحل الحقيقي الوحيد لهذه المشكلة هو تخزين هذا الرابط في حساب المستخدم وإرسال مستخدم oauth دائمًا من خلال حلقة إعادة توجيه oauth قبل قبول تسجيل الدخول.

لست متأكدًا من كيفية حل ذلك "إبطال" الرمز المميز لواجهة مستخدم url / user api. إذا لم يحاولوا أبدًا تسجيل الدخول باستخدام oauth بعد إزالة وصولهم ، فلن يعرف Grafana أبدًا.

hemsush وفقًا https://grafana.com/blog/2015/12/07/grafana-authproxy-have-it-your-way/

أنا متردد في ربط ميزة تسجيل الدخول هذه بالأذونات أو تقييدها بلوحات معلومات محددة (بخلاف ربطها بدور مؤسسة أو مستخدم). لأنها ستحول هذا إلى ميزة مشاركة وتعيين توقعات الأمان التي لم يتم الوفاء بها (حيث يمكنك الاستعلام عن جميع البيانات من مصدر البيانات الذي تستخدمه مؤسسة).

هذه مشكلة تحتاج إلى حل ، لذا فإن اقتراحي هو أن يتم تصميم هذا النظام مع وضع حالة الاستخدام هذه في الاعتبار للمستقبل.

لست متأكدًا من كيفية حل ذلك "إبطال" الرمز المميز لواجهة مستخدم url / user api. إذا لم يحاولوا أبدًا تسجيل الدخول باستخدام oauth بعد إزالة وصولهم ، فلن يعرف Grafana أبدًا.

فكرتي هي أن العرض الذي يحصل عليه العميل عند استخدام أحد هذه الروابط يجب أن يكون مشابهًا للمستخدم "المجهول" ، حيث لا يتم تسجيل دخوله بطريقة سحرية كمستخدم معين ، بل يحصل على حساب عارض محدود ، مما يؤدي إلى فصل هذه الميزة تمامًا من حسابات المستخدمين الفردية. سيؤدي ذلك إلى تجنب مشكلة أذونات حساب المستخدم الفردي ، وتقليل مستوى المخاطرة نظرًا لأنه لا يمكن استخدام الرابط لإجراء أي تغييرات ، والسماح بالإدارة المركزية لجميع روابط الوصول النشطة بواسطة مسؤولي المؤسسة.

اقتراح الحل

1) قدم مفهومًا جديدًا "رمز عنوان URL للعارض" ، والذي يمكنك إضافته / إزالته من صفحة مفاتيح واجهة برمجة التطبيقات (يمكننا إنشاء صفحة جديدة لهذا لاحقًا). قم بالتخزين في جدول جديد url_token وستعمل من منظور أمني مشابه جدًا لمفاتيح api. هذا يعني أنه سيتم إنشاؤها والتحقق من صحتها بنفس طريقة مفاتيح api. ومع ذلك ، يمكن استخدام عنوان URL لتسجيل الدخول عبر الاستخدام في عنوان url مع "& url-auth-token =".
2) خيار تقييد الرمز المميز للعمل فقط مع واجهة برمجة تطبيقات تقديم PNG (سيكون أكثر أمانًا لأن المستخدمين الذين لديهم رمز URL المميز لن يتمكنوا من إصدار أي استعلام فقط لعرض لوحات المعلومات / اللوحات الحالية)
3) في المستقبل ، سيتعين علينا إيجاد طريقة لربط الرمز المميز بمجموعات المستخدمين وأذونات لوحة القيادة ، ولست متأكدًا من كيفية عمل ذلك حتى الآن. أعتقد أنه قد يكون من الجيد إنشاء مستخدم وهمي لهذا يمكن استخدامه لمنح مستخدمي "URL Token" أذونات إلى لوحات معلومات ومصادر بيانات محددة. أكره أن يكون لديك عمليات فحص / انضمام صريحة لرموز url المميزة في عمليات التحقق من الأذونات.

4) أوضح أن أي شخص لديه رمز مميز لعنوان URL سيتمكن من الوصول إلى جميع مصادر بيانات المؤسسات (ويمكنه من الناحية الفنية إصدار أي استعلام) (ما لم يتم استخدام خيار تقييد تقديم واجهة برمجة التطبيقات).

تضمين التغريدة

خيار تقييد الرمز المميز للعمل فقط مع واجهة برمجة تطبيقات تقديم PNG (سيكون أكثر أمانًا لأن المستخدمين الذين لديهم رمز URL المميز لن يتمكنوا من إصدار أي استعلام فقط لعرض لوحات المعلومات / اللوحات الحالية)

لا أعتقد أن عرض PNG هو حل جيد. سوف تومض ولن تبدو جميلة مثل الجرافانا الحقيقي.

تعجبني فكرة توصيل الرمز المميز بالمستخدم. أسهل طريقة لتوصيل هذا الرمز المميز / تسجيل الدخول إلى مجموعات المستخدمين وأذونات مجلد لوحة المعلومات. لكنني أعتقد أن تسجيل الدخول باستخدام الرمز المميز (وضع تسجيل الدخول إلى التلفزيون / وضع العرض / وضع التلفزيون) يجب أن يجبر المستخدم على أن يكون في دور Viewer .

وضح أن أي شخص لديه رمز مميز لعنوان URL سيكون لديه حق الوصول إلى جميع مصادر بيانات المؤسسات (ويمكنه من الناحية الفنية إصدار أي استعلام) (ما لم يتم استخدام خيار تقييد واجهة برمجة التطبيقات).

قد تساعد إضافة المعلومات والتحذيرات عند إنشاء رموز جديدة.

تكمن مشكلة ربط رمز مميز بمستخدم "عادي" في أنه يتسبب في جميع أنواع المشاكل عندما يتم تعديل المستخدم أو حذفه. إذا كانت الرموز المميزة لعناوين URL قادرة على أن تكون أعضاء في مجموعة بنفس الطريقة التي يتواجد بها المستخدمون ، فسيكون هناك قدر كبير من المرونة في إعداد عناوين url الفردية مع الوصول إلى لوحات معلومات معينة وما إلى ذلك.

لست متأكدًا من أنه سيضيف الكثير من التعقيد إلى عمليات التحقق من الأذونات ، فستستخدم جدولًا مختلفًا لأعضاء المجموعة اعتمادًا على ما إذا كان العارض مستخدمًا عاديًا أو رمزًا مميزًا لعنوان url ولكن لا ينبغي التحقق من الوصول في جميع أنحاء النظام الحاجة للتغيير.

بقدر ما يتم فرض الوصول إلى مصادر البيانات فعليًا ، لا يوجد فرق هنا أكثر من المستخدمين العاديين. يتمثل الحل النهائي لهذه المشكلة في نقل المكونات الإضافية لمصدر البيانات إلى الواجهة الخلفية والحصول على طلبات مصدر بيانات الإرسال الأمامي من خلال تحديد قيم var للوحة القيادة واللوحة والنطاق الزمني والقالب ، وإنشاء الاستعلامات الفعلية على الواجهة الخلفية بعد التحقق من صحة ذلك المستخدم له حق الوصول وأن قيم var الخاصة بالنموذج شرعية.

تكمن مشكلة ربط رمز مميز بمستخدم "عادي" في أنه يتسبب في جميع أنواع المشاكل عندما يتم تعديل المستخدم أو حذفه

إن المشكلة المتمثلة في أن أي شخص يعرف رمزًا مميزًا (حتى إذا تم إغلاق الحساب) يمكنه عرض لوحات المعلومات صحيحة لكلا الحلين. يمكن إبطال الوصول عن طريق حذف المستخدم أو الرمز المميز.

لست متأكدًا من أنه سيضيف الكثير من التعقيد إلى عمليات التحقق من الأذونات ، فستستخدم جدولًا مختلفًا لأعضاء المجموعة اعتمادًا على ما إذا كان العارض مستخدمًا عاديًا أو رمزًا مميزًا لعنوان url ولكن لا ينبغي التحقق من الوصول في جميع أنحاء النظام الحاجة للتغيير.

يجب أن تبدو الفحوصات كما هي بغض النظر عن المصادقة. لذلك لن تكون هذه مشكلة كبيرة. قد تكون واجهة المستخدم لإضافة الرموز المميزة / المستخدمين إلى المجموعات ولوحات المعلومات وما إلى ذلك فوضوية وستساعد فقط عددًا صغيرًا جدًا من المستخدمين.

بقدر ما يتم فرض الوصول إلى مصادر البيانات فعليًا ، لا يوجد فرق هنا أكثر من المستخدمين العاديين. يتمثل الحل النهائي لهذه المشكلة في نقل المكونات الإضافية لمصدر البيانات إلى الواجهة الخلفية والحصول على طلبات مصدر بيانات الإرسال الأمامي من خلال تحديد قيم var للوحة القيادة واللوحة والنطاق الزمني والقالب ، وإنشاء الاستعلامات الفعلية على الواجهة الخلفية بعد التحقق من صحة ذلك المستخدم له حق الوصول وأن قيم var الخاصة بالنموذج شرعية.

أعتقد أن هذا هو المكان الذي يجب أن نبدأ فيه العمل لتوفير تجربة جيدة لمشاركة لوحات المعلومات بطريقة آمنة. بدون هذا كل الحلول تبدو وكأنها صفقات سيئة. أعتقد أنه يجب أن يظل عند الحد الأدنى حتى يتم حل الوصول إلى مصدر البيانات.

لقد واجهت أيضًا هذه المشكلة مع لوحة التحكم المضمنة في وضع username+passwd+ldap auth ...
أي تحديث حول هذا؟

أنا مهتم جدًا بخيار رمز المشاهد. إذا كان بإمكاني المساعدة بأي شكل من الأشكال ، فسيسعدني تقديم المساعدة.

مرحبا يا شباب!
أحاول إنشاء رابط مصادق عليه للوحة التحكم ، ولدي واجهة خلفية في جافا وواجهة أمامية في JSF ، أريد أن أضع مستخدمًا على الشاشة ، عند النقر عليه ، سيعيد توجيه المستخدم مباشرة إلى dashboar الخاصة به ، أنا لا أفهم المفهوم جيدًا ، شخص ما هل لديك مثال كيف يمكنني القيام بذلك؟

مرحبا،

مجرد فكرة ، تحاول المساعدة. لماذا لا تضيف واجهة برمجة تطبيقات مستخدم جديدة ، باستخدام المصادقة الأساسية مثل هذا
? 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 ، ويمكنني استخدام هذه المعلومات لتزوير ملفات تعريف الارتباط وتفويض المستخدمين برؤية مخططاتهم الجميلة.

إنني أنظر باهتمام إلى التعليمات البرمجية الخاصة بك وأعتقد ( باحترام شديد ) أنها لن تكون صعبة للغاية.
بدلاً من ذلك ، أرسل:
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)
}

يمكن أن تكون الإجابة مفصلة وترسل مثل إحدى وظائفك مثل:

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

أعلم أنك لست ساحرًا وأن البرمجة لا تلعب لعبة Lego ولكن هذه وظيفة مهمة جدًا بالنسبة لي. سأحاول المساعدة.

خلال GrafanaCon ، ذكر DanCech فكرة إنشاء قوائم تشغيل عامة باستخدام مفتاح GUID. على غرار كيفية عمل اللقطات اليوم. يمكن اعتبار مشاركة / تخزين هذا المفتاح آمنًا مثل رمز API المميز ، ولكنه يقتصر على عرض قوائم التشغيل. يمكن ربط قائمة التشغيل بالمنشئ / المحدث للتحقق من أذونات عرض لوحة المعلومات.

قد يبدو عنوان URL مثل https://play.grafana.com/playlists/public/<hash>

أحد الأشياء التي أحبه في هذا الحل هو أنه يقيد الوظيفة فقط لعرض قوائم التشغيل (لوحة القيادة) والتي أعتقد أنها أكبر حالة استخدام لرموز مثل هذه.

لكننا ما زلنا بحاجة إلى تسجيل دخول المستخدم بطريقة ما لأن لوحة التحكم في التحكم بالوصول / التعليقات التوضيحية وما إلى ذلك ستتطلب مصادقة من جانب الخادم.

أعتقد أنه يمكننا التفكير أكثر في هذا النوع من الحلول. كنت أرغب بشكل أساسي في تفريغ محادثتنا من GrafanaCon :)

شكرًا bergquist ، من الجيد بالتأكيد

كان التطور التالي لهذا الفكر هو إضافة مفهوم "الشاشة" لفصل الأشياء بشكل أكبر ، بحيث يمكن للمستخدم إنشاء "شاشة" تحتوي بعد ذلك على عنوان url مجزأ يمكن الاتصال به. سيؤدي هذا إلى نفس الغرض ولكنه سيسمح بإدارة الشاشات من داخل Grafana ، بحيث يمكن للمستخدم التحكم في قائمة التشغيل التي تم عرضها ، وما إلى ذلك.

سيكون الهدف النهائي هنا هو دعم آلية للمستخدم لإنشاء بطاقة sd أو صورة USB بسهولة يمكن استخدامها لتمهيد raspberry pi وعرض قائمة التشغيل المطلوبة بأمان من Grafana دون الحاجة إلى القفز من خلال حلقات المصادقة.

سيكون الهدف النهائي هنا هو دعم آلية للمستخدم لإنشاء بطاقة sd أو صورة USB بسهولة يمكن استخدامها لتمهيد raspberry pi وعرض قائمة التشغيل المطلوبة بأمان من Grafana دون الحاجة إلى القفز من خلال حلقات المصادقة.

DanCech هذا هو بالضبط حالة الاستخدام التي أبحث عنها.

كان التطور التالي لهذا الفكر هو إضافة مفهوم "الشاشة" لفصل الأشياء بشكل أكبر ، بحيث يمكن للمستخدم إنشاء "شاشة" تحتوي بعد ذلك على عنوان url مجزأ يمكن الاتصال به.

@ DanCech هذا يبدو مثاليا!

مرحبا بالجميع ،

يبدو أن هذا بعيد قليلاً عن الإصدار الأصلي الذي فتحه Germanaz0

من الجيد أن يكون لديك تسجيل دخول تلقائي يمرر رمزًا مميزًا للمستخدم من خلال عنوان url ، فقد يكون هذا حلاً جزئيًا لتضمين إطارات iframe على المواقع.

وشرحها adamlwgriffiths

لدينا المصادقة ولوحات المعلومات الخاصة بنا ، ونريد توفير القدرة على تمرير المستخدم من لوحة القيادة الخاصة بنا إلى Grafana - في سياق مماثل لكيفية تعامل Heroku مع New Relic والخدمات الأخرى بدون كلمات مرور. يعد توفير طريقة مصادقة url + الرمز المميز أمرًا مكافئًا للدورة التدريبية.

Germanaz0 تطوير نص js

في الوقت الحالي ، قمنا بحل هذه المشكلة بقليل من الاختراق ، بإضافة جافا سكريبت لتسجيل الدخول التلقائي إلى غرافانا ، ولكنه حل مؤقت

أدرك أنهم بحاجة إلى تسجيل دخول تلقائي لاستخدام مخطط grafana في موقعهم الخاص. هذا ما أحتاجه أيضًا بدون استخدام قائمة التشغيل ... هل سيكون ذلك ممكنًا؟

إذا كنت تريد فقط تسجيل مستخدم تلقائيًا ، فإن أفضل رهان لك هو استخدام http://docs.grafana.org/tutorials/authproxy/

DanCech ، المشكلة هي أنها ستسمح لجميع المستخدمين بتسجيل الدخول تلقائيًا. نريد طريقة لتسجيل الدخول تلقائيًا فقط للمستخدمين الذين لديهم عنوان URL محدد.

gzzo الذي يعتمد على تصميم الوكيل

أنا أبحث عن هذه الميزة في Grafana أيضًا.
أعتقد أن تضمين Microsoft Power BI هو الحل الجيد. انظر الروابط أدناه.
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.

Nayar أنا جديد في جرافانا. ماذا تقصد الأسهم Grafana و Stock Nginx التي علقت عليها في 14 سبتمبر 2017؟ هل لديك أي ارتباط على حد سواء؟

في انتظار بفارغ الصبر الإصدار 5.4 على ما أعتقد.

تمكنت من القيام بذلك بنجاح باستخدام Grafana auth.proxy و Nginx's ngx_http_secure_link_module

الروابط التي أستخدمها هي بالتنسيق http://grafana/?user=nayar&md5=2tutcea9nfdsfdsfdsw&expires=1505386800

بمجرد أن ينقر المستخدم عليه ، يتم تعيين ملف تعريف ارتباط الجلسة ويمكن للمستخدم تصفح grafana كما لو أنه قام بتسجيل الدخول بشكل طبيعي.

مزايا:

• تنتهي صلاحية الرابط بعد مرور بعض الوقت + الأمان
• يقوم الارتباط بإنشاء تجزئة مع معرف المستخدم والطابع الزمني ومفتاح المرور + الأمان
• لا حاجة لكتابة كلمة المرور + الراحة

إن nginx الخاص بي هو مثل هذا

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

لا تتردد في الاتصال بي إذا كنت بحاجة إلى مساعدة في هذا

مرحبا نايار ،
أحاول أن أفعل grafana التكامل مع SaaS.
المطلب بعد تسجيل دخول المستخدم في تطبيق الويب الخاص بي ثم النقر فوق رابط "grafana" في صفحتي ، سيتم إعادة التوجيه إلى لوحة معلومات grafana بدون إدخال اسم المستخدم وكلمة المرور.

يبدو أن تعليقك يلبي متطلباتي. لكنني ما زلت غير واضح بشأن عملية المصادقة.
عندما proxy_pass إلى grafana ، كيفية التحقق من مصادقة تطبيقي الخاص على المستخدم.

تطبيق الويب الخاص بي عبر X-XSRF-TOKEN للتحقق من سلطة المستخدم.

أنا جديد في تهيئة الخادم ، إنه موضع تقدير لمساعدتكم.

torkelo / bergquist مجرد هذه هي الطريقة التي عملنا بها حول هذا في Screenly . إنه مباشر ويعمل بشكل رائع! شكرا على المجهود الشاق ياشباب!

torkelo / bergquist مجرد هذه هي الطريقة التي عملنا بها حول هذا في Screenly . إنه مباشر ويعمل بشكل رائع! شكرا على المجهود الشاق ياشباب!

vpetersson أنا لا أستخدم Screenly لكنني أشعر بالفضول كيف تمكنت من تنفيذ ذلك. أفهم إنشاء رمز مميز لواجهة برمجة التطبيقات. هل ما زلت iframe في عنوان URL؟ كيف قمت بإلحاق رمز المصادقة في رؤوس الطلب؟

GimpMaster نحن نستخدم فقط رأس المصادقة ، لذلك لا داعي

لقد جعلت للتو وضع Kiosk الخاص بي يعمل باستخدام النهج من Screenly الذي ربط GimpMaster . لقد استخدمت Chrome Extension ModHeader حيث أضفت رأس التخويل باستخدام Bearer API Key. ولكن نظرًا لأن الإضافات تحتاج إلى بعض الوقت لتحميل النوم 10s من إعداد كشك على raspberry pi ، فقد صنعت الحيلة. سيعمل هذا الحل أيضًا مع إطارات iframe ولكن يجب تكوينه على كل عميل بعد ذلك.

Nayar لقد نجحت في تكييف تكوين ngnix المقترح الخاص بك لاستخدام وصول _ unsecure_. أي أنه يأخذ اسم المستخدم من سلسلة الاستعلام ويضعه في X-WEBAUTH-USER. هذا ثم يحصل على معرف جلسة grafana ونحن بعيدون. شكر!

أنا غير قادر على تشغيل طريقة md5. لست واضحًا بشأن ما الذي أحتاجه بالضبط لعمل بصمة md5. هل يمكن أن تتطور؟ هل هناك أي حيل لصنع md5؟

هل من الممكن تنفيذ أي حلول لتسجيل الدخول عن طريق token / cookie / header / ... في grafana 6. *؟

أنا غير قادر على القيام بذلك باستخدام لوحة ارتباط بسيطة في 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 الخاص بي إلى هذا وقمت بتعيين "؟ user = myUser" في عنوان url ، ولكن لم أحصل إلا على رد غير مصرح به

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.
لقد قمت بتحديث تثبيت يعمل بشكل كامل باستخدام وكيل المصادقة في Apache2 إلى 6.1 أمس (من 5.3) وأحصل على نفس الشاشات تمامًا مثل

يرجى ملاحظة أن Grafana يبدو أنه يفهم عنوان الوكيل: فهو يقوم بتسجيل دخول المستخدم في البداية ، لكن الطلبات اللاحقة تحصل على استجابة 401.

Bitblade لم نتلق أي تقارير أخرى مماثلة

تمكنت من القيام بذلك بنجاح باستخدام Grafana auth.proxy و Nginx's ngx_http_secure_link_module

الروابط التي أستخدمها هي بالتنسيق http://grafana/?user=nayar&md5=2tutcea9nfdsfdsfdsw&expires=1505386800

بمجرد أن ينقر المستخدم عليه ، يتم تعيين ملف تعريف ارتباط الجلسة ويمكن للمستخدم تصفح grafana كما لو أنه قام بتسجيل الدخول بشكل طبيعي.

مزايا:

• تنتهي صلاحية الرابط بعد مرور بعض الوقت + الأمان
• يقوم الارتباط بإنشاء تجزئة مع معرف المستخدم والطابع الزمني ومفتاح المرور + الأمان
• لا حاجة لكتابة كلمة المرور + الراحة

إن nginx الخاص بي هو مثل هذا

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 صالح. لا يعمل إذا قمت بملء العنوان عند الطلب الأول ، والحصول على ملفات تعريف الارتباط والذهاب معها.

لقد انتهيت بالحل التالي:

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_request nginx. تطبيقي مسؤول عن التحكم في الوصول (/ طلب gauth) ويعيد اسم المستخدم في رأس استجابة User .

مرحبًا ، في هذه الأثناء ، يمكنك استخدام الحل الخاص بي الموضح هنا: https://github.com/guysoft/FullPageOS/issues/175

إليك الحل البديل باستخدام مصادقة OAuth العامة من Grafana و PHP: https://github.com/nbayramberdiyev/grafana-generic-oauth

ارجوا ان يساعدك هذا.

أردت فقط التعليق على كيفية حل هذا باستخدام http basic auth https://github.com/grafana/grafana/issues/13706#issuecomment -540958284

من الجيد أن يكون لديك تسجيل دخول تلقائي يمرر رمزًا مميزًا للمستخدم من خلال عنوان url ، فقد يكون هذا حلاً جزئيًا لتضمين إطارات iframe على المواقع.

rca هل يمكنك إعطاء مثال

إذا كنت تستخدم oauth ، فهناك طريقة لسحب grafana المضمنة دون تسجيل دخول مزدوج

1. قم بإعداد grafana بموفر oauth واحد ولا توجد آليات تسجيل دخول أخرى
2. اضبط GF_AUTH_OAUTH_AUTO_LOGIN على true
3. قم باستضافة grafana في مسار فرعي واستخدم وكيلًا عكسيًا بحيث يتم تقديم grafana في نفس مضيف تطبيقك الرئيسي
4. ربط تطبيقك الرئيسي و grafana بموفر oauth نفسه (لموفر oauth سيكونان "التطبيق" نفسه)
5. تضمين grafana
6. عند تحميل iframe ، سيحاول grafana تسجيل الدخول تلقائيًا باستخدام oauth (والذي يجب أن ينجح نظرًا لأنه في نفس المجال مثل تطبيقك الرئيسي ، وبالتالي مشاركة ملف تعريف الارتباط نفسه)

تحرير: قد تحتاج إلى تعيين security.cookie_samesite=none في grafana لكي يعمل هذا بشكل صحيح في بعض المتصفحات (هذا لأنه في iframe ، تحدث إعادة توجيه إلى موفر oauth (مجال مختلف) ثم إعادة توجيه مرة أخرى إلى grafana. حاليًا ، لن يسمح Firefox لملف تعريف ارتباط موقع واحد تم تعيينه على lax بالاستمرار بهذه الطريقة. https://bugzilla.mozilla.org/show_bug.cgi؟id=1454027 مما يعني أن grafana تفقد oauth_state ملف تعريف الارتباط إذا لم يتم تعيين cookie_samesite على none )

seanlaff لقد جربت الحل الخاص بك مع AWS Cognito ولكنه يُرجع رأسًا لا يسمح بوضعه في iframe (X-Frame-Options: deny) ، هل من نصائح حول هذا؟

تمكنت من القيام بذلك بنجاح باستخدام Grafana auth.proxy و Nginx's ngx_http_secure_link_module
الروابط التي أستخدمها هي بالتنسيق http://grafana/?user=nayar&md5=2tutcea9nfdsfdsfdsw&expires=1505386800
بمجرد أن ينقر المستخدم عليه ، يتم تعيين ملف تعريف ارتباط الجلسة ويمكن للمستخدم تصفح grafana كما لو أنه قام بتسجيل الدخول بشكل طبيعي.
مزايا:

• تنتهي صلاحية الرابط بعد مرور بعض الوقت + الأمان
• يقوم الارتباط بإنشاء تجزئة مع معرف المستخدم والطابع الزمني ومفتاح المرور + الأمان
• لا حاجة لكتابة كلمة المرور + الراحة

إن nginx الخاص بي هو مثل هذا

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 صالح. لا يعمل إذا قمت بملء العنوان عند الطلب الأول ، والحصول على ملفات تعريف الارتباط والذهاب معها.

لقد انتهيت بالحل التالي:

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_request nginx. تطبيقي مسؤول عن التحكم في الوصول (/ طلب gauth) ويعيد اسم المستخدم في رأس استجابة User .

كيف تستخدم مع iframe؟
أنا جديد في Grafana و NGINX
لذا يرجى مشاركة الحد الأقصى من التفاصيل الآن للتعديل

كيف تستخدم مع iframe؟

pgsekaran هذا الحل ليس من أجل iframe ، ولكن للحصول على grafana UI دون تسجيل الدخول الصريح إلى grafana لمستخدمي تطبيقك. التطبيق في هذه الحالة هو الوكيل الذي يعرف كيفية تسجيل الدخول إلى grafana.

مرحبا،
شكرا على الرد السريع. هل لديك أي رابط مرجعي لإضافة Grafana مع تطبيق آخر باستخدام iframe.i أضفت Grafana إلى تطبيقي ولكني لست قادرًا على ضبط إدارة الاستخدام.
التحيات
في يوم الثلاثاء ، 23 يونيو ، 2020 ، 09:54:57 مساءً بتوقيت غرينتش + 5:30 ، كتب كونستانتين كولوتيوك [email protected] :

كيف تستخدم مع iframe؟

pgsekaran هذا الحل ليس من أجل iframe ، ولكن للحصول على grafana UI دون تسجيل الدخول الصريح إلى grafana لمستخدمي تطبيقك. التطبيق في هذه الحالة هو الوكيل الذي يعرف كيفية تسجيل الدخول إلى grafana.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذه الرسالة الإلكترونية مباشرةً ، أو اعرضها على GitHub ، أو قم بإلغاء الاشتراك.

لا يزال غير مطبق؟ على محمل الجد هذا أمر جيد أن يكون لديك ميزة.

pgsekaran لدي حل لـ iframe ، وهو ليس آمنًا جدًا لأنه يستخدم تسجيل الدخول المستند إلى اسم المستخدم ويعتمد على عدم سهولة تخمين أسماء المستخدمين. في الأساس ، اسم المستخدم هو الرمز المميز.
لقد كتبت عن ذلك هنا ، ليس بتفصيل كبير ولكن eouhg لتبدأ
https://blog.yadamiel.com/tutorials/embed-and-authenticate-grafana-in-a-iframe

pgsekaran لدي حل لـ iframe ، وهو ليس آمنًا جدًا لأنه يستخدم تسجيل الدخول المستند إلى اسم المستخدم ويعتمد على عدم سهولة تخمين أسماء المستخدمين. في الأساس ، اسم المستخدم هو الرمز المميز.
لقد كتبت عن ذلك هنا ، ليس بتفصيل كبير ولكن eouhg لتبدأ
https://blog.yadamiel.com/tutorials/embed-and-authenticate-grafana-in-a-iframe

مرحبا،

أحتاج إلى الإعداد مع NGINX و iframe مع تسجيل الدخول التلقائي

تم شرح المشكلة بالضبط في https://github.com/grafana/grafana/issues/16319#issuecomment -483272921: لا يتم إرجاع معرف الجلسة مع الاستجابة الأولى التي تحتوي على الصفحة "الهيكل العظمي". لا تحتوي الطلبات اللاحقة على رمز تسجيل الدخول التلقائي ، لذلك تفشل.

نستخدم الكروم في وضع الكشك لعرض لوحات معلومات Grafana في أماكن مختلفة. نظرًا لأن مثيل Grafana نفسه متاح أيضًا للمستخدمين ، فإننا نستخدم auth.generic_oauth ( auth.basic حتى 5.x) لتسجيل الدخول إلى البشر و auth.proxy لتسجيل الدخول إلى أجهزة وضع الكشك:

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

كما لاحظ آخرون ، هذا لا يعمل ببساطة. ما سيعمل هو النداء الأول عنوان الموقع http://prometheus.localdomain/grafana/login?autologin=lHOrdypkhxzNYb2lRaIjbNPlOCZw9gWE (الذي يحدد الآن grafana_session كوكي) ومن ثم إعادة توجيه إلى لوحة القيادة الحقيقية. لكن ... وضع الكشك 🤷 و iframes

حل العمل النهائي لدينا هو دمج معامل الاستعلام autologin مع ملف تعريف ارتباط مخصص. نعم ، لا يمكنك تسجيل الخروج عبر واجهة المستخدم الرسومية حيث لا يتم حذف ملف تعريف الارتباط المخصص ، ولكن نظرًا لاستخدام هذه الآلية فقط على أجهزة وضع الكشك ، فلا داعي لذلك.

إذن هنا هو تكوين nginx لخادم 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;
    }
}