Mengimplementasikan segmentasi tingkat baris untuk konten Looker tersemat

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

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

Pengantar

Fungsi sematan Looker adalah salah satu fitur produk Looker yang paling canggih dan berharga. Jika Anda membaca panduan ini, kemungkinan Anda sudah menyematkan konten Looker ke dalam aplikasi atau berencana melakukannya dalam waktu dekat.

Panduan ini dimaksudkan untuk membantu Anda lebih memahami desain fitur sematan Looker dan cara menerapkan segmentasi ke aplikasi tempat partner dapat mengelola akses ke beberapa merek. Sebagai pembahasan mendalam tentang topik ini, panduan ini cukup panjang untuk dibaca. Jadi, perlu diingat bahwa panduan ini bukan dimaksudkan sebagai solusi cepat untuk masalah sederhana, 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 dan menyajikan segmen pengguna yang seharusnya melihat irisan data yang berbeda.

Untuk kasus penggunaan sematan bertanda tangan ini, asumsikan bahwa Anda adalah Admin instance Looker Anda. Anda bekerja dengan dua jenis pengguna sematan eksternal: pelanggan, yang hanya dapat mengakses data yang berkaitan dengan merek tertentu mereka, dan partner, yang dapat mengakses data untuk beberapa merek. Anda memiliki dasbor dengan beberapa kartu yang Anda tunjukkan kepada setiap pelanggan yang menggunakan produk Anda, tetapi Anda memerlukan dasbor untuk difilter secara otomatis 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 products, yang menampilkan beberapa metrik produk untuk berbagai merek. Setiap merek sesuai dengan pengguna sematan yang berbeda (dengan external_user_id yang berbeda) dalam aplikasi sematan bertanda tangan. Karena setiap pengguna sematan hanya boleh 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 Eksplorasi 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 menampilkan dasbor seperti 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 atribut pengguna brand untuk setiap pengguna yang menyematkan.

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 sematan bertanda tangan Looker telah dirancang untuk memungkinkan developer membuat pengalaman data yang canggih dan disesuaikan bagi pengguna sekaligus memastikan bahwa tata kelola data yang ditentukan oleh model data dan kebijakan akses konten Anda tetap dipertahankan.

Memastikan tata kelola data berjalan lancar sangat 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 adalah ringkasan singkat tentang cara kerja semuanya.

Dasar-dasar sematan bertanda tangan Looker

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

Hal ini dapat membingungkan dalam konteks sematan bertanda tangan Looker, karena langkah autentikasi bertanda tangan, setelan pengguna, dan dasbor itu sendiri digabungkan menjadi satu URL yang panjang dan kompleks. Namun, URL tersebut digunakan untuk membuat sesi, yang tetap berlaku meskipun setelah URL dipersingkat. Dengan mengingat konsep ini, Anda akan lebih mudah berhasil membangun pengalaman data yang hebat.

Struktur URL sematan bertanda tangan

Berikut salah satu URL autentikasi sematan bertanda tangan 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-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 mencari akun pengguna yang sudah 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 diganti dengan detail akun yang ditentukan dalam URL.

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

  4. Kemudian, Looker akan mengalihkan ke URL target, atau URL pengalihan, 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 dalam URL sematan bertanda tangan asli:

    %2Fembed%2Fdashboards%2F17

Meskipun langkah 1-3 terjadi secara otomatis di latar belakang, dan yang dilihat pengguna akhir hanyalah hasil akhir (dasbor itu sendiri), langkah-langkah ini pada dasarnya sama dengan langkah-langkah yang digunakan pengguna Looker reguler yang tidak menyematkan 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 harus 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 untuk pengguna tersebut.

  3. Pengguna membuka halaman login di 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 berlaku untuk setiap tab di jendela browser. Jika pengguna memulai di https://mylookerinstance.cloud.looker.com/browse, membuka tab browser baru, dan membuka halaman apa pun yang dapat diakses berdasarkan izinnya, halaman akan dimuat seperti yang diharapkan menggunakan cookie sesi yang sudah dibuat di tab browser asli.

Hal yang sama berlaku untuk pengguna sematan. Pengguna yang menyematkan sedikit lebih terbatas dalam halaman yang dapat mereka akses di UI—mereka hanya dapat mengakses URL Look, dasbor, dan Jelajah dengan awalan /embed. Namun, mereka tetap dapat membuka dasbor secara manual yang dapat diakses oleh detail akun pengguna mereka. Misalkan URL sematan bertanda tangan asli 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 lain yang berada di folder yang sama (dan oleh karena itu memiliki batasan akses yang sama): https://mylookerinstance.cloud.looker.com/embed/dashboards/19.

Meskipun URL pengalihan yang ditentukan dalam URL sematan bertanda tangan asli 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 lain tidak diperlukan untuk memuat dasbor yang berbeda.

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

Sesi pengguna sematan bertanda tangan pada dasarnya berfungsi sama seperti sesi pengguna Looker reguler yang tidak disematkan, jadi akan sangat membantu jika Anda menyusun ulang pendekatan bermasalah yang dijelaskan sebelumnya dalam konteks sesi pengguna Looker reguler yang tidak disematkan dan menguraikan 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 memberi partner link ke dasbor. (https://mylookerinstance.cloud.looker.com/dashboards/17) dan memberi tahu mereka bahwa, untuk mengganti dasbor antar-merek, mereka harus kembali ke halaman login di tab lain dan memasukkan kredensial email dan sandi untuk akun pengguna lainnya, 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 tersebut menekan tombol Muat Ulang. Dasbor menampilkan data Hooli, yang membuat partner tersebut terkejut.

Jadi, sekarang Anda mungkin berpikir:

Tunggu… ini sangat tidak praktis. Lalu, bagaimana cara terbaik untuk melakukannya?

Tentu saja ada. Yang diilustrasikan oleh skenario ini adalah prinsip yang sudah tidak penting dalam konteks non-penyematan, tetapi dapat dikaburkan oleh abstraksi konteks penyematan: Satu pengguna manusia harus dikaitkan dengan satu akun pengguna Looker dengan satu set nilai atribut pengguna. Hal ini juga dijelaskan dengan jelas dalam penjelasan kami tentang external_user_id dalam dokumentasi Sematan bertanda tangan.

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

Anda dapat membuat external_user_id untuk pengguna dengan string apa pun yang Anda inginkan, asalkan unik untuk pengguna tersebut. Setiap ID dikaitkan dengan serangkaian 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 halnya solusi yang dapat disesuaikan, ada pendekatan tertentu yang harus Anda hindari. Misalnya, penerapan 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 Reload di dasbor Pied Piper.

…dasbor Pied Piper menampilkan data Hooli!

Anda dapat mencoba pendekatan serupa, tetapi menggunakan 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 akan menampilkan data untuk Hooli.

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

Menerapkan praktik terbaik

Untuk menerapkan pendekatan yang dijelaskan di bagian, "Pendekatan dari perspektif non-penyematan", Anda akan memerlukan satu nilai atribut pengguna yang memberikan akses ke SEMUA data yang seharusnya dapat 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 Anda 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 begitu, 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, dasbor saya akan menampilkan data untuk semua merek tersebut. Bagaimana cara mempersempit hasil dasbor tertentu ke merek tertentu?

Cara yang benar untuk memfilter dasbor tertentu adalah dengan menggunakan filter dasbor biasa. (Mungkin sekarang hal ini terlihat jelas, tetapi kami telah melihat beberapa orang kesulitan menggunakan atribut pengguna sebagai satu-satunya cara untuk menerapkan filter dalam konteks sematan — mungkin karena user_attributes adalah parameter dalam URL sematan bertanda tangan dan filter tidak.)

Pastikan untuk mewajibkan nilai filter dan menggunakan salah satu opsi kontrol Seleksi 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, jadi 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-penyematan. Bagaimana cara mengirim link ke dasbor yang sudah menerapkan nilai filter tertentu kepada seseorang? Nah, Anda mungkin telah memperhatikan bahwa saat Anda memilih nilai filter, nilai filter tersebut muncul di URL 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 embed SDK, Anda dapat menggunakan withFilters untuk menentukan filter awal yang akan diterapkan ke konten yang disematkan:

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

Jika menggunakan skrip kustom sendiri, Anda harus memastikan bahwa Anda menambahkan filter ke URL sebelum jalur dienkode. Beberapa nilai mungkin sudah dienkode dalam string filter (misalnya, ada spasi yang dienkode sebagai + dalam ?Brand=Pied+Piper), sehingga nilai tersebut akan dienkode ganda di URL akhir. Anda dapat melihat "SO embedded dashboard - set dashboard filter as part of 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 mengajukan pertanyaan.

Menyembunyikan filter dasbor

Oke, saya mengerti cara menyetel filter awal di dasbor, tetapi saya juga tidak ingin partner mengubah filter dasbor itu sendiri—nilai filter HANYA boleh ditentukan oleh dasbor mana yang telah dibuka partner di aplikasi saya. Bagaimana cara menyembunyikan filter dasbor?

Anda dapat menggunakan tema untuk melakukannya. Tema adalah fitur berbayar, jadi, jika Anda 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 menyembunyikan filter dasbor sematan, termasuk beberapa cuplikan kode Embed SDK, dalam tutorial YouTube ini, Menyematkan Looker dengan filter kustom.

Hasil akhirnya harus terlihat identik dengan pengalaman pengguna dari pertanyaan asli:

Namun, 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 bolak-balik antar-tab.

Menguji sebagai pengguna lain

Sekarang, pengalaman pengguna terlihat sangat mirip dengan yang saya bayangkan semula. Namun, dalam kasus penggunaan saya, partner memiliki izin yang berbeda dan setelan pengguna lain yang tidak dimiliki oleh pengguna individu 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 oleh pengguna pied_piper dan hooli, seolah-olah orang tersebut benar-benar login sebagai pengguna tersebut. Bagaimana cara melakukannya?

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

Namun, jika Anda memikirkan konteks non-penyematan lagi: Di halaman Admin - Pengguna, Anda tidak dapat secara bersamaan menggunakan sudo sebagai beberapa pengguna non-penyematan di beberapa tab—sesi sudo akan berlaku untuk seluruh jendela browser, seperti semua sesi pengguna lainnya. Oleh karena itu, Anda harus mendesain sudo ke sudo hanya untuk satu pengguna dalam satu waktu. Selain itu, jika Anda memikirkannya, desain ini lebih konsisten dengan meniru secara sempurna pengalaman pengguna yang Anda tiru. 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 juga tidak dapat membuka dasbor yang berbeda di tab yang berbeda saat Anda melakukan sudo sebagai pengguna ini.

Kesimpulan

Kami harap panduan ini bermanfaat dan Anda merasa siap untuk melanjutkan pembuatan konten sematan bertanda tangan Looker. Kami terus berupaya 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.