Menerapkan 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 setiap pengguna, berdasarkan nilai yang disimpan di 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 penyematan Looker adalah salah satu fitur yang paling canggih dan berharga dari produk Looker. Jika Anda membaca panduan ini, kemungkinan Anda telah 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. Pembahasan mendalam tentang topik ini cukup panjang. Jadi, perlu diingat bahwa panduan ini tidak dimaksudkan sebagai solusi cepat untuk masalah yang mudah dipahami, melainkan fondasi 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 menayangkan segmen pengguna yang seharusnya melihat berbagai potongan data yang berbeda.

Untuk kasus penggunaan penyematan bertanda tangan ini, anggap bahwa Anda adalah Admin instance Looker Anda. Anda bekerja dengan dua jenis pengguna sematan eksternal: pelanggan, yang seharusnya hanya dapat mengakses data yang berkaitan dengan merek spesifik mereka, dan partner, yang akan dapat mengakses data untuk beberapa merek. Anda memiliki dasbor dengan beberapa ubin yang ditampilkan kepada setiap pelanggan yang menggunakan produk Anda, tetapi Anda memerlukan dasbor yang difilter secara otomatis 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 yang disebut 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 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 kotak: Satu menampilkan nama merek, dan lainnya menampilkan jumlah produk untuk merek tersebut.

Anda menggunakan endpoint create_sso_embed_url untuk membuat URL sematan dasbor ini untuk 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 hooli external_user_id:

{
  "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.

Menggali lebih dalam

Keren sekali! Namun, bagaimana jika saya ingin memberikan akses ke beberapa brand kepada satu pengguna? Bagaimana cara memastikan data saya hanya dilihat oleh pengguna yang relevan?

Kabar baik! Fitur penyematan bertanda tangan Looker dirancang untuk mendukung developer dalam menciptakan pengalaman data khusus yang canggih bagi pengguna, sekaligus memastikan tata kelola data yang ditentukan oleh model data dan kebijakan akses konten Anda tetap dipertahankan.

Memastikan bahwa tata kelola data ketat adalah hal yang sangat penting untuk memberikan pengalaman data yang andal. Lanjutkan membaca untuk menjelajahi beberapa konsep dan praktik terbaik yang dapat Anda gunakan untuk merancang pengalaman yang paling sesuai bagi Anda. Pertama adalah ikhtisar singkat tentang bagaimana semua ini bekerja.

Dasar-dasar sematan yang ditandatangani Looker

Penting untuk diingat bahwa autentikasi dan pengelolaan pengguna Looker dalam konteks sematan berfungsi dengan cara yang pada dasarnya sama seperti dalam konteks tanpa penyematan, dan pada dasarnya sama seperti sebagian besar 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 membuat sesi, yang masih berlaku bahkan setelah URL dipersingkat. Mempertimbangkan konsep ini akan membantu Anda mencapai kesuksesan dalam membangun pengalaman data yang luar biasa.

Struktur URL sematan yang ditandatangani

Berikut ini 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 adalah 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 terjadi:

  1. Looker akan 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 sudah 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 dalam 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 untuk melakukan autentikasi oleh pengguna Looker reguler yang tidak tersemat. Misalkan Anda menginginkan pengguna login dengan kredensial pengguna dan sandi. Prosesnya akan terlihat seperti ini:

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

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

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

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

Perhatikan bahwa cookie sesi akan diterapkan ke 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 oleh izin mereka, halaman akan dimuat seperti yang diharapkan menggunakan cookie sesi yang telah dibuat di tab browser asli.

Hal yang sama berlaku untuk pengguna sematan. Pengguna sematan sedikit lebih terbatas, yaitu halaman yang dapat mereka akses di UI. Mereka hanya dapat mengakses URL Look, dasbor, dan Eksplorasi dengan awalan /embed. Namun, mereka masih bebas membuka dasbor secara manual ke dasbor mana pun yang dapat diakses dengan detail akun pengguna. Misalnya URL sematan asli yang ditandatangani mengalihkan Anda ke https://mylookerinstance.cloud.looker.com/embed/dashboards/17 dalam satu tab browser. Kemudian, buka tab browser baru dan muat dasbor sematan lain 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 lain yang ditandatangani tidak diperlukan untuk memuat dasbor berbeda.

Insight utamanya di sini adalah semua detail akun pengguna yang ditetapkan 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, seperti namanya, atribut pengguna adalah fitur pengguna, bukan fitur dasbor, dan harus digunakan untuk menentukan tingkat akses pengguna tertentu di seluruh aplikasi, tidak 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 yang tidak disematkan

Sesi pengguna sematan bertanda tangan bekerja pada dasarnya dengan cara yang sama seperti sesi pengguna Looker reguler yang tidak disematkan, sehingga akan sangat membantu untuk membingkai 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 adalah 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 pada halaman Admin - Pengguna.
    1. Di halaman edit untuk akun pengguna pertama, Anda harus menetapkan nilai atribut pengguna merek ke pied_piper.
    2. Di halaman edit untuk akun pengguna kedua, tetapkan nilai atribut pengguna merek ke hooli.
  2. Anda mengirimkan email pembuatan 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 mengganti dasbor antar-merek, mereka harus kembali ke halaman login di tab lain dan memasukkan kredensial email serta sandi untuk akun pengguna mereka yang lain, lalu memuat kembali dasbor di tab tersebut.

Partner 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, partner menekan tombol Reload. Sebagai kejutan bagi partner, dasbor menampilkan data Hooli!.

Jadi sekarang Anda mungkin berpikir:

Tunggu...ini sangat merepotkan. Bagaimana cara terbaik untuk melakukannya?

Tentu saja ada. Yang diilustrasikan dalam skenario ini adalah prinsip yang tidak begitu jelas dalam konteks yang tidak disematkan, 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 untuknya.

Anda dapat membuat external_user_id untuk pengguna dengan string apa pun yang Anda sukai, 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, 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 di mana aplikasi Anda menghasilkan URL untuk 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 oleh partner. Sering kali kami 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 di 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. Namun, perilakunya sama persis — setelah tab dimuat ulang dengan dasbor Pied Piper, data untuk Hooli akan ditampilkan.

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

Menerapkan praktik terbaik

Untuk menerapkan pendekatan yang dijelaskan di bagian, "Pendekatan dari perspektif yang tidak disematkan", Anda memerlukan nilai atribut pengguna tunggal yang memberikan akses ke SEMUA data yang dapat diakses oleh 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 perlu memastikan atribut pengguna sudah 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 partner mengambil kepemilikan merek ketiga, Anda dapat menambahkan merek ketiga tersebut ke daftar yang dipisahkan koma yang telah Anda tentukan untuk atribut pengguna merek miliknya. Dengan begitu, saat mereka logout dan login kembali, perubahan akan diterapkan.

Memfilter hasil dasbor

Baik, saya memahami bahwa atribut pengguna perlu 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! Bagaimana cara mempersempit hasil dasbor tertentu ke merek tertentu?

Cara yang benar untuk memfilter dasbor tertentu adalah dengan menggunakan filter filter dasbor! (Hal ini mungkin terlihat 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 dan filter bukan.)

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

Pastikan bahwa filter diterapkan ke bidang yang benar pada semua ubin 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 yang tidak disematkan. Bagaimana cara mengirimkan link ke dasbor yang sudah menerapkan nilai filter tertentu kepada seseorang? Anda mungkin telah memperhatikan bahwa saat 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 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 + di ?Brand=Pied+Piper), sehingga nilai tersebut akan dienkode dua kali di URL final. Anda dapat melihat "Dasbor sematan SO - tetapkan filter dasbor sebagai bagian dari URL?" Postingan Komunitas Looker untuk membahas perbedaan ini. Jika Anda masih mengalami kesulitan dalam menerapkan filter, Postingan komunitas juga bisa menjadi tempat yang tepat untuk menambahkan pertanyaan.

Menyembunyikan filter dasbor

Oke, saya melihat cara menetapkan filter awal di dasbor, tetapi saya juga tidak ingin partner mengubah filter dasbor itu sendiri. Nilai filter harus ditentukan HANYA melalui dasbor yang dibuka partner 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, Anda harus menghubungi tim Penjualan Looker untuk mengaktifkannya.

Setelah fitur tersebut diaktifkan, buka bagian Kontrol Dasbor pada halaman Admin - Tema, tempat 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"}
}

Anda dapat mengetahui informasi selengkapnya tentang cara menyembunyikan filter dasbor sematan, termasuk beberapa cuplikan kode SDK sematan, dalam tutorial YouTube ini, yang berjudul Menyematkan Looker dengan filter kustom.

Hasil akhir harus terlihat sama dengan pengalaman pengguna dari pertanyaan awal:

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

Melakukan pengujian sebagai pengguna lain

Sekarang pengalaman pengguna terlihat sangat mendekati apa yang awalnya saya bayangkan. Namun dalam kasus penggunaan saya, partner memiliki izin yang berbeda dan setelan pengguna lainnya yang tidak dimiliki setiap pengguna dengan external_user_id=pied_piper dan external_user_id=hooli, yang mengarah pada opsi berbeda yang tersedia di UI dan hanya pengalaman pengguna yang sedikit berbeda secara keseluruhan. Saya ingin mengizinkan pengguna melihat semuanya persis seperti pengguna pied_piper dan pied_piper yang melihatnya, seolah-olah orang tersebut benar-benar login sebagai pengguna tersebut. Bagaimana cara melakukannya?

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

Namun, jika Anda memikirkan kembali konteks yang tidak disematkan: Di halaman Admin - Pengguna, Anda tidak dapat menggunakan sudo sebagai beberapa pengguna yang tidak disematkan di beberapa tab secara bersamaan—sesi sudo akan diterapkan ke seluruh jendela browser, seperti semua sesi pengguna lainnya. Oleh karena itu, Anda harus mendesain {i>sudo to sudo <i}hanya untuk satu pengguna pada satu waktu. Dan, jika Anda memikirkannya, desain ini lebih konsisten dengan meniru pengalaman pengguna yang Anda 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 tidak akan dapat membuka dasbor yang berbeda di tab yang berbeda saat Anda menggunakan {i>sudoing <i}sebagai pengguna ini.

Kesimpulan

Kami harap panduan ini bermanfaat bagi Anda, dan Anda merasa siap untuk melanjutkan pengembangan konten sematan yang ditandatangani 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.