Grafana: Masuk otomatis dengan token url

akan sangat tidak aman karena siapa pun dapat melihat token, Anda dapat membuat snapshot dari data yang terlihat dan menyematkannya, itu akan lebih aman.

Ya, tetapi dengan menggunakan snapshot Anda tidak memiliki izin untuk mengeditnya, atau adakah cara untuk mengedit dasbor melalui snapshot?

Ini sangat penting untuk interoperabilitas dengan SaaS.
Kami memiliki otentikasi dan dasbor kami sendiri, kami ingin memberikan kemampuan untuk meneruskan pengguna dari dasbor kami ke Grafana - dengan cara yang mirip dengan bagaimana Heroku beroperasi dengan New Relic dan layanan lain tanpa kata sandi.

Menyediakan metode autentikasi token url + adalah par-for-the-course.
Jika seseorang kemudian pergi dan menyematkannya di situs web publik, maka tidak ada keamanan yang akan menyelamatkan orang itu dari dirinya sendiri. Itu salah mereka.
Memberikan peringatan yang memadai dalam dokumentasi / UI seharusnya sudah cukup untuk ini.

Tanpa fungsi ini, pengguna harus menemukan layar login kedua, di mana mereka akan bingung dengan nama pengguna / kata sandi yang harus dimasukkan.

Ini adalah penghalang besar bagi kami.

Sepertinya fitur yang bagus untuk dimiliki di Grafana. Butuh bantuan dengan PR karena ada begitu banyak hal lain yang sangat diprioritaskan saat ini

Penjelasan bagus @adamlwgriffiths hal yang sama terjadi padaku.

Sekarang Kami menyelesaikan masalah ini dengan sedikit peretasan, menambahkan javascript yang masuk otomatis ke grafana, tetapi merupakan solusi sementara

+10 untuk ini !!
Untuk membuat ini aman, harus ada hash dari nama pengguna + kata sandi + tanggal, yang terdapat dalam token. Ini dapat digunakan untuk mengakhiri token setelah x beberapa jam untuk meningkatkan keamanan.

Jika saya punya waktu, saya akan secara serius mempertimbangkan untuk mengerjakan ini

Jika Anda menyimpan tanggal pembuatan token sehingga Anda dapat kedaluwarsa, maka Anda juga menyimpan hash dan akun terkait, jadi menurut saya hash tidak perlu dibuat dari data tertentu. Ini hanya perlu menjadi ruang pencarian yang cukup besar untuk membuat tebakan menjadi tidak mungkin.

@ adamlwgriffiths , ini seharusnya mendukung beberapa peran dasar juga .. seperti penampil, editor .. dll, mirip dengan apa yang dilakukan dengan kunci API .. Mungkin kita bisa memperpanjangnya sehingga kita bisa meneruskan kunci api melalui url?

Saya pikir - dalam jangka panjang - token pengguna / org / api perlu dikonsolidasikan, daripada menambahkan metode baru.
Jika token API diperluas untuk memungkinkan penggunaan dari antarmuka HTML maka ini tidak akan menjadi masalah.
Token API sudah memiliki peran, dan dapat dicabut, jadi itu hanya perlu digunakan untuk tampilan web daripada API murni.

Token IMO API harus berfungsi sama seperti pengguna normal. Ada segregasi sewenang-wenang yang tidak didokumentasikan dan menurut saya kontra-intuitif. Mengaktifkan semua pemeriksaan masuk untuk juga memeriksa kunci API akan menjadi yang terbaik menurut saya.

Apakah fitur ini sudah diterapkan? Saya mencoba agar pengguna secara otomatis diarahkan ke dasbor grafana dari situs saya ..

@comcomservices Sebagai tindak lanjut dari token itu sendiri, Anda pasti dapat mengenkripsi informasi di dalam token dengan id pengguna, dan waktu kedaluwarsa token. Dengan begitu Anda bisa membaca token itu sendiri dan mendapatkan informasi tanpa memerlukan token untuk disimpan di db dan menjalankan 'sapu dan hapus' pada token lama.

Saya ragu untuk merekomendasikan hal seperti itu, saya sangat yakin bahwa kriptografi itu sulit, dan tanpa pemahaman penuh tentang apa yang Anda lakukan, bukanlah ide yang baik untuk mencoba melakukannya.

Masalah lain dengan token terenkripsi, adalah ukurannya agak besar, dan semakin banyak informasi semakin besar pula ukurannya.
Sedangkan string acak dapat dibuat dengan panjang berapa pun, selama ruangnya cukup besar untuk membuat brute force menjadi tidak layak.

@adamlwgriffiths sejauh kriptografi berjalan, saya memiliki latar belakang formal di dalamnya dan menikmatinya tetapi untuk kasus ini saya setuju penuh bahwa token akan menjadi yang terbaik .. Hanya mencoba mencari tahu hal ini, telah melakukan c ++ dan asm untuk waktu yang terlalu lama ... Saya akan mendapatkannya dan ini adalah yang pertama dalam daftar saya

Saya menantikan fitur ini! Mengenai komentar @adamlwgriffiths di atas sehubungan dengan penyematan token di situs, saya yakin cara menguranginya adalah mengaitkan token tersebut dengan domain yang seharusnya memintanya; dengan cara itu token itu hanya berfungsi ketika asalnya cocok. Contoh dari ini - sekali lagi, jika saya memahami masalahnya dengan benar - adalah raven-js Sentry ; itu akan membuat URL publik dan kemudian membatasinya menurut asalnya (lihat di bawah). Apakah ini mengurangi masalah keamanan?

@ Germanaz0 apakah JS login otomatis Anda tersedia untuk umum? Saya ingin mengimplementasikan sesuatu yang mirip dengan cabang master dan tampaknya backend mengarah ke layar login sebelum membuka halaman dasbor. Saya belum terlalu paham dengan struktur proyek, jadi saya mungkin tidak memasukkan ke bagian kanan dalam kode JS.

@rca ya, tetapi solusi saya sangat sederhana https://gist.github.com/Germanaz0/d41b5f60dd8097405b6b

Anda menerima parameter input seperti? T = base64 dari json dengan {user: _USERNAME_, pass: _PASS_, redirect_to: _URL_TO_REDIRECT}

Anda harus memasukkan script tersebut ke dalam halaman login.

@ Germanaz0 , terima kasih telah berbagi! Setelah mengirim komentar saya, saya mulai melihat-lihat dan, seperti yang Anda tunjukkan, saya menemukan bahwa saya perlu memperbarui halaman login. Saya mengambil pendekatan yang sedikit berbeda dan memperbarui pengontrol login alih-alih membuat skrip yang berdiri sendiri; perubahan saya ada di sini: https://github.com/zymbit/grafana/tree/auto-login-by-cookie-redirect

Apakah ini layak untuk permintaan tarik? Saya akan dengan senang hati membuat mod yang diperlukan untuk membuatnya menjadi status yang dapat digabungkan.

Ada pembaruan tentang ini?
@rca Apakah Anda membuat PR?

1 untuk PR dari @rca

@ Germanaz0 , di file

@rca apakah Anda memiliki petunjuk tentang cara menggunakan mod pengontrol login? Saya baru mengenal grafana dan mencoba membuat ini berfungsi untuk kios tanpa pengawasan.

BTW, jika ada orang lain yang membutuhkan cara untuk melakukannya untuk kios, dll., Periksa authproxy Grafana . Saya dapat mencapai apa yang saya butuhkan dengan ini dan apache.

@scottfuhrman Tidak ada yang ditulis secara resmi, namun, inilah kasus penggunaan dan implementasi saya:

Saya tidak mencari mode kios, melainkan cara untuk menyematkan dasbor sebagai iframe di halaman eksternal. Bagan disematkan dengan cukup bersih, misalnya:

Di halaman yang ingin Anda sematkan dasbor, Anda memerlukan markup berikut:

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

Semoga ini membantu.

+1

Saya tidak memiliki sumber daya staf untuk ini, tetapi saya akan dengan senang hati melakukan crowdfunding untuk upaya ini.

Pikir saya menyelesaikan ini sampai saya mencoba menggunakan daftar putar. Menggunakan authproxy berfungsi untuk dasbor tertentu tetapi begitu saya mencoba daftar putar dengan beberapa dasbor mengalami masalah yang sama. Saya tidak mengerti maksud dari memiliki mode kios ketika tidak mungkin menerapkan aplikasi kios nyata kecuali jika kita benar-benar menonaktifkan keamanan tampilan?

@torkelo Saya telah merekrut @ over64 untuk mengerjakan ini untuk saya.

Bagaimana Anda merekomendasikan ini untuk diterapkan? Pada dasarnya yang saya butuhkan adalah memiliki token dalam string URL yang melewati / menyelesaikan otentikasi. Apa pendekatan terbaik untuk ini?

tidak yakin, harus meneliti bagaimana fitur semacam itu harus diterapkan dengan aman

Mengerti. Kami siap setelah Anda menyusun rencana :)

jika Anda memiliki ide bagaimana melakukannya, beri tahu saya dan saya dapat mengevaluasinya

Baik. @ over64 akan melihat dan menyarankan sesuatu.

@torkelo Bisakah Anda melihat PR @ over64 di # 7431 untuk melihat apakah itu masuk akal.

Ada solusi mudah? Saya mencoba menerapkan solusi @ Germanaz0 tetapi tidak berhasil untuk saya :(

Ini harus dimiliki, jika tidak, salah satu akan diblokir saat menyematkan snapshot dalam iframe. Url snapshot yang disematkan harus mendukung kunci / token login.

Hai semuanya,

Komentar yang lebih baru di utas ini berkaitan dengan:

• keamanan
• menyematkan dalam iframe

Sehubungan dengan keamanan, harap pertimbangkan komentar lama saya di atas: https://github.com/grafana/grafana/issues/3752#issuecomment -200874453

Dan tentang penyematan di iframe: https://github.com/grafana/grafana/issues/3752#issuecomment -267062843

Cabang ini (meskipun cukup lama) berisi kode yang dipinjam dari Discourse yang mengukur iframe dengan baik serta mengautentikasi melalui token seperti yang dijelaskan dalam komentar di atas.

@torkelo Beri tahu saya jika Anda ingin mempertimbangkan permintaan tarik yang menggabungkan elemen di atas.

@rca apa itu embed.js dalam kode Anda di atas?

@zoell Ini adalah beberapa js yang dipinjam dari proyek Discourse untuk mengukur iframe dengan baik di halaman berdasarkan konten yang disematkan dengan bingkai.

@rca oh terima kasih. Saya tidak dapat menemukan file itu di cabang yang Anda sebutkan. Apakah itu tersedia di tempat lain?

@zoell , saya akan

@rca terima kasih itu akan luar biasa.

@rca Maaf, saya masih tidak dapat menemukan file di cabang yang Anda sebutkan sebelumnya.

@TinaRen @zoell Saya menjatuhkan bola tentang ini, maaf.

Namun, setelah melihatnya sekarang, sepertinya file tersebut telah ada sejak lama! 😬

Saya akan melakukan pekerjaan tambahan tentang ini di:

https://github.com/rca/grafana

Dan file tersebut ada di:

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

Jika file ini tidak tersusun dan berakhir di direktori public_gen/ , beri tahu saya.

Terima kasih!

Apakah mungkin untuk setidaknya membatasi grafana untuk akses localhost? (untuk mempersempit berbagi panel ke situs server yang sama)

Saya ingin melihat seseorang mencoba melakukan hal ini dengan implementasi yang tepat yang dapat berkembang pesat. Solusi yang kami usulkan (# 7431), tidak pernah diterima :(

Saya senang seseorang dari pihak kami meluangkan waktu untuk hal ini, tetapi kami membutuhkan panduan tentang apa yang dapat diterima di bagian hulu.

Berhasil melakukan ini dengan sukses menggunakan Grafana auth.proxy dan Nginx ngx_http_secure_link_module

Tautan yang saya gunakan dalam format http://grafana/?user=nayar&md5=2tutcea9nfdsfdsfdsw&expires=1505386800

Setelah pengguna mengkliknya, cookie sesi diatur dan pengguna dapat menelusuri grafana seolah-olah dia masuk secara normal.

Keuntungan:

• Tautan kedaluwarsa setelah beberapa waktu + keamanan
• Link menghasilkan hash dengan userid, timestamp dan passkey + security
• Tidak perlu mengetikkan kata sandi + kenyamanan

Konfigurasi nginx saya seperti ini

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

Jangan ragu untuk menghubungi saya jika Anda membutuhkan bantuan untuk ini

Sangat menarik, @Nayar. Namun, kekhawatiran saya dengan solusi ini adalah membutuhkan penyesuaian yang cukup besar. Saya lebih suka sesuatu yang dibangun ke dalam Grafana secara native.

Saya menggunakan stok Grafana. Hanya harus mengkompilasi ulang stok nginx dengan modul diaktifkan dan hanya itu.

Nayar, dapatkah Anda memberi tahu saya apakah solusi yang Anda terapkan dapat bekerja dengan semua versi grafana. Saya baru mengenal Grafana. Di organisasi saya, mereka telah menginstal

Mengeluarkan beberapa ide (dan masalah) tentang bagaimana menyelesaikannya.

Solusi tercepat:

1) tambahkan tipe khusus (bendera) pada kunci API sehingga dapat digunakan di url untuk membuat Anda masuk.

Pro: Kunci API hanya dapat ditambahkan oleh Admin Org.

2) memungkinkan pengguna untuk membuat kunci api & kunci url (varian dari kunci api).

Masalah dengan ini akan menjadi pengaturan oauth di mana jika pengguna dapat membuat kunci api atau kunci url mereka akan dapat menggunakan ini setelah mereka telah menghapus akses dari Grafana (dari sistem oauth). Karena kunci api atau kunci url tidak memerlukan login oauth. Ini akan menjadi masalah besar bagi kunci api pengguna saat kami akhirnya melakukannya. Salah satu solusi yang meringankan mungkin hanya mengizinkan admin org atau admin server grafana untuk membuat kunci api pengguna.

Pikiran @DanCech ? Lanjutkan menggunakan kunci API dengan flag AllowUrlLogin?

Saya tidak berpikir bahwa menggunakan infrastruktur kunci API adalah cara yang tepat, karena akan mempersulit untuk menambahkan lebih banyak fungsi nanti (misalnya, membatasi url ke set dasbor tertentu, memungkinkan non-admin untuk membuat tautan masuk ) dan mungkin membingungkan pengguna. Kami tentunya dapat menggunakan konsep yang sama dan memiliki struktur backend yang serupa, tetapi ini memberi kami lebih banyak opsi jika kami memisahkannya, dan saya pikir ini akan lebih jelas bagi pengguna.

Sejauh pertanyaan login oauth, saya pikir kita harus mencari tahu ruang lingkup apa yang seharusnya ada di sini. Masalah yang sama terjadi pada pengguna oauth jika Anda juga mengaktifkan sandi, karena mereka dapat menyetel sandi lokal dan akan dapat masuk dengan cara itu setelah akun oauth dinonaktifkan. Satu-satunya solusi nyata untuk masalah itu adalah menyimpan tautan itu di akun pengguna dan selalu mengirim pengguna oauth melalui loop pengalihan oauth sebelum menerima login mereka.

Saya juga berpikir kita perlu memberikan nama yang masuk akal untuk fungsi ini. "URL Login" mungkin terlalu luas dan tidak benar-benar meninggalkan ruang untuk digunakan di masa mendatang sebagai cara untuk, misalnya, membagikan tautan langsung yang terbatas pada dasbor tertentu.

@mattttt ingin mengetahui pendapat Anda

karena nanti akan sulit untuk menambahkan lebih banyak fungsi (misalnya, membatasi url ke kumpulan dasbor tertentu, memungkinkan non-admin untuk membuat tautan masuk)

Saya ragu untuk menautkan fitur login ini ke izin atau membatasinya ke dasbor tertentu (selain menautkannya ke peran atau pengguna org). Karena itu akan mengubahnya menjadi fitur berbagi dan menetapkan ekspektasi keamanan yang tidak terpenuhi (karena Anda bisa meminta semua data dari sumber data yang digunakan oleh organisasi).

Satu-satunya solusi nyata untuk masalah itu adalah menyimpan tautan itu di akun pengguna dan selalu mengirim pengguna oauth melalui loop pengalihan oauth sebelum menerima login mereka.

Tidak yakin bagaimana cara memecahkan "pencabutan" login url / token api pengguna. Jika mereka tidak pernah mencoba masuk dengan oauth setelah akses mereka dihapus, Grafana tidak akan pernah tahu.

@hemsush Menurut posting blog ini, itu harus berfungsi mulai dari Grafana 2.0 ke atas: https://grafana.com/blog/2015/12/07/grafana-authproxy-have-it-your-way/

Saya ragu untuk menautkan fitur login ini ke izin atau membatasinya ke dasbor tertentu (selain menautkannya ke peran atau pengguna org). Karena itu akan mengubahnya menjadi fitur berbagi dan menetapkan ekspektasi keamanan yang tidak terpenuhi (karena Anda bisa meminta semua data dari sumber data yang digunakan oleh organisasi).

Itu adalah masalah yang perlu diselesaikan, jadi saran saya adalah bahwa sistem ini dirancang dengan mempertimbangkan kasus penggunaan itu untuk masa depan.

Tidak yakin bagaimana cara memecahkan "pencabutan" login url / token api pengguna. Jika mereka tidak pernah mencoba masuk dengan oauth setelah akses mereka dihapus, Grafana tidak akan pernah tahu.

Menurut saya, tampilan klien saat menggunakan salah satu tautan ini harus serupa dengan pengguna "anonim", di mana mereka tidak masuk secara ajaib sebagai pengguna tertentu melainkan mendapatkan akun Penampil terbatas, yang akan sepenuhnya memisahkan fitur ini dari akun pengguna individu. Itu akan menghindari masalah izin akun pengguna individu, mengurangi tingkat risiko karena tautan tidak dapat digunakan untuk membuat perubahan apa pun, dan memungkinkan pengelolaan terpusat dari semua tautan akses aktif oleh admin org.

Proposal solusi

1) Perkenalkan konsep baru "Viewer URL Token", yang dapat Anda tambahkan / hapus dari halaman API Keys (kita dapat membuat halaman baru untuk ini nanti). Simpan di url_token tabel baru dan mereka akan berfungsi dari perspektif keamanan yang sangat mirip dengan kunci api. Artinya, mereka akan dibuat dan divalidasi dengan cara yang sama seperti kunci api. Namun dapat digunakan untuk memasukkan Anda melalui penggunaan di url dengan "& url-auth-token =".
2) Opsi untuk membatasi token agar hanya berfungsi dengan API render PNG (akan lebih aman karena pengguna dengan token URL tidak akan dapat mengeluarkan kueri apa pun hanya dengan melihat dasbor / panel yang ada)
3) Di masa mendatang kami harus menemukan cara untuk menautkan token ke grup pengguna dan izin dasbor, belum yakin bagaimana cara kerjanya. Saya pikir akan lebih baik untuk membuat pengguna dummy untuk ini yang dapat digunakan memberikan izin pengguna "URL Token" ke dasbor dan sumber data tertentu. Akan sangat benci jika harus memiliki check / join eksplisit untuk token url dalam pemeriksaan izin.

4) Jelaskan bahwa siapa pun yang memiliki token url akan memiliki akses ke semua sumber data organisasi (dan secara teknis dapat mengeluarkan kueri apa pun) (kecuali jika opsi pembatasan untuk merender api digunakan).

pikiran @bergist @DanCech

Opsi untuk membatasi token agar hanya berfungsi dengan API render PNG (akan lebih aman karena pengguna dengan token URL tidak akan dapat mengeluarkan kueri apa pun hanya dengan melihat dasbor / panel yang ada)

Saya tidak berpikir rendering PNG adalah solusi yang baik. Ini akan berkedip dan tidak akan terlihat sebagus Grafana asli.

Saya suka ide untuk menghubungkan token ke pengguna. Cara termudah untuk menghubungkan token / login itu ke grup pengguna dan izin folder dasbor. Tapi saya pikir masuk menggunakan token (tv login / mode tampilan / mode tv) harus memaksa pengguna untuk berada dalam peran Viewer .

Perjelas bahwa siapa pun yang memiliki token url akan memiliki akses ke semua sumber data organisasi (dan secara teknis dapat mengeluarkan kueri apa pun) (kecuali jika opsi pembatasan untuk merender api digunakan).

Menambahkan informasi dan peringatan saat membuat token baru mungkin membantu.

Masalah dengan mengikat token ke pengguna "normal" adalah hal itu menyebabkan berbagai macam masalah saat pengguna diubah atau dihapus. Jika token url dapat menjadi anggota grup dengan cara yang sama seperti pengguna, maka akan ada sejumlah besar fleksibilitas dalam menyiapkan url individual dengan akses ke dasbor tertentu, dll.

Saya tidak yakin itu akan menambah kerumitan pada pemeriksaan izin, Anda akan menggunakan tabel yang berbeda untuk anggota grup tergantung pada apakah pemirsa adalah pengguna biasa atau token url tetapi pemeriksaan akses di seluruh sistem seharusnya tidak perlu berubah.

Sejauh benar-benar menegakkan akses ke sumber data, tidak ada perbedaan di sini dibandingkan dengan pengguna biasa. Solusi akhir untuk masalah itu adalah dengan memindahkan plugin sumber data ke backend dan meminta sumber data pengiriman frontend dengan menentukan nilai dasbor, panel, rentang waktu, dan template var dan memiliki kueri aktual yang dibangun di backend setelah memvalidasi bahwa pengguna memiliki akses dan nilai template var sah.

Masalah dengan mengikat token ke pengguna "normal" adalah hal itu menyebabkan berbagai macam masalah saat pengguna diubah atau dihapus

Masalah bahwa siapa pun yang mengetahui token (meskipun akun dimatikan) dapat melihat dasbor berlaku untuk kedua solusi tersebut. Mencabut akses dapat dilakukan dengan menghapus pengguna atau token.

Saya tidak yakin itu akan menambah kerumitan pada pemeriksaan izin, Anda akan menggunakan tabel yang berbeda untuk anggota grup tergantung pada apakah pemirsa adalah pengguna biasa atau token url tetapi pemeriksaan akses di seluruh sistem seharusnya tidak perlu berubah.

Pemeriksaan akan terlihat sama terlepas dari autentikasi. Jadi itu tidak akan menjadi masalah besar. UI untuk menambahkan token / pengguna ke grup, dasbor, dll. Mungkin berantakan dan hanya akan membantu sejumlah kecil pengguna.

Sejauh benar-benar menegakkan akses ke sumber data, tidak ada perbedaan di sini dibandingkan dengan pengguna biasa. Solusi akhir untuk masalah itu adalah dengan memindahkan plugin sumber data ke backend dan meminta sumber data pengiriman frontend dengan menentukan nilai dasbor, panel, rentang waktu, dan template var dan memiliki kueri aktual yang dibangun di backend setelah memvalidasi bahwa pengguna memiliki akses dan nilai template var sah.

Di sinilah saya pikir kita harus mulai bekerja untuk memberikan pengalaman yang baik untuk berbagi dasbor dengan cara yang aman. Tanpa ini semua solusi terasa seperti pertukaran yang buruk. Saya pikir itu harus dipertahankan minimal sampai akses sumber data diselesaikan.

Saya juga mengalami masalah ini dengan dasbor sematan dalam mode username+passwd+ldap auth ...
Ada pembaruan tentang ini?

Saya sangat tertarik dengan opsi token pemirsa. Jika saya dapat membantu dengan cara apa pun, saya akan dengan senang hati membantu.

Hallo teman-teman!
Saya mencoba membuat tautan terautentikasi untuk dasbor, saya memiliki backend di java dan ujung depan di JSF, saya ingin menempatkan pengguna di layar yang, ketika diklik, akan mengarahkan pengguna langsung ke dasbornya, saya Saya tidak memahami konsep dengan baik, seseorang. Apakah Anda punya contoh bagaimana saya bisa melakukan ini?

Hai,

Hanya ide, mencoba membantu. Mengapa tidak menambahkan API pengguna baru, menggunakan Auth Dasar seperti ini
? curl https://admin:admin<strong i="7">@localhost</strong>:3000/api/user/cookie
dan dapatkan hasil JSON seperti
{"user_name":"admin","cookie_name":"grafana_,session":"a0b1c2d3e4","remember":"da27ef425e9e0d"}

Ini akan diamankan melalui https, dan saya dapat menggunakan informasi ini untuk memalsukan cookie dan memberi otorisasi kepada pengguna untuk melihat grafik indah mereka.

Saya melihat dengan cermat kode Anda dan saya pikir (dengan sangat hormat ) itu tidak akan terlalu sulit.
Sebagai gantinya mengirim:
user.Rands+user.Password, setting.CookieRememberName, user.Login, days, setting.AppSubUrl+"/"

ke fungsi SetSuperSecureCookie, Anda dapat membuat fungsi baru, terinspirasi dari SetSuperSecureCookie, seperti ini:

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

Jawabannya bisa rumit dan kirim seperti di salah satu fungsi Anda seperti:

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

Saya tahu bahwa Anda bukan seorang pesulap dan coding itu tidak memainkan Lego tetapi ini adalah fungsi yang sangat penting bagi saya. Saya akan mencoba membantu.

Selama GrafanaCon @DanCech menyebutkan ide membuat daftar putar publik dengan kunci GUID. Mirip dengan cara kerja snapshot hari ini. Berbagi / menyimpan kunci semacam itu bisa dianggap seaman token API, tetapi terbatas untuk melihat daftar putar. Daftar putar dapat dikaitkan dengan pembuat / pembaru untuk memvalidasi izin tampilan dasbor.

URL mungkin terlihat seperti https://play.grafana.com/playlists/public/<hash>

Satu hal yang saya suka tentang solusi ini adalah ia membatasi fungsionalitas hanya untuk melihat daftar putar (dasbor) yang menurut saya merupakan kasus penggunaan terbesar untuk token seperti ini.

Tetapi kita masih perlu memasukkan pengguna entah bagaimana karena dasbor acl / annotations dll akan memerlukan otentikasi sisi server.

Saya kira kita bisa memikirkan lebih banyak tentang solusi semacam ini. Saya terutama ingin melakukan braindump percakapan kami dari GrafanaCon :)

Terima kasih @bergquist , pasti bagus untuk menuliskan barang ini selagi masih segar!

Evolusi berikutnya dari pemikiran itu adalah menambahkan konsep "layar" untuk memisahkan hal-hal lebih jauh, sehingga pengguna dapat membuat "layar" yang kemudian memiliki url hash rahasia yang akan dihubungkan dengannya. Ini akan melayani tujuan yang sama tetapi akan memungkinkan pengelolaan layar dari dalam Grafana, sehingga pengguna dapat mengontrol daftar putar mana yang ditampilkan, dll.

Tujuan akhirnya di sini adalah untuk mendukung mekanisme bagi pengguna untuk dengan mudah membuat kartu sd atau gambar usb yang dapat digunakan untuk mem-boot raspberry pi khusus dan menampilkan daftar putar yang diinginkan dengan aman dari Grafana tanpa harus melewati lingkaran otentikasi.

Tujuan akhirnya di sini adalah untuk mendukung mekanisme bagi pengguna untuk dengan mudah membuat kartu sd atau gambar usb yang dapat digunakan untuk mem-boot raspberry pi khusus dan menampilkan daftar putar yang diinginkan dengan aman dari Grafana tanpa harus melewati lingkaran otentikasi.

@DanCech Ini adalah kasus penggunaan yang saya cari.

Evolusi berikutnya dari pemikiran itu adalah menambahkan konsep "layar" untuk memisahkan hal-hal lebih jauh, sehingga pengguna dapat membuat "layar" yang kemudian memiliki url hash rahasia yang akan dihubungkan dengannya.

@DanCech Kedengarannya sempurna!

Halo semuanya,

Ini sepertinya agak jauh dari edisi asli yang dibuka oleh Germanaz0

Sebaiknya Anda memiliki login otomatis yang meneruskan token pengguna melalui url, ini bisa menjadi solusi parsial untuk menanamkan iframe di situs.

dan dijelaskan oleh adamlwgriffiths

Kami memiliki otentikasi dan dasbor kami sendiri, kami ingin memberikan kemampuan untuk meneruskan pengguna dari dasbor kami ke Grafana - dengan cara yang mirip dengan bagaimana Heroku beroperasi dengan New Relic dan layanan lain tanpa kata sandi. Menyediakan metode autentikasi token url + adalah par-for-the-course.

Germanaz0 mengembangkan skrip js

Sekarang Kami menyelesaikan masalah ini dengan sedikit peretasan, menambahkan javascript yang masuk otomatis ke grafana, tetapi merupakan solusi sementara

Saya mengerti bahwa mereka membutuhkan login otomatis untuk menggunakan grafik grafana di situs mereka sendiri. Ini yang saya butuhkan juga tanpa menggunakan playlist ... Mungkinkah?

Jika Anda hanya ingin memasukkan pengguna secara otomatis, cara terbaik adalah menggunakan http://docs.grafana.org/tutorials/authproxy/

@DanCech Masalahnya adalah yang memungkinkan semua pengguna untuk masuk secara otomatis. Kami ingin cara untuk hanya secara otomatis masuk pengguna yang memiliki URL tertentu.

@gzzo yang bergantung pada desain proxy

Saya mencari fitur ini di Grafana juga.
Saya pikir penyematan Microsoft Power BI adalah solusi yang baik. Lihat tautan di bawah.
https://github.com/Microsoft/PowerBI-JavaScript/wiki/Embedding-Basics
https://microsoft.github.io/PowerBI-JavaScript/demo/v2-demo/index.html

Saya pikir solusi PowerBi di atas didasarkan pada OAuth2.
Sisi server Grafana harus mendukung OAuth2 dan mengaktifkan CORS.

@Nayar Saya baru mengenal Grafana. Apa maksud Anda saham Grafana dan stok Nginx yang Anda komentari pada 14 Sep 2017? Apakah Anda memiliki tautan keduanya?

Saya rasa menunggu dengan sabar untuk rilis 5.4.

Berhasil melakukan ini dengan sukses menggunakan Grafana auth.proxy dan Nginx ngx_http_secure_link_module

Tautan yang saya gunakan dalam format http://grafana/?user=nayar&md5=2tutcea9nfdsfdsfdsw&expires=1505386800

Setelah pengguna mengkliknya, cookie sesi diatur dan pengguna dapat menelusuri grafana seolah-olah dia masuk secara normal.

Keuntungan:

• Tautan kedaluwarsa setelah beberapa waktu + keamanan
• Link menghasilkan hash dengan userid, timestamp dan passkey + security
• Tidak perlu mengetikkan kata sandi + kenyamanan

Konfigurasi nginx saya seperti ini

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

Jangan ragu untuk menghubungi saya jika Anda membutuhkan bantuan untuk ini

Hai Nayar,
Saya mencoba melakukan integrasi grafana dengan SaaS.
Syaratnya setelah user login di aplikasi web saya lalu klik link 'grafana' di halaman saya, maka akan dialihkan ke dashboard grafana tanpa memasukkan username dan password.

Komentar Anda tampaknya memenuhi kebutuhan saya. Tetapi saya masih belum jelas tentang proses otentikasi.
Ketika proxy_pass ke grafana, cara memverifikasi pengguna diautentikasi oleh aplikasi saya sendiri.

Aplikasi web saya melalui X-XSRF-TOKEN untuk memeriksa otoritas pengguna.

Saya baru mengenal konfigurasi server. Saya sangat menghargai bantuan Anda.

@torkelo / @bergquist Sekadar begitulah cara kami mengatasi masalah ini di Screenly . Ini live dan bekerja dengan baik! Terima kasih atas kerja kerasnya, guys!

@torkelo / @bergquist Sekadar begitulah cara kami mengatasi masalah ini di Screenly . Ini live dan bekerja dengan baik! Terima kasih atas kerja kerasnya, guys!

@vpetersson Saya tidak menggunakan screenly tetapi saya ingin tahu bagaimana Anda dapat menerapkan ini. Saya memahami cara membuat token API. Apakah Anda masih menggunakan iframe di URL? Bagaimana Anda menambahkan token Authentication ke dalam header permintaan?

@GimpMaster Kami hanya menggunakan header auth, jadi tidak perlu iframe. Sejak kami menulis pemutar / browser, kami dapat memasukkan header autentikasi pada pemuatan halaman.

Saya baru saja membuat mode Kios saya berfungsi dengan menggunakan pendekatan dari Screenly yang ditautkan oleh @GimpMaster . Saya telah menggunakan Chrome Extension ModHeader tempat saya menambahkan header Otorisasi dengan Kunci API Bearer. Tetapi karena Ekstensi membutuhkan waktu untuk memuat 10-an tidur dari Menyiapkan kios di raspberry pi membuat triknya. Solusi ini juga akan berfungsi untuk iframe tetapi harus dikonfigurasi pada setiap klien.

@Nayar Saya berhasil mengadaptasi konfigurasi ngnix yang Anda sarankan untuk menggunakan akses _unsecure_. Artinya, ini hanya mengambil nama pengguna dari string kueri dan meletakkannya di X-WEBAUTH-USER. Ini kemudian mendapatkan id sesi grafana dan kami pergi. Terima kasih!

Saya tidak bisa mendapatkan metode md5 untuk bekerja. Saya tidak jelas tentang apa sebenarnya yang saya perlukan untuk membuat sidik jari md5. Bisakah Anda menjelaskannya? Apakah ada trik dalam membuat md5?

Apakah mungkin menerapkan solusi apapun untuk login dengan token / cookie / header / ... di grafana 6. *?

Saya tidak dapat melakukannya dengan panel tautan sederhana di PHP kosong

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

Saya menguji mengubah konfigurasi nginx saya menjadi ini dan menyetel "? User = myUser" di url, tetapi hanya mendapatkan tanggapan yang tidak sah

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 Segala sesuatu di sekitar proxy auth dijelaskan dalam dokumentasi . Belum pernah melihat solusi sebelumnya di mana Anda memanggil proxy dengan "X-WEBAUTH-USER - biasanya Anda mengotentikasi di proxy Anda yang pada gilirannya mengisi dan memberikan X-WEBAUTH-USER ke grafana.

@marefr terima kasih atas jawabannya.
Saya membaca dokumentasi dan API saya berfungsi, tetapi saya memerlukan autentikasi pengguna dinamis (bukan izin yang sama untuk semua pengguna halaman)

Solusi @Nayar ini menyertakan X-WEBAUTH-USER di header tanpa hardcode, tetapi saya tidak dapat membuatnya berfungsi

Saya pikir ada yang rusak di 6.0 atau 6.1.
Saya memperbarui instalasi yang berfungsi penuh menggunakan proxy auth di Apache2 ke 6.1 kemarin (dari 5.3) dan saya mendapatkan layar yang persis sama dengan @ mr0bles

Harap dicatat bahwa Grafana tampaknya memahami tajuk proxy: Awalnya ia memasukkan pengguna, tetapi permintaan berikutnya mendapatkan respons 401.

@Bitblade kami belum menerima laporan lain yang serupa dengan Anda. Silakan buka laporan bug baru karena masalah ini berkaitan dengan permintaan fitur.

Berhasil melakukan ini dengan sukses menggunakan Grafana auth.proxy dan Nginx ngx_http_secure_link_module

Tautan yang saya gunakan dalam format http://grafana/?user=nayar&md5=2tutcea9nfdsfdsfdsw&expires=1505386800

Setelah pengguna mengkliknya, cookie sesi diatur dan pengguna dapat menelusuri grafana seolah-olah dia masuk secara normal.

Keuntungan:

• Tautan kedaluwarsa setelah beberapa waktu + keamanan
• Link menghasilkan hash dengan userid, timestamp dan passkey + security
• Tidak perlu mengetikkan kata sandi + kenyamanan

Konfigurasi nginx saya seperti ini

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

Jangan ragu untuk menghubungi saya jika Anda membutuhkan bantuan untuk ini

Solusi ini tidak berhasil untuk saya. Karena menurut saya setiap permintaan harus berisi header X-WEBAUTH-USER yang valid. Ini tidak berfungsi jika Anda mengisi tajuk pada permintaan pertama, mendapatkan cookie, dan mengikutinya.

Saya mengakhiri dengan solusi berikutnya:

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

Jadi solusinya menggunakan modul nginx auth_request. Aplikasi saya bertanggung jawab untuk kontrol akses (/ gauth request) dan mengembalikan nama pengguna di header respon User .

Hai, sementara itu, Anda dapat menggunakan solusi saya yang dijelaskan di sini: https://github.com/guysoft/FullPageOS/issues/175

Berikut adalah solusi saya menggunakan Autentikasi OAuth Generik Grafana dan PHP: https://github.com/nbayramberdiyev/grafana-generic-oauth

Semoga ini bisa membantu Anda.

hanya ingin berkomentar bagaimana saya menyelesaikan ini menggunakan http basic auth https://github.com/grafana/grafana/issues/13706#issuecomment -540958284

Sebaiknya Anda memiliki login otomatis yang meneruskan token pengguna melalui url, ini bisa menjadi solusi parsial untuk menanamkan iframe di situs.

@rca dapatkah Anda memberikan contoh dengan kode Anda? Saya menyalin kode Anda dan embed.js, tetapi tidak berhasil.

Jika Anda menggunakan oauth, ada cara untuk melakukan grafana tertanam tanpa login ganda

1. Setup grafana dengan satu penyedia oauth dan tidak ada mekanisme login lainnya
2. Setel GF_AUTH_OAUTH_AUTO_LOGIN menjadi true
3. Host grafana di subpath dan gunakan reverse proxy sehingga grafana disajikan di host yang sama dengan aplikasi utama Anda
4. Hubungkan aplikasi dan grafana utama Anda ke penyedia oauth yang sama (ke penyedia oauth, "aplikasi" tersebut akan menjadi "aplikasi" yang sama)
5. Sematkan grafana
6. Saat iframe dimuat, grafana akan mencoba masuk secara otomatis dengan oauth (yang seharusnya berhasil karena berada di domain yang sama dengan aplikasi utama Anda, sehingga berbagi cookie autentikasi yang sama)

EDIT: Anda mungkin perlu menyetel security.cookie_samesite=none dalam grafana agar ini berfungsi dengan benar di beberapa browser (Ini karena di iframe, pengalihan ke penyedia oauth (domain berbeda) sedang terjadi dan kemudian pengalihan kembali ke Anda grafana domain. Saat ini, firefox tidak akan mengizinkan cookie situs web yang disetel ke lax tetap ada dengan cara ini. https://bugzilla.mozilla.org/show_bug.cgi?id=1454027 yang berarti grafana kehilangan oauth_state -nya none )

@seanlaff Saya mencoba solusi Anda dengan AWS Cognito tetapi mengembalikan tajuk yang tidak memungkinkan untuk dimasukkan ke dalam iframe (X-Frame-Options: deny), ada tip tentang ini?

Berhasil melakukan ini dengan sukses menggunakan Grafana auth.proxy dan Nginx ngx_http_secure_link_module
Tautan yang saya gunakan dalam format http://grafana/?user=nayar&md5=2tutcea9nfdsfdsfdsw&expires=1505386800
Setelah pengguna mengkliknya, cookie sesi diatur dan pengguna dapat menelusuri grafana seolah-olah dia masuk secara normal.
Keuntungan:

• Tautan kedaluwarsa setelah beberapa waktu + keamanan
• Link menghasilkan hash dengan userid, timestamp dan passkey + security
• Tidak perlu mengetikkan kata sandi + kenyamanan

Konfigurasi nginx saya seperti ini

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

Jangan ragu untuk menghubungi saya jika Anda membutuhkan bantuan untuk ini

Solusi ini tidak berhasil untuk saya. Karena menurut saya setiap permintaan harus berisi header X-WEBAUTH-USER yang valid. Ini tidak berfungsi jika Anda mengisi tajuk pada permintaan pertama, mendapatkan cookie, dan mengikutinya.

Saya mengakhiri dengan solusi berikutnya:

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

Jadi solusinya menggunakan modul nginx auth_request. Aplikasi saya bertanggung jawab untuk kontrol akses (/ gauth request) dan mengembalikan nama pengguna di header respon User .

bagaimana cara menggunakan iframe?
saya baru mengenal Grafana dan NGINX
jadi tolong bagikan detail maksimum sekarang untuk memodifikasi

bagaimana cara menggunakan iframe?

@pgsekaran solusi ini bukan untuk iframe, tetapi untuk mendapatkan grafana UI tanpa login grafana eksplisit untuk pengguna aplikasi Anda. Aplikasi dalam hal ini adalah proxy yang mengetahui cara login ke grafana.

Hai,
Terima kasih atas balasan cepatnya. apakah Anda memiliki tautan dengan referensi untuk menambahkan Grafana dengan aplikasi lain menggunakan iframe.i menambahkan Grafana ke aplikasi saya tetapi saya tidak dapat mengatur manajemen penggunaan.
Salam Guna
Pada hari Selasa, 23 Juni 2020, 09:54:57 GMT + 5: 30, Konstantin Kolotyuk [email protected] menulis:

bagaimana cara menggunakan iframe?

@pgsekaran solusi ini bukan untuk iframe, tetapi untuk mendapatkan grafana UI tanpa login grafana eksplisit untuk pengguna aplikasi Anda. Aplikasi dalam hal ini adalah proxy yang mengetahui cara login ke grafana.

-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub, atau berhenti berlangganan.

Masih belum diterapkan? Serius, ini bagus untuk dimiliki.

@pgsekaran saya punya solusi untuk iframe, yang tidak terlalu aman karena menggunakan login berbasis nama pengguna dan bergantung pada nama pengguna yang tidak mudah ditebak. pada dasarnya, nama pengguna adalah token.
Saya sudah menulis tentang hal itu di sini, tidak dengan sangat rinci tetapi eouhg untuk membantu Anda memulai
https://blog.yadamiel.com/tutorials/embed-and-authenticate-grafana-in-a-iframe

@pgsekaran saya punya solusi untuk iframe, yang tidak terlalu aman karena menggunakan login berbasis nama pengguna dan bergantung pada nama pengguna yang tidak mudah ditebak. pada dasarnya, nama pengguna adalah token.
Saya sudah menulis tentang hal itu di sini, tidak dengan sangat rinci tetapi eouhg untuk membantu Anda memulai
https://blog.yadamiel.com/tutorials/embed-and-authenticate-grafana-in-a-iframe

Hai,

Saya perlu mengatur dengan NGINX dan iframe dengan login otomatis

Masalah sebenarnya dijelaskan di https://github.com/grafana/grafana/issues/16319#issuecomment -483272921: ID sesi tidak dikembalikan dengan respons pertama yang berisi halaman "kerangka". Permintaan selanjutnya tidak berisi token masuk otomatis, sehingga gagal.

Kami menggunakan kromium dalam mode kios untuk menampilkan dasbor Grafana di berbagai tempat. Karena instance Grafana yang sama juga tersedia untuk pengguna, kami menggunakan auth.generic_oauth ( auth.basic hingga 5.x) untuk masuk manusia dan auth.proxy untuk masuk ke mesin mode kios:

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

Seperti yang telah dicatat orang lain, ini tidak berfungsi begitu saja. Yang akan berhasil adalah pertama-tama memanggil url http://prometheus.localdomain/grafana/login?autologin=lHOrdypkhxzNYb2lRaIjbNPlOCZw9gWE (yang sekarang menetapkan cookie grafana_session ) dan kemudian mengarahkan ulang ke dasbor yang sebenarnya. Tapi ... mode kios 🤷 dan iframes 🤦‍♂️

Solusi kerja terakhir kami adalah menggabungkan parameter kueri autologin dengan cookie khusus. Ya, Anda tidak dapat keluar melalui GUI karena cookie khusus tidak dihapus, tetapi karena mekanisme ini hanya digunakan pada mesin mode kios, hal ini tidak diperlukan.

Jadi inilah konfigurasi nginx untuk Grafana Server:

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

server {
    listen 80;

    server_name server.localdomain;

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

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

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

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

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

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