Grafana: टोकन यूआरएल द्वारा स्वचालित लॉगिन

बहुत असुरक्षित होगा क्योंकि कोई भी टोकन देख सकता है, आप दृश्यमान डेटा का स्नैपशॉट बना सकते हैं और उसे एम्बेड कर सकते हैं, यह अधिक सुरक्षित होगा

हां, लेकिन स्नैपशॉट का उपयोग करने से आपको इसे संपादित करने की अनुमति नहीं है, या क्या डैशबोर्ड के स्नैपशॉट को संपादित करने का कोई तरीका है?

यह सास के साथ अंतर के लिए बहुत महत्वपूर्ण है।
हमारे पास अपना स्वयं का प्रमाणीकरण और डैशबोर्ड है, हम एक उपयोगकर्ता को अपने डैशबोर्ड से ग्रेफ़ाना तक पार करने की क्षमता प्रदान करना चाहते हैं - एक समान नस में कि कैसे हेरोकू नए अवशेष और शून्य-पासवर्ड के साथ अन्य सेवाओं के साथ हस्तक्षेप करता है।

एक url + टोकन प्रमाणीकरण विधि प्रदान करना परा-पाठ्यक्रम है।
यदि कोई व्यक्ति सार्वजनिक वेबसाइट पर जाता है और एम्बेड करता है, तो सुरक्षा की कोई भी राशि उस व्यक्ति को अपने आप से नहीं बचाएगी। यही उनकी गलती है।
प्रलेखन / यूआई में पर्याप्त चेतावनी प्रदान करना इसके लिए ठीक होना चाहिए।

इस कार्यक्षमता के बिना, उपयोगकर्ताओं को दूसरी लॉगिन स्क्रीन का सामना करना होगा, जहां वे भ्रमित होंगे कि उपयोगकर्ता नाम / पासवर्ड दर्ज करने के लिए क्या होगा।

यह हमारे लिए एक बड़ा अवरोधक है।

Grafana में होने के लिए एक अच्छी सुविधा की तरह लगता है। पीआर के साथ मदद करना चाहते हैं क्योंकि बहुत अधिक अन्य सामान है जो वास्तव में उच्च प्राथमिकता है

अच्छा स्पष्टीकरण @adamlwgriffiths वही होता है जो मेरे साथ होता है।

अभी हमने इस मुद्दे को एक छोटी सी हैक के साथ हल किया है, एक जावास्क्रिप्ट जोड़ते हैं जो ग्राफ्टाना में स्वचालित लॉगिन करता है, लेकिन एक अस्थायी समाधान है

इसके लिए +10 !!
इसे सुरक्षित बनाने के लिए टोकन में निहित उपयोगकर्ता नाम + पासवर्ड + दिनांक का होना चाहिए। इसका उपयोग सुरक्षा में सुधार के लिए x नंबर घंटे के बाद टोकन को समाप्त करने के लिए किया जा सकता है।

अगर मुझे कुछ समय मिलता है तो मैं गंभीरता से इस पर काम करने पर विचार करूंगा

यदि आप टोकन के निर्माण की तारीख जमा कर रहे हैं, तो आप इसे समाप्त कर सकते हैं, तो आप हैश और संबद्ध खाते को भी संग्रहीत कर रहे हैं, इसलिए मुझे नहीं लगता कि हैश को किसी विशेष डेटा से उत्पन्न करने की आवश्यकता है। यह अनुमान लगाने योग्य बनाने के लिए बस एक पर्याप्त बड़ी खोज स्थान होना चाहिए।

@adamlwgriffiths ,

मुझे लगता है कि लंबी अवधि में - उपयोगकर्ता / org / एपीआई टोकन को एक नई पद्धति के बजाय समेकित करने की आवश्यकता है।
अगर HTML इंटरफ़ेस से उपयोग की अनुमति देने के लिए एपीआई टोकन का विस्तार किया गया था, तो यह एक समस्या नहीं होगी।
एपीआई टोकन में पहले से ही भूमिकाएं हैं, और इसे रद्द किया जा सकता है, इसलिए इसे केवल शुद्ध एपीआई के बजाय वेब दृश्य के लिए उपयोग करने की आवश्यकता है।

IMO API टोकन सामान्य उपयोगकर्ताओं की तरह ही काम करना चाहिए। एक मनमाना अलगाव है जिसे प्रलेखित नहीं किया गया है और मुझे प्रति-सहज ज्ञान युक्त लगता है। एपीआई कुंजियों की जांच के लिए सभी लॉगिन जांचों को सक्षम करना मुझे सबसे अच्छा लगता है।

क्या यह सुविधा लागू हो गई है? मैं एक उपयोगकर्ता को स्वचालित रूप से अपनी साइट से ग्राफ्टाना डैशबोर्ड पर पुनर्निर्देशित करने की कोशिश कर रहा था।

@comcomservices टोकन पर ही अनुवर्ती

मुझे इस तरह की सलाह देने में संकोच है, मेरा दृढ़ विश्वास है कि क्रिप्टोग्राफी कठिन है, और आप क्या कर रहे हैं, इसकी पूरी समझ के बिना, इसे करने का प्रयास करना अच्छा नहीं है।

एन्क्रिप्टेड टोकन के साथ दूसरा मुद्दा यह है कि वे बड़े होते हैं, और जितनी अधिक जानकारी उतनी बड़ी हो जाती है।
जहां बेतरतीब तार किसी भी लंबाई के लिए बनाया जा सकता है, जब तक कि अंतरिक्ष पर्याप्त रूप से बड़ा न हो जाए, जिससे बल को बल मिल सके।

@adamlwgriffiths जहां तक ​​क्रिप्टोग्राफी जाती है, मेरी इसमें एक औपचारिक पृष्ठभूमि है और इसका आनंद लेते हैं, लेकिन इस मामले में मैं पूरी तरह से सहमत हूं कि एक टोकन सबसे अच्छा होगा .. बस इस गो सामान को जानने की कोशिश कर रहा था, सी ++ और asm कर रहा था वैसे भी बहुत लंबा ... मैं इसे प्राप्त करूंगा और यह मेरी सूची में पहली बार है

मैं इस सुविधा के लिए तत्पर हूँ! किसी साइट पर टोकन एम्बेड करने के संबंध में @adamlwgriffiths के बारे में ऊपर टिप्पणी करते हुए, मेरा मानना ​​है कि इसे कम करने का तरीका उस डोमेन के साथ उस टोकन को जोड़ना है जो इसे अनुरोध करना चाहिए; इस तरह से कि टोकन केवल तभी काम करता है जब मूल मेल खाता हो। इसका एक उदाहरण - फिर से, अगर मैं मुद्दे को सही ढंग से समझता हूं - संतरी के रावेन-जेएस ; यह एक सार्वजनिक URL बनाएगा और फिर इसे मूल (नीचे देखें) द्वारा प्रतिबंधित करेगा। क्या इससे सुरक्षा चिंता कम होगी?

@ Germanaz0 क्या आपका ऑटो-लॉगिन JS सार्वजनिक रूप से उपलब्ध है? मैं मास्टर ब्रांच के खिलाफ कुछ समान लागू करना चाहता हूं और ऐसा प्रतीत होता है कि बैकएंड डैशबोर्ड पेज को हिट करने से पहले लॉगिन स्क्रीन पर रीडायरेक्ट करता है। मैं अभी परियोजना संरचना से सुपर परिचित नहीं हूं, इसलिए मैं जेएस कोड में सही अनुभाग में प्लगिंग नहीं कर सकता हूं।

@rca हाँ, लेकिन मेरी समाधान करना बहुत ही आसान है https://gist.github.com/Germanaz0/d41b5f60dd8097405b6b

आपको एक इनपुट पैरामीटर प्राप्त होता है, जैसे {उपयोगकर्ता: _USERNAME_, पास: _PASS_, redirect_to: _URL_TO_REDIRECT} के साथ json का आधार = base64।

आप उस स्क्रिप्ट को लॉगिन पेज में शामिल करेंगे।

@ Germanaz0 , साझा करने के लिए धन्यवाद! अपनी टिप्पणी भेजने के बाद मैंने एक नज़र रखना शुरू किया और, जैसा कि आपने बताया, मुझे पता चला कि मुझे लॉगिन पृष्ठ को अपडेट करने की आवश्यकता है। मैंने थोड़ा अलग तरीका अपनाया और स्टैंड-अलोन स्क्रिप्ट बनाने के बजाय लॉगिन कंट्रोलर को अपडेट किया; मेरा परिवर्तन यहाँ है: https://github.com/zymbit/grafana/tree/auto-login-by-cookie-redirect

क्या यह एक पुल अनुरोध के योग्य है? मैं इसे एक मर्ज करने योग्य स्थिति में लाने के लिए आवश्यक mods बनाने के लिए खुश हूँ।

इस पर किसी भी अद्यतन?
@rca क्या आपने PR बनाया?

@ पीआर से एक पीआर के लिए +1

@ जर्मनज़0 , आप अपनी .js फ़ाइल सहित किस फ़ाइल में हैं?

@rca क्या आपके पास अपने लॉगिन नियंत्रक मॉड का उपयोग करने के बारे में कोई निर्देश हैं? मैं ग्राफ्टाना के लिए नया हूं और एक अप्राप्त कियोस्क के लिए यह काम करने की कोशिश कर रहा हूं।

BTW अगर किसी और को कियोस्क, आदि के लिए इसे पूरा करने के लिए एक तरीके की आवश्यकता है, तो ग्राफ्टाना के ऑर्टप्रोक्सी को चबाएं । इस और अपाचे के साथ मुझे जो चाहिए वह पूरा करने में सक्षम था।

@scottfuhrman औपचारिक रूप से कुछ भी नहीं लिखा है, हालाँकि, यहाँ मेरा उपयोग और कार्यान्वयन है:

मैं कियोस्क मोड की तलाश में नहीं था, बल्कि एक डैशबोर्ड को बाहरी पृष्ठ पर एक आइफ्रेम के रूप में एम्बेड करने का एक तरीका था। उदाहरण के लिए चार्ट बहुत साफ-सुथरे हैं।

डैशबोर्ड को एम्बेड करने के लिए जिस पृष्ठ पर आप देख रहे हैं, आपको निम्नलिखित मार्कअप की आवश्यकता है:

<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

मेरे पास इसके लिए स्टाफिंग संसाधन नहीं हैं, लेकिन मुझे इसके लिए प्रयास करने में खुशी होगी।

सोचा था कि मैं इसे हल कर दिया था जब तक मैं एक प्लेलिस्ट का उपयोग करने की कोशिश की। किसी दिए गए डैशबोर्ड के लिए ऑर्टप्रोक्सी का उपयोग करना जब तक हम पूरी तरह से सुरक्षा को अक्षम नहीं करते हैं तब तक मुझे एक कियोस्क मोड होने की बात समझ में नहीं आती है जब वास्तविक कियोस्क एप्लिकेशन को लागू करना असंभव है?

@torkelo मैंने अपने लिए इस पर काम करने के लिए @ over64 को भर्ती किया है।

आप इसे लागू करने की अनुशंसा कैसे करते हैं? मूल रूप से जो मुझे चाहिए वह URL स्ट्रिंग में एक टोकन होना चाहिए जो प्रमाणीकरण को बायपास / हल करता है। इसके लिए सबसे अच्छा तरीका क्या है?

निश्चित नहीं है, अनुसंधान करना होगा कि इस तरह की सुविधा को सुरक्षित रूप से कैसे लागू किया जाना चाहिए

समझ गया। आपकी योजना तैयार करने के बाद हम तैयार हैं :)

यदि आपके पास कोई विचार है कि कैसे करना है तो कृपया मुझे बताएं और मैं इसका मूल्यांकन कर सकता हूं

ठीक है। @ ओवर 64 कुछ देख लेंगे और कुछ सुझाएंगे।

@torkelo क्या आप @ over64 के PR को देख सकते हैं।

कोई आसान काम? मैं @ Germanaz0 समाधान को लागू करने की कोशिश कर रहा हूं, लेकिन यह मेरे लिए काम नहीं कर रहा है :(

यह एक होना चाहिए, और एक iframe के भीतर स्नैपशॉट एम्बेड करने पर अवरुद्ध है। एम्बेडेड स्नैपशॉट url को लॉगिन कुंजी / टोकन का समर्थन करना चाहिए।

ज़रा सुनिए सभी,

इस थ्रेड में हाल की टिप्पणियाँ सम्मान के साथ हैं:

• सुरक्षा
• एक iframe के भीतर एम्बेड करना

सुरक्षा के संबंध में कृपया मेरी पुरानी टिप्पणी पर विचार करें :

और एक iframe में एम्बेड करने के बारे में: https://github.com/grafana/grafana/issues/3752#issuecomment -267062843

इस शाखा (यद्यपि काफी पुरानी) में प्रवचन से उधार लिया गया कोड है जो अच्छी तरह से एक iframe के आकार के साथ-साथ टोकन के माध्यम से प्रमाणित करता है जैसा कि ऊपर टिप्पणी में वर्णित है।

@torkelo कृपया मुझे बताएं कि क्या आप उपरोक्त तत्वों को शामिल करते हुए एक पुल अनुरोध पर विचार करेंगे।

@rca आपके कोड में वह एम्बेड

@zoell यह

@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/ निर्देशिका में नहीं बन रही है और समाप्त हो रही है, तो कृपया मुझे बताएं।

धन्यवाद!

क्या कम से कम ग्राफ्टाना को लोकलहोस्ट एक्सेस तक सीमित करना संभव है? (एक ही सर्वर साइट पर संकीर्ण पैनल साझा करने के लिए)

मैं एक उचित कार्यान्वयन के साथ किसी को छुरा लेते देखना पसंद करूंगा जो ऊपर की तरफ जा सके। हमने जो समाधान (# 7431) प्रस्तावित किया, उसे कभी स्वीकार नहीं किया गया :(

मुझे खुशी है कि हमारी ओर से किसी ने इस पर कुछ समय बिताया, लेकिन हमें इस बात पर मार्गदर्शन की आवश्यकता है कि क्या स्वीकार्य होगा।

Grafana के auth.proxy और Nginx के ngx_http_secure_link_module का उपयोग करके सफलता के साथ ऐसा करने में कामयाब रहे

मेरे द्वारा उपयोग किए जाने वाले लिंक http://grafana/?user=nayar&md5=2tutcea9nfdsfdsfdsw&expires=1505386800 प्रारूप में हैं

एक बार जब उपयोगकर्ता उस पर क्लिक करता है, तो सत्र कुकी सेट हो जाती है और उपयोगकर्ता ग्राफ्टाना ब्राउज़ कर सकता है जैसे कि वह सामान्य रूप से लॉग इन करता है।

लाभ:

• लिंक कुछ समय + सुरक्षा के बाद समाप्त हो रहा है
• लिंक उपयोगकर्ता, टाइमस्टैम्प और पासकी + सुरक्षा के साथ हैश उत्पन्न करता है
• पासवर्ड + सुविधा में टाइप करने की आवश्यकता नहीं है

मेरा नग्नेक्स कॉन्फिडेंस इस तरह है

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 recompile था और यह बात है।

नैयर, क्या आप मुझे बता सकते हैं कि क्या आपने जो समाधान लागू किया है वह ग्राफ्टाना के सभी संस्करणों के साथ काम कर सकता है। मेरे संगठन में, वे पहले ही स्थापित कर चुके हैं

इसे हल करने के लिए कुछ विचारों (और समस्याओं) को बाहर निकालना।

सबसे तेज समाधान:

1) एक एपीआई कुंजी पर एक विशेष प्रकार (ध्वज) जोड़ें ताकि इसे आपको साइन इन करने के लिए url में उपयोग किया जा सके।

Proos: API कुंजियाँ केवल Org Admins द्वारा जोड़ी जा सकती हैं।

2) उपयोगकर्ताओं को एपीआई कुंजी और यूआरएल कुंजी (एपीआई कुंजी का संस्करण) बनाने के लिए संभव बनाते हैं।

इसके साथ समस्याएं ओउथ सेटअप होने वाली हैं जहां अगर कोई उपयोगकर्ता एपीआई कुंजी या यूआरएल कुंजी बना सकता है, तो वे ग्राफाना (ओउथ सिस्टम से) को हटा दिए जाने के बाद इसका उपयोग कर पाएंगे। जैसा कि एपीआई कुंजी या यूआरएल कुंजी के लिए एक ओह लॉगिन की आवश्यकता नहीं होगी। यह उपयोगकर्ता एपीआई कुंजी के लिए एक बड़ी समस्या होने वाली है जब हम अंततः उन्हें करते हैं। एक शमन समाधान केवल ओआरजी व्यवस्थापक या उपयोगकर्ता एपीआई कुंजी बनाने के लिए ग्रफाना सर्वर प्रवेश की अनुमति दे सकता है।

विचार @DanCech ? एक AllowUrlLogin ध्वज के साथ एपीआई कुंजी का उपयोग करके आगे बढ़ें?

मुझे नहीं लगता कि एपीआई कुंजी बुनियादी ढांचे का उपयोग करने का सही तरीका है, क्योंकि बाद में अधिक कार्यक्षमता जोड़ना मुश्किल हो जाता है (उदाहरण के लिए, डैशबोर्ड के एक विशेष सेट में यूआरएल को सीमित करना, गैर-प्रवेश लॉगिन लिंक बनाने की अनुमति देता है ) और उपयोगकर्ताओं के लिए भ्रामक होने की संभावना है। हम निश्चित रूप से समान अवधारणाओं का उपयोग कर सकते हैं और एक समान बैकएंड संरचना है, लेकिन यह हमें और विकल्प देता है यदि हम इसे अलग करते हैं, और मुझे लगता है कि यह उपयोगकर्ताओं के लिए स्पष्ट होगा।

जहाँ तक ओउथ लॉगिन प्रश्न है, मुझे लगता है कि हमें यह पता लगाना होगा कि यहाँ क्या गुंजाइश होनी चाहिए। ओउथ उपयोगकर्ताओं के लिए भी यही समस्या है यदि आपके पास भी पासवर्ड सक्षम है, क्योंकि वे एक स्थानीय पासवर्ड सेट कर सकते हैं और ओथ अकाउंट के निष्क्रिय होने के बाद उस तरह से लॉग इन कर पाएंगे। उस समस्या का एकमात्र वास्तविक समाधान उपयोगकर्ता खाते में उस लिंक को संग्रहीत करना है और हमेशा अपने लॉगिन को स्वीकार करने से पहले ओउथ रीडायरेक्ट लूप के माध्यम से एक ओउथ उपयोगकर्ता को भेजें।

मुझे भी लगता है कि हमें इस कार्यक्षमता के लिए एक उचित नाम के साथ आने की जरूरत है। "लॉगिन URL" बहुत व्यापक हो सकता है और वास्तव में भविष्य में उपयोग के लिए जगह नहीं छोड़ता है, उदाहरण के लिए एक विशेष डैशबोर्ड तक सीमित लाइव लिंक को साझा करने के लिए।

@mattttt अपने विचारों को प्राप्त करना पसंद करेंगे

चूंकि बाद में अधिक कार्यक्षमता जोड़ना मुश्किल हो जाता है (उदाहरण के लिए, डैशबोर्ड के एक विशेष सेट में url को सीमित करना, गैर-प्रवेशकों को लॉगिन लिंक बनाने की अनुमति देना)

मैं इस लॉगिन सुविधा को अनुमतियों से जोड़ने या इसे विशिष्ट डैशबोर्ड पर प्रतिबंधित करने से संकोच कर रहा हूं (इसे किसी मूल भूमिका या उपयोगकर्ता से लिंक करने के अलावा)। क्योंकि यह इसे एक साझा सुविधा में बदल देगा और सुरक्षा अपेक्षाओं को पूरा करेगा जो पूरी नहीं होती हैं (क्योंकि आप किसी डेटा स्रोत से सभी डेटा को क्वेरी कर सकते हैं जो एक ऑर्ग द्वारा उपयोग किया जाता है)।

उस समस्या का एकमात्र वास्तविक समाधान उपयोगकर्ता खाते में उस लिंक को संग्रहीत करना है और हमेशा अपने लॉगिन को स्वीकार करने से पहले ओउथ रीडायरेक्ट लूप के माध्यम से एक ओउथ उपयोगकर्ता को भेजें।

यकीन नहीं है कि लॉगिन यूआरएल / उपयोगकर्ता एप टोकन को "रिवाइजिंग" कैसे करता है। अगर वे अपनी पहुंच से बाहर होने के बाद कभी भी ओहूत के साथ लॉगिन करने की कोशिश नहीं करते, तो ग्राफ्टाना को कभी पता नहीं चलता।

@hemsush इस ब्लॉग पोस्ट के अनुसार, यह Grafana 2.0 से ऊपर की ओर काम करना चाहिए: https://grafana.com/blog/2015/12/07/grafana-authproxy-have-it-your-way/

मैं इस लॉगिन सुविधा को अनुमतियों से जोड़ने या इसे विशिष्ट डैशबोर्ड पर प्रतिबंधित करने से संकोच कर रहा हूं (इसे किसी मूल भूमिका या उपयोगकर्ता से लिंक करने के अलावा)। क्योंकि यह इसे एक साझा सुविधा में बदल देगा और सुरक्षा अपेक्षाओं को पूरा करेगा जो पूरी नहीं होती हैं (क्योंकि आप किसी डेटा स्रोत से सभी डेटा को क्वेरी कर सकते हैं जो एक ऑर्ग द्वारा उपयोग किया जाता है)।

यह एक समस्या है जिसे हल करने की आवश्यकता है, इसलिए मेरा सुझाव यह होगा कि इस प्रणाली को भविष्य के लिए उस उपयोग-मामले के साथ डिज़ाइन किया जाए।

यकीन नहीं है कि लॉगिन यूआरएल / उपयोगकर्ता एप टोकन को "रिवाइजिंग" कैसे करता है। अगर वे अपनी पहुंच से बाहर होने के बाद कभी भी ओहूत के साथ लॉगिन करने की कोशिश नहीं करते, तो ग्राफ्टाना को कभी पता नहीं चलता।

मेरा विचार यह है कि क्लाइंट को इन लिंक्स में से किसी एक का उपयोग करते समय मिलने वाला दृश्य "अनाम" उपयोगकर्ता के समान होना चाहिए, जहां वे जादुई रूप से किसी विशेष उपयोगकर्ता के रूप में लॉग इन नहीं होते हैं, बल्कि एक सीमित व्यूअर खाता प्राप्त करते हैं, जो इस सुविधा को पूरी तरह से तलाक देगा। व्यक्तिगत उपयोगकर्ता खातों से। यह व्यक्तिगत उपयोगकर्ता खाता अनुमतियों के मुद्दे को दरकिनार कर देगा, जोखिम स्तर को कम कर देगा क्योंकि लिंक को किसी भी परिवर्तन करने के लिए उपयोग नहीं किया जा सकता है, और ऑर्गन व्यवस्थापक द्वारा सभी सक्रिय एक्सेस लिंक के केंद्रीकृत प्रबंधन की अनुमति दे सकता है।

समाधान का प्रस्ताव

1) नई अवधारणा "व्यूअर URL टोकन" का परिचय दें, जिसे आप एपीआई कीज़ पेज से जोड़ / हटा सकते हैं (हम बाद में इसके लिए एक नया पेज बना सकते हैं)। नई तालिका url_token में संग्रहीत करें और वे एपीआई कुंजियों के समान सुरक्षा दृष्टिकोण से कार्य करेंगे। यही कारण है कि वे उत्पन्न किए जाएंगे और उसी तरह से मान्य होंगे जैसे एपी कीज हैं। हालाँकि, आपको url में "और url-Cort-token =" के साथ उपयोग करने के लिए लॉग इन किया जा सकता है”।
2) पीएनजी रेंडर एपीआई के साथ केवल टोकन को प्रतिबंधित करने का विकल्प (अधिक सुरक्षित होगा क्योंकि URL टोकन वाले उपयोगकर्ता किसी भी क्वेरी को केवल मौजूदा डैशबोर्ड / पैनल को देखने में सक्षम नहीं होंगे)
3) भविष्य में हमें उपयोगकर्ता समूहों और डैशबोर्ड अनुमतियों के लिए टोकन लिंक करने का एक तरीका खोजना होगा, यह सुनिश्चित नहीं होगा कि यह कैसे काम करेगा। मुझे लगता है कि इसके लिए एक डमी उपयोगकर्ता बनाना अच्छा हो सकता है जिसका उपयोग "URL टोकन" उपयोगकर्ताओं को विशिष्ट डैशबोर्ड और डेटा स्रोतों को अनुमति देने में किया जा सकता है। अनुमति जाँच में url टोकन के लिए स्पष्ट चेक / जॉइन करने से नफरत होगी।

4) यह स्पष्ट करें कि url टोकन वाले किसी भी व्यक्ति के पास सभी संगठनों डेटा स्रोतों तक पहुंच होगी (और तकनीकी रूप से कोई क्वेरी जारी कर सकता है) (जब तक कि एपीआई विकल्प का उपयोग करने के लिए प्रतिबंधित नहीं किया जाता है)।

विचार @bergquist @DanCech

पीएनजी रेंडर एपीआई के साथ केवल टोकन को प्रतिबंधित करने का विकल्प (अधिक सुरक्षित होगा क्योंकि URL टोकन वाले उपयोगकर्ता किसी भी क्वेरी को केवल मौजूदा डैशबोर्ड / पैनल को देखने के लिए जारी नहीं कर पाएंगे)

मुझे नहीं लगता कि पीएनजी प्रतिपादन अच्छा समाधान है। यह झिलमिलाहट करेगा और यह असली ग्राफ्टाना जितना अच्छा लगेगा।

मुझे उपयोगकर्ता से टोकन कनेक्ट करने का विचार पसंद है। उपयोगकर्ता समूहों और डैशबोर्ड फ़ोल्डर अनुमतियों के लिए उस टोकन / लॉगिन को कनेक्ट करने का सबसे आसान तरीका। लेकिन मुझे लगता है कि टोकन (टीवी लॉग इन / व्यू मोड / टीवी मोड) का उपयोग करने में उपयोगकर्ता को Viewer भूमिका में रहने के लिए बाध्य करना चाहिए।

यह स्पष्ट करें कि url टोकन वाले किसी भी व्यक्ति के पास सभी संगठनों डेटा स्रोतों तक पहुंच होगी (और तकनीकी रूप से कोई क्वेरी जारी कर सकता है) (जब तक कि एपीआई विकल्प का उपयोग करने के लिए प्रतिबंधित नहीं किया जाता है)।

नए टोकन बनाते समय जानकारी और चेतावनी जोड़ना मदद कर सकता है।

एक "सामान्य" उपयोगकर्ता को टोकन बांधने में समस्या यह है कि यह उपयोगकर्ता द्वारा संशोधित या हटाए जाने पर सभी प्रकार की समस्याओं का कारण बनता है। यदि यूआरएल टोकन एक समूह के सदस्य होने में सक्षम हैं उसी तरह से उपयोगकर्ता हैं तो विशेष डैशबोर्ड आदि तक पहुंच के साथ व्यक्तिगत यूआरएल स्थापित करने में बड़ी मात्रा में लचीलापन होगा।

मुझे यकीन नहीं है कि यह अनुमति चेक में बहुत जटिलता जोड़ देगा, आप समूह के सदस्यों के लिए एक अलग तालिका का उपयोग कर रहे होंगे जो इस बात पर निर्भर करता है कि दर्शक एक नियमित उपयोगकर्ता है या एक यूआरएल टोकन है लेकिन पूरे सिस्टम में एक्सेस चेक नहीं होना चाहिए बदलने की जरूरत।

जहां तक ​​वास्तव में डेटा स्रोतों तक पहुंच को लागू करने की बात है, तो नियमित उपयोगकर्ताओं की तुलना में यहां कोई अंतर नहीं है। उस समस्या का अंतिम समाधान डेटा स्रोत प्लगइन्स को बैकएंड पर ले जाना है और डैशबोर्ड, पैनल, समय सीमा और टेम्प्लेट var मान निर्दिष्ट करके और उपयोगकर्ता द्वारा मान्य किए जाने के बाद बैकएंड पर बनाए गए वास्तविक क्वेरीज़ को निर्दिष्ट करके डेटा स्रोत अनुरोधों को जोड़ना है। पहुंच है और यह कि टेम्पलेट var मान वैध हैं।

एक "सामान्य" उपयोगकर्ता को टोकन बांधने में समस्या यह है कि यह उपयोगकर्ता द्वारा संशोधित या हटाए जाने पर सभी प्रकार की समस्याओं का कारण बनता है

समस्या यह है कि जो कोई भी टोकन जानता है (भले ही खाता बंद है) डैशबोर्ड को देख सकता है दोनों समाधान के लिए सही है। उपयोगकर्ता या टोकन को हटाकर फिर से उपयोग किया जा सकता है।

मुझे यकीन नहीं है कि यह अनुमति चेक में बहुत जटिलता जोड़ देगा, आप समूह के सदस्यों के लिए एक अलग तालिका का उपयोग कर रहे होंगे जो इस बात पर निर्भर करता है कि दर्शक एक नियमित उपयोगकर्ता है या एक यूआरएल टोकन है लेकिन पूरे सिस्टम में एक्सेस चेक नहीं होना चाहिए बदलने की जरूरत।

प्रमाणीकरण की परवाह किए बिना चेक को समान दिखना चाहिए। तो यह एक बड़ी समस्या नहीं है। टोकन / उपयोगकर्ताओं को समूह, डैशबोर्ड आदि में जोड़ने के लिए UI गड़बड़ हो सकता है और यह केवल बहुत ही कम उपयोगकर्ताओं की मदद करेगा।

जहां तक ​​वास्तव में डेटा स्रोतों तक पहुंच को लागू करने की बात है, तो नियमित उपयोगकर्ताओं की तुलना में यहां कोई अंतर नहीं है। उस समस्या का अंतिम समाधान डेटा स्रोत प्लगइन्स को बैकएंड पर ले जाना है और डैशबोर्ड, पैनल, समय सीमा और टेम्प्लेट var मान निर्दिष्ट करके और उपयोगकर्ता द्वारा मान्य किए जाने के बाद बैकएंड पर बनाए गए वास्तविक क्वेरीज़ को निर्दिष्ट करके डेटा स्रोत अनुरोधों को जोड़ना है। पहुंच है और यह कि टेम्पलेट var मान वैध हैं।

यह वह जगह है जहां मुझे लगता है कि हमें डैशबोर्ड को सुरक्षित तरीके से साझा करने के लिए एक अच्छा अनुभव प्रदान करने के लिए काम करना शुरू करना चाहिए। इसके बिना सभी समाधान खराब ट्रेडों ऑफ की तरह महसूस करते हैं। मुझे लगता है कि यह तक कम से कम keept होना चाहिए जब तक डेटासोर्स एक्सेस हल नहीं हो जाता।

मैं भी username+passwd+ldap auth मोड में एम्बेड डैशबोर्ड के साथ इस मुद्दे को मिला ...
इस बारे में कोई अपडेट?

मुझे दर्शक टोकन विकल्प में बहुत दिलचस्पी है। अगर मैं किसी भी तरह से सहायता कर सकता हूं तो मुझे सहायता करने में खुशी होगी।

हैलो दोस्तों!
मैं एक डैशबॉर्ड के लिए एक प्रमाणित लिंक बनाने की कोशिश कर रहा हूं, मेरे पास जावा में एक बैकएंड और JSF में एक फ्रंट एंड है, मैं एक उपयोगकर्ता को स्क्रीन पर रखना चाहता हूं, जिसे क्लिक करने पर, उपयोगकर्ता को सीधे अपने डैशबोर्ड पर रीडायरेक्ट करेगा, मैं अवधारणा को अच्छी तरह से समझ में नहीं आ रहा है, क्या आपके पास कोई उदाहरण है कि मैं यह कैसे कर सकता हूं?

नमस्ते,

बस एक विचार, मदद करने की कोशिश कर रहा है। इस तरह बेसिक ऑथेंट का उपयोग करके नया उपयोगकर्ता एपीआई क्यों नहीं जोड़ा जाता है
? 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)
}

मुझे पता है कि आप एक जादूगर नहीं हैं और कोडिंग लेगो नहीं खेल रही है लेकिन यह मेरे लिए बहुत महत्वपूर्ण कार्य है। मैं मदद करने की कोशिश करूंगा।

GrafanaCon दौरान @DanCech विचार एक GUID कुंजी के साथ सार्वजनिक प्लेलिस्ट बनाने का उल्लेख किया। आज स्नैपशॉट कैसे काम करते हैं, इसके समान। ऐसी कुंजी साझा करना / संग्रहीत करना एपीआई टोकन के रूप में सुरक्षित माना जा सकता है, लेकिन प्लेलिस्ट देखने के लिए सीमित है। डैशबोर्ड दृश्य अनुमतियों को मान्य करने के लिए प्लेलिस्ट को निर्माता / updater के साथ जोड़ा जा सकता है।

URL https://play.grafana.com/playlists/public/<hash> जैसा कुछ देख सकता है

इस समाधान के बारे में एक बात मुझे पसंद है कि यह केवल प्लेलिस्ट (डैशबोर्ड) को देखने के लिए कार्यक्षमता को प्रतिबंधित करता है जो मुझे लगता है कि इस तरह के टोकन के लिए सबसे बड़ा उपयोग मामला है।

लेकिन हमें अभी भी उपयोगकर्ता को किसी तरह से लॉगिन करने की आवश्यकता होगी क्योंकि डैशबोर्ड एसएल / एनोटेशन आदि के लिए सर्वर-साइड प्रमाणीकरण की आवश्यकता होगी।

मुझे लगता है कि हम इस तरह के समाधान के बारे में अधिक सोच सकते हैं। मैं मुख्य रूप से GrafanaCon से हमारी बातचीत को शांत करना चाहता था :)

धन्यवाद @bergquist , निश्चित रूप से इस सामान को नीचे लिखे जाने के लिए अच्छा है जबकि यह अभी भी ताज़ा है!

उस विचार का अगला विकास चीजों को और कम करने के लिए एक "स्क्रीन" की अवधारणा को जोड़ना था, ताकि उपयोगकर्ता एक "स्क्रीन" बना सके, जिसमें तब एक गुप्त हैशेड यूआरएल था जिसे वह कनेक्ट करेगा। यह उसी उद्देश्य को पूरा करेगा लेकिन ग्राफाना के भीतर से स्क्रीन के प्रबंधन के लिए अनुमति देगा, इसलिए उपयोगकर्ता नियंत्रित कर सकता है कि कौन सी प्लेलिस्ट दिखाई गई, आदि।

यहां अंतिम लक्ष्य एक उपयोगकर्ता को आसानी से एसडी कार्ड या यूएसबी छवि बनाने के लिए एक तंत्र का समर्थन करना होगा जो कि एक समर्पित रास्पबेरी पाई को बूट करने के लिए इस्तेमाल किया जा सकता है और प्रमाणीकरण हुप्स के माध्यम से कूदने के बिना ग्रेफाना से सुरक्षित रूप से वांछित प्लेलिस्ट प्रदर्शित करता है।

यहां अंतिम लक्ष्य एक उपयोगकर्ता को आसानी से एसडी कार्ड या यूएसबी छवि बनाने के लिए एक तंत्र का समर्थन करना होगा जो कि एक समर्पित रास्पबेरी पाई को बूट करने के लिए इस्तेमाल किया जा सकता है और प्रमाणीकरण हुप्स के माध्यम से कूदने के बिना ग्रेफाना से सुरक्षित रूप से वांछित प्लेलिस्ट प्रदर्शित करता है।

@DanCech यह बिल्कुल उपयोग मामला है जिसकी मुझे तलाश है।

उस विचार का अगला विकास चीजों को और कम करने के लिए एक "स्क्रीन" की अवधारणा को जोड़ना था, ताकि उपयोगकर्ता एक "स्क्रीन" बना सके, जिसमें तब एक गुप्त हैशेड यूआरएल था जिसे वह कनेक्ट करेगा।

@DanCech यह सही लगता है!

हेलो सब लोग,

ऐसा लगता है कि जर्मनेज़ 0 द्वारा खोले गए मूल मुद्दे से थोड़ा दूर है

उपयोगकर्ता लॉगिन टोकन के माध्यम से एक स्वचालित लॉगिन पास होना अच्छा होना चाहिए, यह साइटों पर iframes एम्बेड करने के लिए एक आंशिक समाधान हो सकता है।

और adamlwgriffiths द्वारा समझाया गया

हमारे पास अपना स्वयं का प्रमाणीकरण और डैशबोर्ड है, हम एक उपयोगकर्ता को अपने डैशबोर्ड से ग्रेफ़ाना तक पार करने की क्षमता प्रदान करना चाहते हैं - एक समान नस में कि कैसे हेरोकू नए अवशेष और शून्य-पासवर्ड के साथ अन्य सेवाओं के साथ हस्तक्षेप करता है। एक url + टोकन प्रमाणीकरण विधि प्रदान करना परा-पाठ्यक्रम है।

Germanaz0 एक js स्क्रिप्ट विकसित करता है

अभी हमने इस मुद्दे को एक छोटी सी हैक के साथ हल किया है, एक जावास्क्रिप्ट जोड़ते हैं जो ग्राफ्टाना में स्वचालित लॉगिन करता है, लेकिन एक अस्थायी समाधान है

मैं समझता हूं कि उन्हें अपनी साइट में ग्राफ्टाना चार्ट का उपयोग करने के लिए एक स्वचालित लॉगिन की आवश्यकता है। प्लेलिस्ट के उपयोग से मुझे क्या आवश्यकता है ... क्या यह संभव होगा?

यदि आप बस अपने आप को सर्वश्रेष्ठ शर्त में स्वचालित रूप से लॉग इन करना चाहते हैं तो 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/ind.net.html

मुझे लगता है कि ऊपर PowerBi समाधान OAuth2 पर आधारित है।
Grafana सर्वर साइड OAuth2 का समर्थन करेगा और CORS को सक्षम करेगा।

@Nayar मैं

5.4 रिलीज होने का मुझे बेसब्री से इंतजार है।

Grafana के auth.proxy और Nginx के ngx_http_secure_link_module का उपयोग करके सफलता के साथ ऐसा करने में कामयाब रहे

मेरे द्वारा उपयोग किए जाने वाले लिंक http://grafana/?user=nayar&md5=2tutcea9nfdsfdsfdsw&expires=1505386800 प्रारूप में हैं

एक बार जब उपयोगकर्ता उस पर क्लिक करता है, तो सत्र कुकी सेट हो जाती है और उपयोगकर्ता ग्राफ्टाना ब्राउज़ कर सकता है जैसे कि वह सामान्य रूप से लॉग इन करता है।

लाभ:

• लिंक कुछ समय + सुरक्षा के बाद समाप्त हो रहा है
• लिंक उपयोगकर्ता, टाइमस्टैम्प और पासकी + सुरक्षा के साथ हैश उत्पन्न करता है
• पासवर्ड + सुविधा में टाइप करने की आवश्यकता नहीं है

मेरा नग्नेक्स कॉन्फिडेंस इस तरह है

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 को प्रॉक्सी_पास किया जाता है, तो उपयोगकर्ता को मेरे स्वयं के आवेदन द्वारा कैसे सत्यापित किया जाए।

उपयोगकर्ता प्राधिकरण की जांच करने के लिए मेरा वेब एप्लिकेशन X-XSRF-TOKEN के माध्यम से है।

मैं सर्वर config के लिए नया हूँ। आपकी मदद के लिए इसकी सराहना की।

@torkelo / @bergquist बस एक सिर-अप - यह है कि हमने स्क्रीनली में इसके चारों ओर कैसे काम किया । यह जीवित है और महान काम करता है! कड़ी मेहनत के लिए धन्यवाद, दोस्तों!

@torkelo / @bergquist बस एक सिर-अप - यह है कि हमने स्क्रीनली में इसके चारों ओर कैसे काम किया । यह जीवित है और महान काम करता है! कड़ी मेहनत के लिए धन्यवाद, दोस्तों!

@vpetersson मैं

@GimpMaster हम सिर्फ हेडर का उपयोग करते हैं, इसलिए iframes की कोई आवश्यकता नहीं है। चूंकि हमने खिलाड़ी / ब्राउज़र को लिखा था इसलिए हम पेज लोड में ऑर्टिकल हैडर को इंजेक्ट करने में सक्षम थे।

मैंने अभी-अभी स्क्रीन पर उस @GimpMaster लिंक से दृष्टिकोण का उपयोग करके अपने कियोस्क मोड को काम किया है। मैंने Chrome एक्सटेंशन ModHeader का उपयोग किया है जहां मैंने Bearer API कुंजी के साथ प्राधिकरण शीर्षक जोड़ा है। लेकिन जैसा कि एक्सटेंशन्स को स्लीप 10 एस को लोड करने के लिए कुछ समय की आवश्यकता होती है, रास्पबेरी पाई पर एक कियोस्क स्थापित करने से। यह समाधान iframes के लिए भी काम करेगा लेकिन फिर इसे हर क्लाइंट पर कॉन्फ़िगर करना होगा।

@Nayar मैंने _unsecure_ एक्सेस का उपयोग करने के लिए आपके सुझाए गए ngnix कॉन्फ़िगरेशन को सफलतापूर्वक अनुकूलित किया है। यही है, यह केवल क्वेरी स्ट्रिंग से उपयोगकर्ता नाम लेता है और इसे X-WEBAUTH-USER में डालता है। इसके बाद ग्राफ्टाना सेशन आईडी मिलती है और हम दूर हो जाते हैं। धन्यवाद!

मैं काम करने के लिए md5 विधि प्राप्त करने में असमर्थ हूं। मैं स्पष्ट नहीं हूं कि वास्तव में मुझे md5 फिंगरप्रिंट बनाने की क्या आवश्यकता है। क्या आप विस्तृत कर सकते हैं? वहाँ md5 बनाने पर कोई चाल है?

क्या टोकन 6. कुकी / हेडर / ... 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>

नग्नेक्स

 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 config को इस पर सेट किया और "url में उपयोगकर्ता = 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 गराफना करने के लिए प्रदान करते हैं।

@ उत्तर के लिए धन्यवाद।
मैं प्रलेखन पढ़ता हूं और मेरा एपीआई इसे काम करता है, लेकिन मुझे डायनेमिक यूजर ऑडर की जरूरत है (पेज के सभी यूजर के लिए समान अनुमति नहीं)

@Nayar के इस समाधान में X-WEBAUTH-USER को बिना हार्डकोड के हेडर में शामिल किया गया है, लेकिन मैं इसे काम नहीं कर सकता

मुझे लगता है कि 6.0 या 6.1 में कुछ टूट गया।
मैंने Apache2 में 6.1 (कल 5.3 बजे से) में प्रॉक्सी प्रॉक्सी का उपयोग करके एक पूरी तरह से काम कर रहे इंस्टॉल को अपडेट किया और @r0bles के समान स्क्रीन प्राप्त कर रहा

कृपया ध्यान दें कि ग्रैफाना प्रॉक्सी हेडर को समझने लगता है: यह शुरू में उपयोगकर्ता को लॉग इन करता है, लेकिन बाद के अनुरोधों को 401 की प्रतिक्रिया मिलती है।

@ बिटब्लेड हमें आपके समान कोई अन्य रिपोर्ट नहीं मिली है। कृपया नया बग रिपोर्ट खोलें क्योंकि यह समस्या एक सुविधा अनुरोध के बारे में है।

Grafana के auth.proxy और Nginx के ngx_http_secure_link_module का उपयोग करके सफलता के साथ ऐसा करने में कामयाब रहे

मेरे द्वारा उपयोग किए जाने वाले लिंक http://grafana/?user=nayar&md5=2tutcea9nfdsfdsfdsw&expires=1505386800 प्रारूप में हैं

एक बार जब उपयोगकर्ता उस पर क्लिक करता है, तो सत्र कुकी सेट हो जाती है और उपयोगकर्ता ग्राफ्टाना ब्राउज़ कर सकता है जैसे कि वह सामान्य रूप से लॉग इन करता है।

लाभ:

• लिंक कुछ समय + सुरक्षा के बाद समाप्त हो रहा है
• लिंक उपयोगकर्ता, टाइमस्टैम्प और पासकी + सुरक्षा के साथ हैश उत्पन्न करता है
• पासवर्ड + सुविधा में टाइप करने की आवश्यकता नहीं है

मेरा नग्नेक्स कॉन्फिडेंस इस तरह है

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

तो समाधान Cort_request nginx मॉड्यूल का उपयोग करता है। मेरा एप्लिकेशन एक्सेस कंट्रोल (/ गौथ अनुरोध) के लिए जिम्मेदार है और User प्रतिसाद हेडर में उपयोगकर्ता नाम लौटाता है।

नमस्ते, इस बीच, आप मेरे समाधान का उपयोग कर सकते हैं जो यहाँ वर्णित है: https://github.com/guysoft/FullPageOS/issues/175

यहाँ Grafana की जेनेरिक OAuth प्रमाणीकरण और PHP का उपयोग कर मेरा काम है: https://github.com/nbayramberdiyev/grafana-generic-oauth

आशा है कि यह आपकी मदद करेगा।

बस यह टिप्पणी करना चाहता था कि मैंने इसे कैसे हल किया है http बेसिक रिसोर्स https://github.com/grafana/grafana/issues/13706#issuecomment -540958284

उपयोगकर्ता लॉगिन टोकन के माध्यम से एक स्वचालित लॉगिन पास होना अच्छा होना चाहिए, यह साइटों पर iframes एम्बेड करने के लिए एक आंशिक समाधान हो सकता है।

@ आरसीए आप अपने कोड के साथ एक उदाहरण दे सकते हैं? मैं आपके कोड की प्रतिलिपि बनाता हूं और एम्बेड करता हूं। जेएस, लेकिन यह काम नहीं करता है।

यदि आप oauth का उपयोग कर रहे हैं, तो डबल लॉगिन के बिना एम्बेडेड ग्राफ्टाना को खींचने का एक तरीका है

1. एकल ऑउथ प्रदाता और कोई अन्य लॉगिन तंत्र के साथ ग्राफ्टाना सेटअप करें
2. GF_AUTH_OAUTH_AUTO_LOGIN को सही पर सेट करें
3. एक उपपाठ में ग्राफ्टाना होस्ट करें और एक रिवर्स प्रॉक्सी का उपयोग करें ताकि आपके मुख्य ऐप के रूप में ग्राफाना को उसी मेजबान में परोसा जाए
4. अपने मुख्य ऐप और grafana को एक ही oauth प्रदाता को हुक करें (oauth प्रदाता के लिए वे समान "ऐप" होंगे)
5. ग्राफ्टाना एम्बेड करें
6. जब iframe लोड होता है, तो ग्राफ्टाना स्वचालित रूप से oauth के साथ लॉगिन करने का प्रयास करेगा (जो कि आपके मुख्य ऐप के समान डोमेन पर इसके बाद से सफल होना चाहिए, इस प्रकार एक ही ऑर्टिकल कुकी साझा करना)

संपादित करें: इसके लिए आपको कुछ ब्राउज़रों में सही तरीके से काम करने के लिए security.cookie_samesite=none आवश्यकता हो सकती है (इसका कारण यह है कि iframe में, oauth प्रदाता (अलग डोमेन) पर पुनर्निर्देशित हो रहा है और फिर आपके लिए एक रीडायरेक्ट बैक हो सकता है) grafana डोमेन। वर्तमान में, फ़ायरफ़ॉक्स एक samesite कुकी को lax में इस तरह से बने रहने की अनुमति नहीं देगा। https://bugzilla.mozilla.org/show_bug.cgi?id=1452527 जिसका अर्थ है कि ग्राफ्टाना अपना oauth_state खो देता है। none लिए सेट नहीं है)

@seanlaff मैंने AWS कॉग्निटो के साथ आपके समाधान की कोशिश की, लेकिन यह एक हेडर देता है जो इसे आइफ्रेम (एक्स-फ्रेम-ऑप्शंस: इनकार) में डालने की अनुमति नहीं देता है, इस पर कोई सुझाव?

Grafana के auth.proxy और Nginx के ngx_http_secure_link_module का उपयोग करके सफलता के साथ ऐसा करने में कामयाब रहे
मेरे द्वारा उपयोग किए जाने वाले लिंक http://grafana/?user=nayar&md5=2tutcea9nfdsfdsfdsw&expires=1505386800 प्रारूप में हैं
एक बार जब उपयोगकर्ता उस पर क्लिक करता है, तो सत्र कुकी सेट हो जाती है और उपयोगकर्ता ग्राफ्टाना ब्राउज़ कर सकता है जैसे कि वह सामान्य रूप से लॉग इन करता है।
लाभ:

• लिंक कुछ समय + सुरक्षा के बाद समाप्त हो रहा है
• लिंक उपयोगकर्ता, टाइमस्टैम्प और पासकी + सुरक्षा के साथ हैश उत्पन्न करता है
• पासवर्ड + सुविधा में टाइप करने की आवश्यकता नहीं है

मेरा नग्नेक्स कॉन्फिडेंस इस तरह है

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

तो समाधान Cort_request nginx मॉड्यूल का उपयोग करता है। मेरा एप्लिकेशन एक्सेस कंट्रोल (/ गौथ अनुरोध) के लिए जिम्मेदार है और User प्रतिसाद हेडर में उपयोगकर्ता नाम लौटाता है।

कैसे iframe के साथ उपयोग करने के लिए?
मैं Grafana और NGINX के लिए नया हूं
इसलिए कृपया संशोधित करने के लिए अधिकतम विवरण साझा करें

कैसे iframe के साथ उपयोग करने के लिए?

@pgsekaran यह समाधान iframe के लिए नहीं है, लेकिन अपने ऐप के उपयोगकर्ताओं के लिए स्पष्ट रूप से ग्राफ्टन लॉगिन के बिना grafana UI प्राप्त करने के लिए है। इस मामले में ऐप प्रॉक्सी है जो ग्रैफाना में लॉगिन करना जानता है।

नमस्ते,
त्वरित उत्तर के लिए धन्यवाद। क्या आपके पास iframe.i का उपयोग करके अन्य ऐप के साथ Grafana जोड़ने के लिए संदर्भ के साथ कोई लिंक है, तो मेरे ऐप में Grafana जोड़ें, लेकिन मैं उपयोग प्रबंधन सेट करने में सक्षम नहीं हूं।
सादर गुनगुनाना
मंगलवार, 23 जून, 2020, 09:54:57 अपराह्न GMT + 5: 30, कॉन्स्टेंटिन कोलोट्युक नोटिफिकेशन @githubub ने लिखा है:

कैसे iframe के साथ उपयोग करने के लिए?

@pgsekaran यह समाधान iframe के लिए नहीं है, लेकिन अपने ऐप के उपयोगकर्ताओं के लिए स्पष्ट रूप से ग्राफ्टन लॉगिन के बिना grafana UI प्राप्त करने के लिए है। इस मामले में ऐप प्रॉक्सी है जो ग्रैफाना में लॉगिन करना जानता है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें, या सदस्यता समाप्त करें।

फिर भी इसे लागू नहीं किया जाता है? गंभीरता से यह सुविधा के लिए अच्छा है।

@pgsekaran के पास iframe का एक समाधान है, जो बहुत सुरक्षित नहीं है क्योंकि यह उपयोगकर्ता-आधारित लॉगिन का उपयोग करता है और उपयोगकर्ता नाम पर आसानी से अनुमान लगाने योग्य नहीं होने पर निर्भर करता है। आधारभूत, उपयोगकर्ता नाम टोकन है।
ive ने इसके बारे में यहां लिखा है, महान विस्तार से नहीं बल्कि आपको आरंभ करने के लिए ehhg
https://blog.yadamiel.com/tutorials/embed-and-authenticate-grafana-in-a-iframe

@pgsekaran के पास iframe का एक समाधान है, जो बहुत सुरक्षित नहीं है क्योंकि यह उपयोगकर्ता-आधारित लॉगिन का उपयोग करता है और उपयोगकर्ता नाम पर आसानी से अनुमान लगाने योग्य नहीं होने पर निर्भर करता है। आधारभूत, उपयोगकर्ता नाम टोकन है।
ive ने इसके बारे में यहां लिखा है, महान विस्तार से नहीं बल्कि आपको आरंभ करने के लिए ehhg
https://blog.yadamiel.com/tutorials/embed-and-authenticate-grafana-in-a-iframe

नमस्ते,

मुझे NGINX और iframe को ऑटो लॉगिन के साथ सेटअप करना होगा

सटीक समस्या को https://github.com/grafana/grafana/issues/16319#issuecomment -483272921 में समझाया गया था: सत्र आईडी पहली प्रतिक्रिया के साथ वापस नहीं आती है जिसमें पेज "कंकाल" शामिल है। बाद के अनुरोधों में ऑटो लॉगिन टोकन नहीं होता है, इसलिए वे विफल हो जाते हैं।

हम विभिन्न स्थानों में ग्राफाना डैशबोर्ड प्रदर्शित करने के लिए कियोस्क मोड में क्रोमियम का उपयोग करते हैं। जैसा कि 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"

जैसा कि दूसरों ने उल्लेख किया है, यह केवल काम नहीं करता है। क्या काम करना होगा पहले url http://prometheus.localdomain/grafana/login?autologin=lHOrdypkhxzNYb2lRaIjbNPlOCZw9gWE (जो अब grafana_session कुकी सेट करता है) और फिर वास्तविक डैशबोर्ड पर रीडायरेक्ट करेगा। लेकिन ... कियोस्क मोड mode और iframes mode mode♂️

हमारा अंतिम कार्य समाधान कस्टम कुकी के साथ autologin क्वेरी पैरामीटर को संयोजित करना है। हां, आप GUI के माध्यम से लॉग आउट नहीं कर सकते क्योंकि कस्टम कुकी को हटाया नहीं गया है, लेकिन चूंकि यह तंत्र केवल कियोस्क-मोड मशीनों पर उपयोग किया जाता है, इसके लिए कोई आवश्यकता नहीं थी।

तो यहाँ Grafana सर्वर के लिए nginx config है:

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