Mengimplementasikan segmentasi tingkat baris untuk konten Looker tersemat

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

Dengan segmentasi tingkat baris, Anda dapat membatasi data yang dapat diakses oleh setiap pengguna, berdasarkan nilai yang disimpan di satu atau beberapa kolom database. Panduan ini menjelaskan metode untuk menerapkan segmentasi tingkat baris dalam konten Looker tersemat, dan berisi bagian berikut:

Pengantar

Fungsi penyematan Looker adalah salah satu fitur paling canggih dan berharga dari produk Looker. Jika Anda membaca panduan ini, kemungkinan Anda 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 dan cara menerapkan segmentasi ke aplikasi tempat partner dapat mengelola akses ke beberapa merek. Sebagai pembahasan mendalam tentang topik ini, artikel ini mungkin agak panjang. Jadi, perlu diingat bahwa panduan ini tidak dimaksudkan sebagai perbaikan cepat untuk masalah sederhana, melainkan sebagai elemen penyusun untuk membantu Anda mengelola seluruh kasus penggunaan penyematan Looker dengan lebih baik.

Ringkasan kasus penggunaan

Panduan ini menjelaskan kasus penggunaan umum saat perusahaan Anda menyematkan konten Looker dalam produk dan menayangkan segmen pengguna yang akan melihat berbagai bagian data Anda.

Untuk kasus penggunaan penyematan yang ditandatangani ini, asumsikan bahwa Anda adalah Admin instance Looker. Anda bekerja sama dengan dua jenis pengguna penyematan eksternal: pelanggan, yang hanya boleh mengakses data yang berkaitan dengan merek tertentu mereka, dan partner, yang akan dapat mengakses data untuk beberapa merek. Anda memiliki dasbor dengan beberapa kartu yang ditampilkan kepada setiap pelanggan yang menggunakan produk Anda, tetapi Anda memerlukan dasbor yang otomatis difilter untuk setiap pelanggan sehingga dasbor hanya akan menampilkan data yang spesifik untuk pelanggan tersebut. Contoh dalam dokumen ini menggunakan dua perusahaan fiktif — Hooli dan Pied Piper.

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

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

Anda memiliki dasbor yang didasarkan pada Jelajah ini dan 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 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 akan 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 dibuat untuk Hooli menampilkan dasbor dengan cara ini:

Voilà! Dasbor difilter sesuai dengan nilai setiap pengguna sematan untuk atribut pengguna merek.

Mempelajari lebih dalam

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

Kabar baik! Fitur penyematan yang ditandatangani dari Looker telah dirancang untuk memungkinkan developer membuat pengalaman data yang canggih dan khusus bagi pengguna sekaligus memastikan bahwa tata kelola data yang ditentukan oleh model data dan kebijakan akses konten Anda dipertahankan.

Memastikan tata kelola data tidak bocor sangatlah penting untuk memberikan pengalaman data yang efektif. Baca terus untuk mempelajari beberapa konsep dan praktik terbaik yang dapat Anda gunakan untuk mendesain pengalaman yang paling sesuai untuk Anda. Pertama, ringkasan singkat tentang cara kerja semuanya.

Dasar-dasar penyematan Looker yang ditandatangani

Perlu diingat bahwa autentikasi dan pengelolaan pengguna Looker dalam konteks penyematan pada dasarnya berfungsi dengan cara yang sama seperti dalam konteks non-penyematan dan pada dasarnya sama seperti sebagian besar aplikasi web lainnya.

Hal ini dapat membingungkan dalam konteks penyematan Looker yang ditandatangani, karena langkah autentikasi yang ditandatangani, setelan pengguna, dan dasbor itu sendiri digabungkan menjadi satu URL panjang dan rumit. Namun, URL tersebut digunakan untuk membuat sesi, yang tetap berlaku meskipun URL telah dipersingkat. Mempertimbangkan konsep ini akan sangat membantu Anda dalam membangun pengalaman data yang luar biasa.

Struktur URL penyematan yang ditandatangani

Berikut adalah salah satu URL autentikasi penyematan 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 URL yang sama yang didekode dan dipecah menjadi baris terpisah:

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

Saat Anda mengakses URL ini, beberapa hal akan terjadi:

  1. Looker akan 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 pengalihan 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 digunakan pengguna Looker reguler yang tidak disematkan 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 akun pengguna sudah ada untuk pengguna ini. Jika tidak, Anda dapat membuat akun pengguna baru.

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

  3. Pengguna membuka halaman login di https://mylookerinstance.cloud.looker.com/login dan memasukkan nama pengguna dan 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 berlaku untuk setiap tab di jendela browser. Jika pengguna memulai di https://mylookerinstance.cloud.looker.com/browse, membuka tab browser baru, dan membuka halaman yang aksesnya diberikan oleh izin mereka, halaman akan dimuat seperti yang diharapkan menggunakan cookie sesi yang sudah dibuat di tab browser asli.

Hal yang sama berlaku untuk pengguna sematan. Pengguna sematan memiliki batasan halaman yang dapat diakses di UI—mereka hanya dapat mengakses URL Tampilan, dasbor, dan Jelajahi dengan awalan /embed. Namun, mereka tetap dapat membuka dasbor mana pun yang aksesnya diberikan oleh detail akun pengguna mereka secara manual. Misalkan URL sematan asli yang ditandatangani mengalihkan Anda ke https://mylookerinstance.cloud.looker.com/embed/dashboards/17 di satu tab browser. Kemudian, Anda membuka tab browser baru dan memuat dasbor sematan yang 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. Perhatikan bahwa URL sematan bertanda tangan lainnya tidak diperlukan untuk memuat dasbor yang berbeda.

Insight utama di sini adalah bahwa semua detail akun pengguna yang dibuat di URL (izin, atribut pengguna, dll.) diterapkan ke seluruh sesi pengguna, bukan hanya ke dasbor tertentu yang ditentukan dalam URL asli yang ditandatangani. Dengan kata lain, seperti 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.

Mengakses beberapa merek secara bersamaan

Pertimbangkan bahwa Anda juga memiliki partner eksternal yang mungkin memiliki atau mengelola beberapa merek. Dalam contoh ini, partner mengelola merek Pied Piper dan Hooli.

Pendekatan dari perspektif non-embed

Sesi pengguna sematan yang ditandatangani pada dasarnya berfungsi dengan cara yang sama seperti sesi pengguna Looker reguler yang tidak disematkan, jadi sebaiknya ubah pendekatan bermasalah yang dijelaskan sebelumnya dalam konteks sesi pengguna Looker reguler yang tidak disematkan dan uraikan langkah-langkah tersebut untuk membantu memahami cara menerapkan solusi ini dengan cara yang lebih andal. Berikut tampilan alur kerja tersebut jika Anda memberikan petunjuk kepada pengguna BI standar yang memiliki akses ke UI Looker:

  1. Anda membuat dua akun pengguna yang berbeda di halaman Admin - Pengguna.
    1. Di halaman edit untuk akun pengguna pertama, Anda menetapkan nilai atribut pengguna brand ke pied_piper.
    2. Di halaman edit untuk akun pengguna kedua, Anda menetapkan nilai atribut pengguna brand ke hooli.
  2. Anda mengirimkan email penyiapan akun untuk kedua akun pengguna kepada partner.
  3. Partner menyiapkan kredensial email dan sandi terpisah untuk setiap akun.
  4. Anda memberikan link ke dasbor kepada partner. (https://mylookerinstance.cloud.looker.com/dashboards/17) dan beri tahu mereka bahwa, untuk beralih 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.

Partner mengikuti petunjuknya. Namun, setelah memasukkan nama pengguna dan sandi akun pengguna Hooli di tab browser kedua, lalu kembali ke tab pertama tempat dasbor Pied Piper sudah dimuat, partner menekan tombol Muat ulang. Yang mengejutkan partner, dasbor menampilkan data Hooli!.

Jadi, sekarang Anda mungkin berpikir:

Tunggu…ini sangat merepotkan. Jadi, bagaimana cara terbaik untuk melakukannya?

Tentu saja ada. Skenario ini membantu menggambarkan prinsip yang sudah umum dalam konteks non-penyematan, tetapi dapat dikaburkan oleh abstraksi konteks penyematan: 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 login, sehingga setiap pengguna harus memiliki ID unik yang ditetapkan.

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

Mengakses beberapa merek secara bersamaan — hal yang TIDAK boleh dilakukan

Seperti solusi yang dapat disesuaikan lainnya, ada pendekatan tertentu yang harus Anda hindari. Misalnya, implementasi saat 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 perlu diakses partner. Kami sering melihat developer menerapkan solusi seperti ini, yang menghasilkan 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 Muat ulang di dasbor Pied Piper.

…dasbor Pied Piper menampilkan data Hooli.

Anda dapat mencoba pendekatan yang serupa, tetapi gunakan external_user_id test_user yang sama untuk kedua panggilan create_sso_embed_url. Namun, perilakunya sama persis — setelah tab dimuat ulang dengan dasbor Pied Piper, tab tersebut akan menampilkan data untuk Hooli.

Bagaimana cara memastikan bahwa dasbor setiap merek hanya menampilkan data untuk merek tersebut?

Menggunakan praktik terbaik

Untuk menerapkan pendekatan yang dijelaskan di bagian, "Pendekatan dari perspektif non-penyematan", Anda memerlukan satu nilai atribut pengguna yang memberikan akses ke SEMUA data yang harus diakses partner 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 ditetapkan sebagai Filter String (lanjutan):

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

Memfilter hasil dasbor

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

Cara yang benar untuk memfilter dasbor tertentu adalah dengan menggunakan filter dasbor biasa. (Hal ini mungkin tampak jelas sekarang, tetapi kami melihat beberapa orang mengalami kesulitan dengan atribut pengguna sebagai satu-satunya cara untuk menerapkan filter dalam konteks penyematan — mungkin karena user_attributes adalah parameter dalam URL penyematan yang ditandatangani dan filter tidak.)

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 kartu yang diperlukan:

Sekarang partner 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, sekarang dasbor dapat difilter ke 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-embed. Bagaimana cara mengirim link ke dasbor yang sudah menerapkan nilai filter tertentu kepada seseorang? Anda mungkin telah memperhatikan bahwa saat memilih nilai filter, nilai filter tersebut akan 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 Anda sendiri, pastikan 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 ganda di URL akhir. Anda dapat melihat "Dasbor tersemat SO - menetapkan filter dasbor sebagai bagian dari URL?" Postingan Komunitas Looker untuk beberapa diskusi tentang nuansa ini. Jika Anda masih mengalami masalah saat menerapkan filter, Postingan komunitas tersebut juga merupakan tempat yang tepat untuk menambahkan pertanyaan.

Menyembunyikan filter dasbor

Oke, saya sudah tahu cara menetapkan filter awal di dasbor, tetapi saya juga tidak ingin partner mengubah filter dasbor sendiri—nilai filter hanya boleh ditentukan oleh dasbor yang dibuka partner di aplikasi saya. Bagaimana cara menyembunyikan filter dasbor?

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

Setelah fitur tersebut diaktifkan, buka bagian Kontrol Dasbor di halaman Admin - Tema, tempat Anda dapat menghapus opsi Tampilkan Panel Filter:

Kemudian, Anda dapat menetapkan tema sebagai default atau menerapkan tema di URL dasbor tertentu. Sekali lagi, ini akan masuk ke target_url 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, di tutorial YouTube ini, Menyemat Looker dengan filter kustom.

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

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

Menguji sebagai pengguna lain

Sekarang, pengalaman pengguna terlihat sangat mirip dengan yang saya bayangkan sebelumnya. Namun, dalam kasus penggunaan saya, partner memiliki izin dan setelan pengguna lain yang tidak dimiliki oleh pengguna individual dengan external_user_id=pied_piper dan external_user_id=hooli, yang menyebabkan opsi yang berbeda tersedia di UI dan pengalaman pengguna yang sedikit berbeda secara keseluruhan. Saya ingin mengizinkan pengguna melihat semuanya persis seperti yang dilihat pengguna pied_piper dan hooli , seolah-olah orang tersebut benar-benar login sebagai pengguna tersebut. Bagaimana cara melakukannya?

Jika ingin pengguna dapat melakukan pengujian sebagai setiap pengguna merek, Anda dapat membuat fungsi sudo serupa di aplikasi yang akan memuat URL penyematan untuk external_user_id=pied_piper saat pengguna menggunakan sudo sebagai pengguna Pied Piper, dan URL penyematan untuk external_user_id=hooli saat pengguna menggunakan sudo sebagai pengguna Hooli. Anda juga dapat menggunakan endpoint login_user API untuk sudo sebagai pengguna merek dengan API jika aplikasi Anda menggunakan API.

Namun, jika Anda memikirkan kembali konteks non-embed: Di halaman Admin - Users, Anda tidak dapat melakukan sudo secara bersamaan sebagai beberapa pengguna non-embed di beberapa tab—sesi sudo akan berlaku untuk seluruh jendela browser, seperti semua sesi pengguna lainnya. Oleh karena itu, Anda harus mendesain sudo untuk sudo sebagai satu pengguna dalam satu waktu. Dan, jika Anda memikirkannya, desain ini lebih konsisten dengan meniru pengalaman pengguna yang Anda gunakan sudo-nya dengan sempurna. Misalnya, pengguna pied_piper hanya memiliki akses ke dasbor Pied Piper dan tidak memiliki akses untuk membuka dasbor tambahan di tab tambahan. Oleh karena itu, Anda tidak akan dapat membuka dasbor yang berbeda di tab yang berbeda saat menggunakan sudo sebagai pengguna ini.

Kesimpulan

Semoga panduan ini bermanfaat bagi Anda dan Anda merasa siap untuk melanjutkan pembuatan konten sematan yang ditandatangani Looker. Kami terus berupaya menjadikan Looker sebagai penawaran analisis data tersemat 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.