Menerapkan keamanan tingkat baris untuk konten Looker tersemat

Ditulis oleh Christopher Seymour, Sr. Data Analyst dan Dean Hicks, Developer Relations Engineer

Pengantar

Fitur penyematan Looker adalah salah satu fitur produk Looker yang paling canggih dan berharga. Jika membaca panduan ini, Anda mungkin sudah menyematkan konten Looker ke dalam aplikasi atau Anda ingin melakukannya dalam waktu dekat.

Panduan ini dimaksudkan untuk membantu Anda lebih memahami desain fitur penyematan Looker, sehingga Anda dapat membuat aplikasi yang andal dan aman untuk mengirimkan data kepada pengguna. Pembahasan ini bersifat agak panjang — jadi perlu diingat bahwa panduan ini tidak dimaksudkan sebagai perbaikan cepat untuk masalah yang mudah, melainkan sebagai elemen penyusun untuk membantu Anda mengelola seluruh kasus penggunaan sematan Looker dengan lebih baik.

Ringkasan kasus penggunaan

Panduan ini menjelaskan kasus penggunaan umum saat perusahaan Anda menyematkan konten Looker dalam produk.

Untuk kasus penggunaan penyematan yang ditandatangani ini, asumsikan bahwa Anda adalah Admin instance Looker Anda. Anda bekerja sama dengan dua jenis pengguna sematan: pelanggan (atau "pengguna merek"), yang seharusnya hanya dapat mengakses data yang berkaitan dengan perusahaan mereka, dan pemilik akun, yang akan dapat mengakses data untuk beberapa pelanggan tertentu. Anda memiliki dasbor dengan beberapa ubin yang Anda tampilkan kepada setiap pelanggan yang menggunakan produk Anda, tetapi Anda perlu dasbor secara otomatis difilter untuk setiap pelanggan sehingga dasbor hanya akan menampilkan data yang khusus untuk pelanggan tersebut. Contoh dalam dokumen ini menggunakan dua perusahaan fiktif — Hooli dan Pied Piper.

Anda memiliki tabel bernama produk, yang menampilkan beberapa metrik produk untuk berbagai merek. Setiap merek sesuai dengan pengguna sematan yang berbeda (dengan external_user_id yang berbeda) dalam aplikasi penyematan yang ditandatangani. Karena setiap pengguna sematan hanya dapat melihat data merek mereka sendiri, Anda memiliki Eksplorasi sederhana yang menggunakan filter akses pada atribut pengguna merek:

explore: products {
  access_filter: {
    field: products.brand
    user_attribute: brand
  }
}

Anda memiliki dasbor sederhana yang didasarkan pada Jelajahi ini dan yang memiliki dua kartu: Satu menampilkan nama merek, dan yang lainnya menampilkan jumlah produk untuk merek tersebut.

Anda menggunakan endpoint create_sso_embed_url untuk membuat URL sematan dari dasbor ini bagi setiap pengguna sematan. Contoh ini menggunakan dua merek: Pied Piper dan Hooli. Berikut adalah isi permintaan yang Anda gunakan dalam panggilan create_sso_embed_url untuk Pied Piper, dengan external_user_id pied_piper:

{
  "target_url": "https://mylookerinstance.cloud.looker.com/embed/dashboards/17",
  "session_length": 300,
  "force_logout_login": true,
  "external_user_id": "pied_piper",
  "first_name": "PiedPiper",
  "last_name": "User",
  "permissions": ["access_data","see_user_dashboards"],
  "models": ["thelook"],
  "user_attributes": {"brand":"Pied Piper"}
}

URL yang Anda buat untuk Pied Piper menampilkan dasbor dengan cara ini:

Berikut adalah isi permintaan yang digunakan dalam panggilan create_sso_embed_url untuk Hooli, dengan external_user_id hooli:

{
  "target_url": "https://mylookerinstance.cloud.looker.com/embed/dashboards/17",
  "session_length": 300,
  "force_logout_login": true,
  "external_user_id": "hooli",
  "first_name": "Hooli",
  "last_name": "User",
  "permissions": ["access_data","see_user_dashboards"],
  "models": ["thelook"],
  "user_attributes": {"brand":"Hooli"}
}

URL yang dihasilkan untuk Hooli akan menampilkan dasbor dengan cara ini:

Voilà! Dasbor akan difilter sesuai dengan nilai setiap pengguna yang disematkan untuk atribut pengguna merek.

Menggali lebih dalam

Keren sekali. Namun, bagaimana jika saya ingin memberi satu pemilik akun akses ke beberapa brand? Bagaimana cara memastikan data saya hanya dilihat oleh pengguna yang relevan?

Kabar baik! Fitur sematan yang ditandatangani Looker telah dirancang untuk mendukung developer dalam menciptakan pengalaman data yang andal dan sesuai kebutuhan pengguna, sekaligus memastikan bahwa tata kelola data yang ditentukan oleh model data dan kebijakan akses konten Anda tetap dipertahankan.

Memastikan bahwa tata kelola data bersifat ketat adalah hal yang sangat penting untuk memberikan pengalaman data yang andal. Baca terus untuk menjelajahi beberapa konsep dan praktik terbaik yang dapat Anda gunakan untuk mendesain pengalaman yang paling sesuai untuk Anda. Pertama adalah ikhtisar singkat tentang cara kerjanya.

Dasar-dasar penyematan yang ditandatangani Looker

Penting untuk diingat bahwa autentikasi dan pengelolaan pengguna Looker dalam konteks sematan pada dasarnya berfungsi dengan cara yang sama seperti dalam konteks non-penyematan dan pada dasarnya dengan cara yang sama seperti kebanyakan aplikasi web lainnya.

Hal ini dapat membingungkan dalam konteks penyematan yang ditandatangani Looker, karena langkah autentikasi yang ditandatangani, setelan pengguna, dan dasbor itu sendiri digabungkan menjadi satu URL yang panjang dan kompleks. Namun, URL tersebut digunakan untuk menetapkan sesi, yang masih berlaku bahkan setelah URL dipersingkat. Dengan mengingat konsep ini, Anda akan mendapatkan banyak manfaat dalam membangun pengalaman data yang luar biasa.

Struktur URL sematan bertanda tangan

Berikut adalah salah satu URL autentikasi sematan yang ditandatangani yang dihasilkan oleh panggilan create_sso_embed_url dengan isi permintaan untuk Pied Piper:

https://mylookerinstance.cloud.looker.com/login/embed/%2Fembed%2Fdashboards%2F17?permissions=%5B%22access_data%22%2C%22see_user_dashboards%22%5D&models=%5B%22thelook%22%5D&signature=iG6vcKBgnA50jaL2iShFeQHwFPN7wvTx7Rz6r%2FtFuvE%3D&nonce=%22967729518a7dbb8a178f1c03a3511dd1%22&time=1696013242&session_length=300&external_user_id=%22pied_piper%22&access_filters=%7B%7D&first_name=%22Pied%22&last_name=%22Piper%22&user_attributes=%7B%22brand%22%3A%22Pied+Piper%22%7D&force_logout_login=true

Berikut adalah URL yang sama yang didekode dan dibagi menjadi beberapa baris:

https://mylookerinstance.cloud.looker.com/login/embed/
/embed/dashboards/17
?permissions=["access_data","see_user_dashboards"]
&models=["thelook"]
&signature=iG6vcKBgnA50jaL2iShFeQHwFPN7wvTx7Rz6r/tFuvE=
&nonce="967729518a7dbb8a178f1c03a3511dd1"
&time=1696013242
&session_length=300
&external_user_id="pied_piper"
&access_filters={}
&first_name="PiedPiper"
&last_name="User"
&user_attributes={"brand":"Pied Piper"}
&force_logout_login=true

Ketika Anda mengakses URL ini, beberapa hal terjadi:

  1. Looker mencari akun pengguna yang ada dengan external_user_id = pied_piper. Jika tidak ada, Looker akan membuat akun pengguna baru dengan external_user_id tersebut.

  2. Detail akun pengguna yang ada, termasuk izin, model, grup (jika ditentukan), nilai atribut pengguna (jika ditentukan), akan ditimpa dengan detail akun yang ditentukan dalam URL.

  3. Looker mengautentikasi pengguna dan membuat sesi untuk pengguna tersebut dengan menyimpan cookie sesi di browser.

  4. Looker kemudian mengalihkan ke URL target, atau URL alihan, yang ditentukan dalam panggilan create_sso_embed_url:

    https://mylookerinstance.cloud.looker.com/embed/dashboards/17.

    Anda dapat melihat URL alihan ini sebagai URL relatif yang dienkode di URL sematan asli yang ditandatangani:

    %2Fembed%2Fdashboards%2F17

Meskipun langkah 1-3 terjadi di latar belakang secara otomatis, dan semua yang dilihat pengguna akhir adalah hasil akhir (dasbor itu sendiri), langkah-langkah ini pada dasarnya sama dengan langkah-langkah yang dilakukan oleh pengguna Looker non-sematan biasa untuk melakukan autentikasi. Misalnya Anda ingin pengguna login dengan kredensial pengguna dan sandi. Prosesnya akan terlihat seperti ini:

  1. Anda (Admin Looker) membuka panel Admin - Pengguna dan menggunakan kotak penelusuran untuk memeriksa apakah sudah ada akun pengguna untuk pengguna ini. Jika belum, Anda perlu membuat akun pengguna baru.

  2. Anda (Admin Looker) mengklik Edit di samping pengguna dari panel Admin - Pengguna dan memberikan izin, model, grup, nilai atribut pengguna, dan nilai lainnya kepada pengguna.

  3. Pengguna membuka halaman login https://mylookerinstance.cloud.looker.com/login dan memasukkan nama pengguna serta sandinya. Looker mengautentikasi pengguna dan membuat sesi untuk pengguna tersebut dengan menyimpan cookie sesi di browser.

  4. Looker kemudian mengalihkan ke halaman landing (biasanya https://mylookerinstance.cloud.looker.com/browse).

Perhatikan bahwa cookie sesi akan diterapkan ke setiap tab dalam jendela browser. Jika pengguna memulai pada https://mylookerinstance.cloud.looker.com/browse, membuka tab browser baru, dan membuka halaman yang dapat diakses oleh izin mereka, halaman tersebut akan dimuat seperti yang diharapkan menggunakan cookie sesi yang sudah ditetapkan di tab browser asli.

Hal yang sama berlaku untuk pengguna sematan. Pengguna sematan sedikit lebih terbatas pada halaman yang dapat mereka akses di UI—mereka hanya dapat mengakses URL Tampilan, dasbor, dan Eksplorasi dengan awalan /embed. Namun, mereka tetap bebas membuka dasbor mana pun secara manual yang dapat diakses oleh detail akun pengguna mereka. Misalnya URL sematan asli yang ditandatangani mengalihkan Anda ke https://mylookerinstance.cloud.looker.com/embed/dashboards/17 di satu tab browser. Selanjutnya, Anda akan membuka tab browser baru dan memuat dasbor sematan berbeda yang berada di folder yang sama (sehingga memiliki batasan akses yang sama): https://mylookerinstance.cloud.looker.com/embed/dashboards/19.

Meskipun URL alihan yang ditentukan dalam URL sematan asli yang ditandatangani adalah untuk dasbor 17, Anda dapat melihat bahwa dasbor 19 dimuat seperti yang diharapkan jika Anda memasukkan URL secara manual di tab browser. Perlu diketahui bahwa URL sematan lain yang ditandatangani tidak diperlukan untuk memuat dasbor lain.

Wawasan utama di sini adalah semua detail akun pengguna yang dibuat di URL (izin, atribut pengguna, dll.) diterapkan ke seluruh sesi pengguna, tidak hanya ke dasbor tertentu yang ditentukan dalam URL asli yang ditandatangani. Dengan kata lain, sesuai dengan namanya, atribut pengguna adalah fitur pengguna, bukan fitur dasbor, dan harus digunakan untuk menentukan tingkat akses pengguna tertentu di seluruh aplikasi, bukan hanya di satu tab tertentu.

Kasus penggunaan pemilik akun

Seperti halnya solusi yang dapat disesuaikan, ada pendekatan tertentu yang harus Anda hindari. Dengan mengingat hal itu, pertimbangkan bahwa Anda juga memiliki pemilik akun yang mungkin memiliki atau mengelola beberapa merek. Dalam contoh ini, pemilik akun mengelola brand Pied Piper dan Hooli. Oleh karena itu, aplikasi Anda membuat URL untuk kedua external_user_ids menggunakan input yang sama dalam panggilan create_sso_embed_url yang ditampilkan sebelumnya, dan membuat tab baru di aplikasi untuk memuat setiap dasbor yang ingin diakses oleh pemilik akun. Kami sering melihat developer menerapkan solusi seperti ini, yang mengakibatkan alur kerja yang salah bagi pengguna:

  1. Buka tab dasbor Pied Piper.
  2. Buka tab dasbor Hooli.
  3. Kembali ke tab dasbor Pied Piper.
  4. Tekan tombol Reload pada dasbor Pied Piper.

...dasbor Pied Piper menampilkan data Hooli.

Anda dapat mencoba pendekatan yang serupa, tetapi gunakan test_user external_user_id yang sama untuk kedua panggilan create_sso_embed_url:

{
  "target_url": "https://mylookerinstance.cloud.looker.com/embed/dashboards/17",
  "session_length": 300,
  "force_logout_login": true,
  "external_user_id": "test_user",
  "first_name": "Test",
  "last_name": "User",
  "permissions": ["access_data","see_user_dashboards"],
  "models": ["thelook"],
  "user_attributes": {"brand":"Pied Piper"}
}

{
  "target_url": "https://mylookerinstance.cloud.looker.com/embed/dashboards/17",
  "session_length": 300,
  "force_logout_login": true,
  "external_user_id": "test_user",
  "first_name": "Test",
  "last_name": "User",
  "permissions": ["access_data","see_user_dashboards"],
  "models": ["thelook"],
  "user_attributes": {"brand":"Hooli"}
}

Namun, perilakunya sama persis—setelah tab dimuat ulang dengan dasbor Pied Piper, tab tersebut akan menampilkan data untuk Hooli.

Apa yang terjadi? Bagaimana cara memastikan setiap dasbor merek hanya menampilkan data untuk merek tersebut?

Pendekatan yang sama dari perspektif non-sematan

Seperti yang telah dibahas di bagian sebelumnya, sesi pengguna sematan yang ditandatangani bekerja pada dasarnya dengan cara yang sama seperti sesi pengguna Looker reguler yang tidak disematkan, sehingga akan bermanfaat untuk membingkai ulang pendekatan bermasalah yang dijelaskan sebelumnya dalam konteks sesi pengguna Looker yang tidak disematkan dan rutin serta menguraikan langkah-langkah tersebut untuk membantu memahami cara menerapkan solusi ini dengan cara yang lebih andal. Seperti inilah alur kerja tersebut jika Anda memberikan petunjuk kepada pengguna BI standar yang memiliki akses ke UI Looker:

  1. Anda dapat membuat dua akun pengguna yang berbeda di halaman Admin - Pengguna.
    1. Di halaman edit untuk akun pengguna pertama, tetapkan nilai atribut pengguna merek ke pied_piper.
    2. Pada halaman edit untuk akun pengguna kedua, tetapkan nilai atribut pengguna brand ke hooli.
  2. Anda mengirim email pembuatan akun untuk kedua akun pengguna kepada pemilik akun.
  3. Pemilik akun menyiapkan kredensial email dan sandi terpisah untuk setiap akun.
  4. Anda memberikan tautan ke dasbor kepada pemilik akun. (https://mylookerinstance.cloud.looker.com/dashboards/17) dan memberi tahu mereka bahwa, untuk berganti dasbor antar-merek, mereka harus kembali ke halaman login di tab lain dan memasukkan kredensial email dan sandi untuk akun pengguna mereka yang lain, lalu memuat dasbor lagi di tab tersebut.

Pemilik akun mengikuti petunjuk. Namun, setelah memasukkan nama pengguna dan sandi akun pengguna Hooli di tab browser kedua, lalu kembali ke tab pertama tempat dasbor Pied Piper dimuat, pemilik akun menekan tombol Reload. Yang mengejutkan pemilik akun, dasbor menampilkan data Hooli. Jangan sampai hal ini mengejutkan, karena skenario yang sama baru saja terjadi dalam konteks sematan.

Anda dapat dengan cepat menguraikan implementasi terakhir (menggunakan test_user external_user_id yang sama dengan kumpulan atribut pengguna yang berbeda) dengan cara yang sama. UI yang setara dengan alur kerja tersebut akan terlihat seperti ini:

  1. Anda membuat satu akun pengguna untuk pemilik akun.
  2. Anda menetapkan pied_piper sebagai nilai atribut brand untuk akun pengguna tersebut.
  3. Anda memberi tahu pemilik akun bahwa untuk mengalihkan dasbor dari Pied Piper ke Hooli, mereka harus menghubungi Anda sehingga Anda dapat membuka halaman edit untuk akun pengguna tersebut dan mengubah nilai atribut brand miliknya dari pied_piper menjadi hooli di tengah sesi.
  4. Setelah Anda mengedit atribut penggunanya, mereka dapat memuat kembali dasbor di tab baru untuk melihat data Hooli.

Jadi sekarang Anda mungkin berpikir:

Tunggu...sepertinya ini merepotkan! Apakah tidak ada cara untuk memberi mereka satu akun pengguna dan mengizinkan mereka memfilter data di dasbor secara terpisah untuk setiap merek?

Tentu saja ada! Yang dapat diilustrasikan oleh skenario ini adalah prinsip yang sudah sederhana dalam konteks non-sematan, tetapi dapat terhalang oleh abstraksi konteks sematan: Satu pengguna manusia harus dikaitkan dengan satu akun pengguna Looker dengan satu kumpulan nilai atribut pengguna. Hal ini juga dijelaskan dalam penjelasan kami tentang external_user_id dalam Dokumentasi penyematan yang ditandatangani.

Looker menggunakan external_user_id untuk membedakan pengguna sematan yang ditandatangani, sehingga setiap pengguna harus memiliki ID unik yang ditetapkan untuk mereka.

Anda dapat membuat external_user_id untuk pengguna dengan string apa pun yang Anda inginkan, selama string tersebut unik untuk pengguna tersebut. Setiap ID dikaitkan dengan sekumpulan izin, atribut pengguna, dan model. Satu browser hanya dapat mendukung satu external_user_id, atau sesi pengguna, pada satu waktu. Tidak ada perubahan yang dapat dilakukan pada izin pengguna atau atribut pengguna di tengah sesi.

Memanfaatkan praktik terbaik ini

Dengan menerapkan prinsip ini pada contoh kami, Anda akan memerlukan satu nilai atribut pengguna yang memberikan akses ke SEMUA data yang dapat diakses oleh pemilik akun di seluruh aplikasi. Anda dapat melakukannya dengan menggunakan nilai yang dipisahkan koma untuk atribut brand Pied Piper,Hooli:

{
  "target_url": "https://mylookerinstance.cloud.looker.com/embed/dashboards/17",
  "session_length": 300,
  "force_logout_login": true,
  "external_user_id": "test_user",
  "first_name": "Test",
  "last_name": "User",
  "permissions": ["access_data","see_user_dashboards"],
  "models": ["thelook"],
  "user_attributes": {"brand":"Pied Piper,Hooli"}
}

Agar sintaksis ini berfungsi, Anda harus memastikan bahwa atribut pengguna Anda ditetapkan sebagai Filter String (lanjutan):

Perhatikan bahwa Anda masih dapat mengubah kumpulan atribut pengguna untuk pengguna jika ada perubahan pada tingkat akses data mereka. Misalnya, jika pemilik akun mengambil alih kepemilikan merek ketiga, Anda dapat menambahkan merek ketiga tersebut ke daftar yang dipisahkan koma, yang telah Anda tentukan untuk atribut pengguna merek miliknya. Dengan demikian, saat pengguna logout dan login kembali, perubahan akan diterapkan.

Memfilter hasil dasbor

Oke, saya mengerti bahwa atribut pengguna perlu menentukan semua data yang dapat diakses pengguna di seluruh aplikasi. Tetapi jika saya menentukan atribut pengguna dengan cara ini, maka data untuk semua merek tersebut akan ditampilkan di dasbor saya. Bagaimana cara mempersempit hasil dasbor tertentu ke brand tertentu?

Cara yang benar untuk memfilter dasbor tertentu adalah dengan menggunakan filter dasbor reguler. (Hal ini mungkin sudah jelas sekarang, tetapi kami telah melihat beberapa orang terjebak pada atribut pengguna sebagai satu-satunya cara untuk menerapkan filter dalam konteks sematan — mungkin karena user_attributes adalah parameter dalam URL sematan yang ditandatangani, sedangkan filter bukan merupakan parameter.)

Pastikan untuk mewajibkan nilai filter dan menggunakan salah satu opsi kontrol Pilihan Tunggal, seperti drop-down:

Pastikan filter diterapkan ke kolom yang benar di semua tile yang diperlukan:

Sekarang pemilik akun Anda dapat memilih di antara dua nilai tersebut (dan hanya dua nilai tersebut), karena opsi yang tersedia di drop-down dibatasi oleh atribut pengguna:

Mengisi otomatis filter dasbor

Oke, jadi sekarang dasbor dapat difilter berdasarkan merek tertentu, tetapi saya ingin nilai filter sudah ditetapkan ke merek tertentu saat pengguna memuat dasbor untuk merek tersebut di aplikasi saya.

Sekali lagi, sebaiknya pikirkan cara kerjanya dalam konteks non-sematan. Bagaimana cara mengirimkan link ke dasbor yang sudah menerapkan nilai filter tertentu kepada seseorang? Nah, Anda mungkin telah melihat bahwa ketika Anda memilih nilai filter, nilai filter tersebut muncul di URL untuk dasbor:

Sertakan bagian URL tersebut di target_url untuk panggilan create_sso_embed_url:

{
  "target_url": "https://mylookerinstance.cloud.looker.com/embed/dashboards/17?Brand=Hooli",
  "session_length": 300,
  "force_logout_login": true,
  "external_user_id": "test_user",
  "first_name": "Test",
  "last_name": "User",
  "permissions": ["access_data","see_user_dashboards"],
  "models": ["thelook"],
  "user_attributes": {"brand":"Pied Piper,Hooli"}
}

Jika menggunakan SDK sematan, Anda dapat menggunakan withFilters untuk menentukan filter awal yang akan diterapkan ke konten sematan:

https://looker-open-source.github.io/embed-sdk/classes/EmbedBuilder.html#withFilters

Jika menggunakan skrip kustom sendiri, Anda dapat memastikan bahwa Anda menambahkan filter ke URL sebelum jalur dienkode. Beberapa nilai mungkin sudah dienkode dalam string filter (misalnya, ada spasi yang dienkode sebagai + di ?Brand=Pied+Piper), sehingga nilai tersebut akan dienkode dua kali dalam URL final. Anda dapat melihat "Dasbor tersemat - tetapkan filter dasbor sebagai bagian dari URL?" Postingan Komunitas Looker untuk membahas perbedaan-perbedaan tersebut. Jika Anda masih mengalami kesulitan untuk menerapkan filter, Postingan komunitas tersebut juga dapat digunakan untuk menambahkan pertanyaan.

Menyembunyikan filter dasbor

Oke, saya melihat cara menetapkan filter awal di dasbor, tetapi saya juga tidak ingin pemilik akun mengubah filter dasbor itu sendiri—nilai filter HANYA ditentukan berdasarkan dasbor yang dibuka pemilik akun di aplikasi saya. Bagaimana cara menyembunyikan filter dasbor?

Anda dapat menggunakan tema untuk ini. Tema adalah fitur berbayar. Jadi, jika Anda belum mengaktifkannya di instance Looker, sebaiknya hubungi tim Penjualan Looker untuk mengaktifkannya.

Setelah fitur tersebut diaktifkan, buka bagian Kontrol Dasbor di halaman Admin - Tema. Di sana, Anda dapat menghapus opsi Panel Filter Tampilan:

Kemudian, Anda dapat menetapkan tema sebagai default atau menerapkan tema di URL dasbor tertentu. Sekali lagi, ini akan masuk ke target_url dari panggilan create_sso_embed_url:

{
  "target_url": "https://mylookerinstance.cloud.looker.com/embed/dashboards/17?Brand=Hooli&theme=test_theme",
  "session_length": 300,
  "force_logout_login": true,
  "external_user_id": "test_user",
  "first_name": "Test",
  "last_name": "User",
  "permissions": ["access_data","see_user_dashboards"],
  "models": ["thelook"],
  "user_attributes": {"brand":"Pied Piper,Hooli"}
}

Ada info selengkapnya tentang cara menyembunyikan filter dasbor sematan, termasuk beberapa cuplikan kode SDK sematan, dalam tutorial YouTube ini, Menyematkan Looker dengan filter kustom.

Hasil akhir akan terlihat identik dengan pengalaman pengguna dari pertanyaan awal:

Namun, karena nilai filter dienkode dalam URL target masing-masing yang disematkan di aplikasi, setiap dasbor merek akan selalu menampilkan dasbor yang difilter ke merek yang benar bahkan saat Anda beralih antar-tab.

sudoing sebagai pengguna lain

Pengalaman pengguna kini terlihat sangat mirip dengan apa yang awalnya saya bayangkan. Namun dalam kasus penggunaan saya, pemilik akun memiliki izin dan setelan pengguna lain yang tidak dimiliki setiap pengguna dengan external_user_id=pied_piper dan external_user_id=hooli, sehingga mengarah ke berbagai opsi yang tersedia di UI dan hanya pengalaman pengguna yang sedikit berbeda secara keseluruhan. Saya ingin pemilik akun melihat semuanya persis seperti yang dilihat pengguna pied_piper dan pied_piper , seolah-olah pemilik akun benar-benar login sebagai pengguna tersebut. Bagaimana cara melakukan hal ini?

Perintah yang Anda minta disebut "sudo". Jika ingin pemilik akun dapat menggunakan "sudo" untuk setiap pengguna brand, Anda dapat membuat fungsi sudo yang serupa di aplikasi, yang akan memuat URL sematan untuk external_user_id=pied_piper saat pemilik akun menggunakan sudo sebagai pengguna Pied Piper, dan URL sematan untuk external_user_id=hooli saat pemilik akun menggunakan sudo sebagai pengguna Hooli. Anda juga dapat menggunakan endpoint API login_user untuk menggunakan sudo sebagai pengguna merek dengan API jika aplikasi Anda menggunakan API.

Namun, jika Anda memikirkan tentang konteks non-sematan lagi: Di halaman Admin - Pengguna, Anda tidak dapat melakukan sudo secara bersamaan sebagai beberapa pengguna non-sematan di beberapa tab—sesi sudo akan diterapkan ke seluruh jendela browser, sama seperti semua sesi pengguna lainnya. Oleh karena itu, Anda harus mendesain {i>sudo to sudo <i}sebagai hanya satu pengguna dalam satu waktu. Jika Anda memikirkannya, desain ini lebih konsisten dengan meniru pengalaman pengguna yang Anda gunakan untuk sudoing secara sempurna. Pengguna pied_piper, misalnya, hanya memiliki akses ke dasbor Pied Piper dan tidak memiliki akses untuk membuka dasbor tambahan di tab tambahan. Oleh karena itu, Anda juga tidak dapat membuka dasbor yang berbeda di tab yang berbeda saat menggunakan sudo sebagai pengguna ini.

Kesimpulan

Kami harap panduan ini bermanfaat dan Anda merasa siap untuk melanjutkan pembuatan konten sematan yang ditandatangani Looker. Kami terus berupaya untuk menjadikan Looker sebagai penawaran analisis data sematan yang paling fleksibel dan andal, dan kami ingin mendengar masukan Anda. Jika ada pertanyaan atau ingin mempelajari lebih lanjut, Anda dapat berinteraksi dengan kami di Komunitas Looker dan menghadiri acara Komunitas kami.