현재 Looker 문서를 보고 있습니다. Looker Studio 문서는 https://support.google.com/looker-studio를 방문하세요.

임베딩된 Looker 콘텐츠에 대한 행 수준 보안 구현

작성자: 크리스토퍼 시모어(수석 데이터 분석가), 딘 힉스(개발자 관계 엔지니어)

소개

Looker의 임베딩 기능은 Looker 제품의 가장 강력하고 유용한 기능 중 하나입니다. 이 가이드를 읽고 있는 경우 이미 애플리케이션에 Looker 콘텐츠를 임베딩하고 있거나 가까운 미래에 임베딩하려는 것일 수 있습니다.

이 가이드는 Looker 임베딩 기능의 설계를 더 잘 이해하여 사용자에게 데이터를 제공하는 강력하고 안전한 애플리케이션을 빌드할 수 있도록 돕기 위해 작성되었습니다. 주제를 심층적으로 다루는 데는 시간이 오래 걸립니다. 이 가이드는 특정 문제의 빠른 해결 방법을 위한 것이 아니라 전체 Looker 임베딩 사용 사례를 관리하는 데 유용한 구성 요소라는 점을 참고하시기 바랍니다.

사용 사례 개요

이 가이드에서는 회사에서 제품 내에 Looker 콘텐츠를 임베딩하는 일반적인 사용 사례를 설명합니다.

이 서명된 임베딩 사용 사례에서는 사용자가 Looker 인스턴스의 관리자라고 가정합니다. 두 가지 임베딩 유형의 사용자로 작업합니다. 자신의 회사와 관련된 데이터에만 액세스할 수 있어야 하는 고객(또는 '브랜드 사용자')과 여러 특정 고객의 데이터에 액세스할 수 있는 계정 소유자입니다. 제품을 사용하는 모든 고객에게 표시되는 몇 개의 타일이 있는 대시보드가 있지만 대시보드에 해당 고객과 관련된 데이터만 표시되도록 대시보드를 각 고객별로 자동으로 필터링해야 합니다. 이 문서의 예시에서는 Hooli 및 Pied Piper라는 두 가지 가상 회사를 사용합니다.

여러 브랜드의 일부 제품 측정항목을 보여주는 제품이라는 테이블이 있습니다. 각 브랜드는 서명된 임베딩 애플리케이션의 서로 다른 임베딩 사용자(external_user_id가 다름)에 해당합니다. 각 임베딩 사용자는 자신의 브랜드의 데이터만 볼 수 있어야 하므로 브랜드 사용자 속성에 액세스 필터를 사용하는 간단한 탐색이 있습니다.

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

이 탐색을 기반으로 하며 두 개의 타일이 있는 간단한 대시보드가 있습니다. 하나는 브랜드 이름을, 다른 하나는 해당 브랜드의 제품 수를 표시합니다.

create_sso_embed_url 엔드포인트를 사용하여 각 임베딩 사용자에 대해 이 대시보드의 임베딩 URL을 생성합니다. 이 예시에서는 Pied Piper와 Hooli라는 두 가지 브랜드를 사용합니다. 다음은 external_user_id pied_piper와 함께 Pied Piper의 create_sso_embed_url 호출에 사용하는 요청 본문입니다.

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

Pied Piper에 대해 생성한 URL은 다음과 같은 방식으로 대시보드를 표시합니다.

다음은 Hooli의 create_sso_embed_url 호출에 사용된 요청 본문이며 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"}
}

Hooli에 대해 생성된 URL은 다음과 같은 방식으로 대시보드를 표시합니다.

그러면 대시보드는 브랜드 사용자 속성에 대한 각 임베딩 사용자의 값에 따라 필터링됩니다.

자세히 살펴보기

정말 유용합니다. 하지만 한 계정 소유자에게 여러 브랜드에 대한 액세스 권한을 부여하려면 어떻게 해야 하나요? 내 데이터가 관련 사용자에게만 표시되도록 하려면 어떻게 해야 하나요?

좋은 소식입니다. Looker의 서명된 임베딩 기능은 개발자가 데이터 모델 및 콘텐츠 액세스 정책으로 정의된 데이터 거버넌스를 유지하면서 사용자를 위한 강력한 맞춤형 데이터 환경을 만들 수 있도록 설계되었습니다.

데이터 거버넌스를 철저하게 유지하는 것은 강력한 데이터 경험을 제공하는 데 있어 매우 중요합니다. 가장 적합한 환경을 설계하는 데 사용할 수 있는 몇 가지 개념과 권장사항을 알아보세요. 첫 번째는 이 모든 작동 방식에 대한 간단한 개요입니다.

Looker 서명된 임베딩의 기본사항

임베딩 컨텍스트에서 Looker의 사용자 인증 및 관리는 비임베딩 컨텍스트에서와 기본적으로 동일한 방식으로 작동하며 대부분의 다른 웹 애플리케이션과 기본적으로 동일한 방식으로 작동한다는 점을 염두에 두어야 합니다.

서명된 인증 단계, 사용자 설정, 대시보드 자체가 모두 하나의 길고 복잡한 URL로 결합되기 때문에 Looker 서명된 임베딩 컨텍스트에서 혼동을 줄 수 있습니다. 그러나 이 URL은 세션을 설정하는 데 사용되며, URL이 단축된 후에도 적용됩니다. 이 개념을 염두에 두면 훌륭한 데이터 경험을 구축하는 데 큰 도움이 될 것입니다.

서명된 임베딩 URL 구조

다음은 Pied Piper의 요청 본문과 함께 create_sso_embed_url 호출로 생성된 서명된 임베딩 인증 URL 중 하나입니다.

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

다음은 동일한 URL을 디코딩하여 개별 줄로 분해한 것입니다.

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

이 URL에 액세스하면 다음과 같은 결과가 발생합니다.

Looker는 external_user_id = pied_piper인 기존 사용자 계정을 찾습니다. 아무것도 없으면 Looker가 해당 external_user_id로 신규 사용자 계정을 만듭니다.
권한, 모델, 그룹(지정된 경우), 사용자 속성 값(지정된 경우)을 포함한 기존 사용자의 계정 세부정보가 URL에 지정된 계정 세부정보로 덮어쓰기됩니다.
Looker는 사용자를 인증하고 브라우저에 세션 쿠키를 저장하여 해당 사용자에 대한 세션을 설정합니다.
그런 다음 Looker가 create_sso_embed_url 호출에 지정된 대상 URL 또는 리디렉션 URL로 리디렉션합니다.

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

이 리디렉션 URL은 원래 서명된 임베딩 URL에서 인코딩된 상대 URL로 표시됩니다.

%2Fembed%2Fdashboards%2F17

1~3단계가 백그라운드에서 자동으로 진행되고 최종 사용자에게 표시되는 모든 결과가 최종 결과(대시보드 자체)이지만 이 단계는 기본적으로 일반 비임베딩 Looker 사용자가 인증하는 단계와 동일합니다. 사용자가 사용자 및 비밀번호 사용자 인증 정보로 로그인하도록 한다고 가정해 보겠습니다. 이 프로세스는 다음과 같은 형태가 됩니다.

사용자(Looker 관리자)가 관리자 패널로 이동하고 검색창을 사용하여 이 사용자의 계정이 이미 있는지 확인합니다. 없으면 새 사용자 계정을 만듭니다.
사용자(Looker 관리자)가 관리자 패널에서 사용자 옆에 있는 수정을 누르고 사용자에게 권한, 모델, 그룹, 사용자 속성 값, 기타 값을 프로비저닝합니다.
사용자가 https://mylookerinstance.cloud.looker.com/login의 로그인 페이지로 이동하여 사용자 이름과 비밀번호를 입력합니다. Looker는 사용자를 인증하고 브라우저에 세션 쿠키를 저장하여 해당 사용자에 대한 세션을 설정합니다.
그러면 Looker가 방문 페이지(일반적으로 https://mylookerinstance.cloud.looker.com/browse)로 리디렉션됩니다.

세션 쿠키는 브라우저 창의 모든 탭에 적용됩니다. 사용자가 https://mylookerinstance.cloud.looker.com/browse에서 시작하여 새 브라우저 탭을 열고 액세스 권한을 부여하는 페이지로 이동하면 페이지가 원래 브라우저 탭에 이미 설정된 세션 쿠키를 사용하여 정상적으로 로드됩니다.

임베딩 사용자의 경우에도 마찬가지입니다. 임베딩 사용자는 UI에서 액세스할 수 있는 페이지가 좀 더 제한됩니다. 임베딩 사용자는 /embed 프리픽스가 있는 Look, 대시보드, Explore URL에만 액세스할 수 있습니다. 하지만 사용자 계정 세부정보에서 액세스 권한을 부여받은 대시보드로 직접 이동할 수는 있습니다. 원래 서명된 임베딩 URL이 하나의 브라우저 탭에서 https://mylookerinstance.cloud.looker.com/embed/dashboards/17로 리디렉션된다고 가정해 보겠습니다. 그런 다음 새 브라우저 탭을 열고 동일한 폴더에 있는 다른 임베딩 대시보드를 로드합니다(따라서 동일한 액세스 제한이 적용됩니다). https://mylookerinstance.cloud.looker.com/embed/dashboards/19

원래 서명된 임베딩 URL에 지정된 리디렉션 URL은 대시보드 17에 대한 것이지만 브라우저 탭에 URL을 수동으로 입력하면 대시보드 19가 예상대로 로드되는 것을 확인할 수 있습니다. 다른 대시보드를 로드하는 데 다른 서명된 임베딩 URL이 필요하지 않았습니다.

여기서 중요한 점은 URL에 설정된 모든 사용자 계정 세부정보(권한, 사용자 속성 등)가 원래 서명된 URL에 지정된 특정 대시보드뿐만 아니라 전체 사용자 세션에 적용된다는 것입니다. 즉, 이름에서 알 수 있듯이 사용자 속성은 대시보드의 기능이 아니라 사용자의 기능이며 특정 탭뿐만 아니라 전체 애플리케이션에서 특정 사용자의 액세스 수준을 결정하는 데 사용해야 합니다.

계정 소유자 사용 사례

맞춤설정 가능한 솔루션과 마찬가지로 피해야 할 특정 접근 방식이 있습니다. 이 점을 고려하여 여러 브랜드를 소유하거나 관리할 수 있는 계정 소유자도 여러 개 있다는 점을 고려하세요. 이 예시에서는 계정 소유자가 Pied Piper와 Hooli 브랜드를 모두 관리합니다. 따라서 앱은 이전에 표시된 create_sso_embed_url 호출의 동일한 입력을 사용하여 external_user_ids의 URL을 생성하고 계정 소유자가 액세스하려는 각 대시보드를 로드하는 새 탭을 앱에 만듭니다. 개발자가 다음과 같은 솔루션을 구현하여 사용자에게 잘못된 워크플로가 흔히 발생합니다.

Pied Piper 대시보드 탭으로 이동합니다.
Hooli 대시보드 탭으로 이동합니다.
Pied Piper 대시보드 탭으로 다시 이동합니다.
Pied Piper 대시보드에서 새로고침 버튼을 누릅니다.

…Pied Piper 대시보드에는 Hooli 데이터가 표시됩니다.

비슷한 접근법을 시도할 수 있지만 대신 두 create_sso_embed_url 호출에서 동일한 external_user_id test_user를 사용합니다.

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

하지만 동작이 정확히 동일합니다. Pied Piper 대시보드로 탭을 새로고침하면 Hooli의 데이터가 대신 표시됩니다.

어떻게 된 것일까요? 각 브랜드의 대시보드에 해당 브랜드의 데이터만 표시되도록 하려면 어떻게 해야 하나요?

비임베딩 관점에서 동일한 접근 방식

이전 섹션에서 설명한 것처럼 서명된 임베딩 사용자 세션은 기본적으로 일반 비임베딩 Looker 사용자 세션과 동일한 방식으로 작동하므로, 이전에 일반적인 비임베딩 Looker 사용자 세션 컨텍스트에서 설명한 문제가 있는 접근 방식을 재구성하고 해당 단계들을 세분화함으로써 이 솔루션을 보다 견고하게 구현하는 방법을 이해하는 데 도움이 될 수 있습니다. Looker UI에 액세스할 수 있는 표준 BI 사용자에게 안내를 제공하는 경우 이 워크플로는 다음과 같습니다.

관리자 페이지에서 2개의 서로 다른 사용자 계정을 만듭니다.
1. 첫 번째 사용자 계정의 수정 페이지에서 브랜드 사용자 속성 값을 pied_piper로 설정합니다.
2. 두 번째 사용자 계정의 수정 페이지에서 브랜드 사용자 속성 값을 hooli로 설정합니다.
두 사용자 계정에 대한 계정 설정 이메일을 계정 소유자에게 보냅니다.
계정 소유자는 계정별로 이메일 및 비밀번호 사용자 인증 정보를 별도로 설정합니다.
계정 소유자에게 대시보드 링크를 제공합니다 (https://mylookerinstance.cloud.looker.com/dashboards/17). 그리고 계정 소유자에게 브랜드 간에 대시보드를 전환하려면 다른 탭의 로그인 페이지로 돌아가서 다른 사용자 계정의 이메일 및 비밀번호 사용자 인증 정보를 입력하고 해당 탭에 대시보드를 다시 로드해야 한다고 알립니다.

계정 소유자는 안내를 따릅니다. 하지만 두 번째 브라우저 탭에 Hooli 사용자 계정의 사용자 이름과 비밀번호를 입력하고 Pied Piper 대시보드가 이미 로드된 첫 번째 탭으로 돌아가면 계정 소유자는 새로고침 버튼을 누릅니다. 계정 소유자는 놀랍게도 대시보드에 Hooli 데이터가 표시되는 것을 보게 됩니다. 동일한 시나리오가 임베딩 컨텍스트에서 실행되었기 때문에 이는 놀라운 일이 아닙니다.

후자의 구현(동일한 external_user_id test_user를 사용하지만 사용자 속성 집합이 다름)을 동일한 방식으로 빠르게 분류할 수 있습니다. 이 워크플로에 해당하는 UI는 다음과 같습니다.

계정 소유자에 대해 하나의 사용자 계정을 만듭니다.
pied_piper를 해당 사용자 계정의 브랜드 속성 값으로 설정합니다.
계정 소유자에게 대시보드를 Pied Piper에서 Hooli로 전환하려면 관리자에게 연락하여 관리자가 해당 사용자 계정의 수정 페이지로 이동하여 브랜드 속성 값을 pied_piper에서 hooli로 변경할 수 있도록 해야 한다고 안내합니다.
사용자 속성을 수정하면 새 탭에서 대시보드를 다시 로드하여 Hooli 데이터를 확인할 수 있습니다.

지금쯤 이렇게 생각하고 계실지도 모릅니다.

많은 작업을 해야 하는 것 같습니다! 단일 사용자 계정을 제공하여 사용자가 대시보드에서 각 브랜드별로 데이터를 개별적으로 필터링할 수 있도록 할 방법이 없나요?

물론 있습니다. 이러한 시나리오가 보여주는 것은 비임베딩 컨텍스트에서는 이미 단순하지만 임베딩 컨텍스트의 추상화로 인해 가려질 수 있는 원칙입니다. 단일 인간 사용자는 단일 사용자 속성 값 집합을 가진 단일 Looker 사용자 계정과 연결해야 합니다. 이는 서명된 임베딩 문서의 external_user_id 설명에서도 명확하게 확인할 수 있습니다.

Looker는 서명된 임베딩 사용자를 구분하기 위해 external_user_id를 사용하므로 각 사용자에게 할당된 고유한 ID가 있어야 합니다.

사용자별로 고유한 문자열을 사용하면 원하는 문자열을 사용하여 사용자의 external_user_id를 만들 수 있습니다. 각 ID는 권한, 사용자 속성, 모델 세트와 연결됩니다. 단일 브라우저는 한 번에 하나의 external_user_id 또는 사용자 세션만 지원할 수 있습니다. 세션 중에 사용자의 권한 또는 사용자 속성을 변경할 수 없습니다.

권장사항 적용

이러한 원칙을 이 예시에 적용하면 계정 소유자가 애플리케이션 전체에 액세스해야 하는 모든 데이터에 대한 액세스 권한을 부여하는 단일 사용자 속성 값이 필요합니다. 브랜드 속성 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"}
}

이 구문이 작동하려면 사용자 속성이 문자열 필터(고급)로 설정되어 있는지 확인해야 합니다.

데이터 액세스 수준에 변화가 있는 경우에도 사용자의 사용자 속성 집합을 변경할 수 있습니다. 예를 들어 계정 소유자가 세 번째 브랜드의 소유권을 가지고 있는 경우 해당 세 번째 브랜드를 브랜드 사용자 속성에 지정한 쉼표로 구분된 목록에 추가할 수 있습니다. 그렇게 하면 사용자가 로그아웃했다가 다시 로그인할 때 변경사항이 적용됩니다.

대시보드 결과 필터링

알겠습니다. 사용자 속성이 사용자가 애플리케이션 전반에 걸쳐 액세스할 수 있는 모든 데이터를 명시해야 한다는 것을 이해했습니다. 하지만 이 방식으로 사용자 속성을 지정하면 대시보드에 모든 브랜드의 데이터가 표시됩니다. 특정 대시보드의 결과 범위를 특정 브랜드로 좁히려면 어떻게 해야 하나요?

특정 대시보드를 필터링하는 올바른 방법은 일반 대시보드 필터를 사용하는 것입니다. (지금은 당연한 것처럼 보일 수 있지만 user_attributes 서명된 임베딩 URL의 매개변수이고 필터는 그렇지 않기 때문에 임베딩 컨텍스트에서 필터를 적용하는 유일한 방법으로 사용자 속성에 집중하는 사람도 있었습니다.)

필터 값이 필요하도록 설정하고 드롭다운과 같은 단일 선택 제어 옵션 중 하나를 사용하세요.

필요한 모든 타일의 올바른 필드에 필터가 적용되었는지 확인합니다.

이제 계정 소유자는 드롭다운에서 사용 가능한 옵션이 사용자 속성에 따라 제한되기 때문에 그 두 가지 값 중에서만 선택할 수 있습니다.

대시보드 필터 자동 입력

이제 대시보드를 특정 브랜드로 필터링할 수 있지만, 사용자가 내 앱에서 해당 브랜드의 대시보드를 로드할 때 이미 필터 값을 특정 브랜드로 설정하고 싶습니다.

다시 한번 비임베딩 컨텍스트에서 이것이 어떻게 작동하는지 생각해보면 도움이 됩니다. 특정 필터 값이 이미 적용된 대시보드로 연결되는 링크를 다른 사용자에게 보내려면 어떻게 해야 하나요? 필터 값을 선택하면 해당 필터 값이 대시보드의 URL에 표시되는 것을 이미 알아차렸을 것입니다.

create_sso_embed_url 호출의 target_url에 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"}
}

임베딩 SDK를 사용하는 경우 withFilters를 사용하여 임베딩된 콘텐츠에 적용할 초기 필터를 지정할 수 있습니다.

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

자체 커스텀 스크립트를 사용하는 경우 경로가 인코딩되기 전에 URL에 필터를 추가해야 합니다. 일부 값이 이미 필터 문자열에 인코딩되어 있을 수 있습니다(예: ?Brand=Pied+Piper에 +로 인코딩된 공백이 있음). 따라서 해당 값은 최종 URL에서 이중 인코딩됩니다. 'SO 임베딩된 대시보드 - URL의 일부로 대시보드 필터를 설정하시겠습니까?'를 확인합니다. 이러한 미묘한 차이에 대한 자세한 내용은 Looker 커뮤니티 게시물을 참조하세요. 그래도 필터를 적용하는 데 문제가 있다면 커뮤니티 게시물을 통해 질문을 추가하는 것이 좋습니다.

대시보드 필터 숨기기

대시보드의 초기 필터를 설정하는 방법을 이해했지만, 계정 소유자가 직접 대시보드 필터를 변경하지 못하게 하고 싶습니다—필터 값은 계정 소유자가 내 앱에서 탐색한 대시보드에 따라서만 결정되어야 합니다. 대시보드 필터를 숨기려면 어떻게 해야 하나요?

이를 위해 테마를 사용할 수 있습니다. 테마는 유료 기능이므로 Looker 인스턴스에서 아직 이 기능을 사용 설정하지 않은 경우 Looker 영업팀에 문의하여 사용 설정해야 합니다.

이 기능을 사용 설정하면 관리 - 테마 페이지의 대시보드 제어 섹션으로 이동하여 필터 표시줄 표시 옵션을 선택 해제할 수 있습니다.

그런 다음 테마를 기본값으로 설정하거나 특정 대시보드의 URL에 테마를 적용할 수 있습니다. 이번에도 create_sso_embed_url 호출의 target_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"}
}

일부 임베딩 SDK 코드 스니펫을 포함한 임베딩 대시보드 필터를 숨기는 방법에 대한 자세한 내용은 YouTube 튜토리얼 커스텀 필터를 사용한 임베딩 Looker를 참조하세요.

최종 결과는 원래 질문의 사용자 환경과 동일하게 표시되어야 합니다.

그러나 이제 필터 값이 앱에 임베딩된 각 대상 URL로 인코딩되기 때문에 탭을 오가는 경우에도 각 브랜드의 대시보드에는 항상 올바른 브랜드로 필터링된 대시보드가 표시됩니다.

다른 사용자로 가장

이제 사용자 환경이 원래 구상했던 것과 매우 비슷해졌습니다. 하지만 이 사용 사례에서 계정 소유자는 external_user_id=pied_piper 및 external_user_id=hooli가 있는 개별 사용자에게는 없는 다른 권한이 있고 기타 사용자 설정이 다릅니다. 이로 인해 UI에서 사용할 수 있는 옵션이 달라지고 전반적인 사용자 환경이 약간 달라집니다. 계정 소유자가 pied_piper 및 hooli 사용자가 보는 것과 동일하게(실제로 계정 소유자가 해당 사용자로 로그인한 것처럼) 모든 항목을 볼 수 있도록 하고 싶습니다. 어떻게 해야 하나요?

이러한 요청을 '가장'이라고 합니다. 계정 소유자가 각 개별 브랜드 사용자로 '가장'할 수 있도록 하려면 앱에서 비슷한 가장 기능을 빌드할 수 있습니다. 이렇게 하면 계정 소유자가 Pied Piper 사용자로 가장할 때는 external_user_id=pied_piper에 대한 임베딩 URL을, Hooli 사용자로 가장할 때는 external_user_id=hooli의 임베딩 URL을 로드하게 됩니다. 앱에서 API를 사용하는 경우 login_user API 엔드포인트를 사용하여 API에서 브랜드 사용자로 가장할 수도 있습니다.

그러나 비임베딩 컨텍스트에 대해 다시 생각해보겠습니다. 관리자 - 사용자 페이지의 여러 탭에서 여러 비임베딩 사용자로 동시에 가장할 수 없습니다. 가장 세션은 다른 모든 사용자 세션과 마찬가지로 전체 브라우저 창에 적용됩니다. 따라서 한 번에 한 명의 사용자만 가장할 수 있도록 가장을 설계해야 합니다. 또한 이 설계는 가장하는 사용자의 경험을 완벽하게 모방하는 것과 더 일관성이 있습니다. 예를 들어 pied_piper 사용자는 Pied Piper 대시보드에만 액세스할 수 있으며 추가 탭에서 추가 대시보드를 열 수 없습니다. 따라서 이 사용자로 가장할 때는 다른 탭에서 다른 대시보드를 열 수 있어서는 안 됩니다.

결론

이 가이드가 도움이 되었기를 바라며, Looker 서명 임베딩 콘텐츠를 빌드할 준비가 되었기를 바랍니다. Google은 Looker를 가장 유연하고 강력한 임베디드 데이터 분석 서비스로 만들기 위해 지속적으로 노력하고 있으며 사용자의 의견을 기다리고 있습니다. 궁금한 점이 있거나 자세히 알아보려면 Looker 커뮤니티에 참여하고 커뮤니티 이벤트에 참석하세요.