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

임베딩된 Looker 콘텐츠에 대한 행 수준 세분화 구현

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

행 수준 세분화를 사용하면 데이터베이스 필드 하나 이상에 저장된 값을 기반으로 개별 사용자가 액세스할 수 있는 데이터를 제한할 수 있습니다. 이 가이드에서는 임베딩된 Looker 콘텐츠에서 행 수준 세분화를 구현하는 방법을 설명하고 다음 섹션을 포함합니다.

소개
- 사용 사례 개요
- 자세히 살펴보기
Looker 서명된 임베딩의 기본사항
- 서명된 임베딩 URL 구조
동시에 여러 브랜드에 액세스
- 비임베딩 관점에서의 접근 방식
- 동시에 여러 브랜드에 액세스 - 금지사항
권장사항 사용
결론

소개

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

이 가이드에서는 Looker 임베딩 기능의 설계와 파트너가 여러 브랜드에 대한 액세스를 관리할 수 있는 애플리케이션에 세분화를 구현하는 방법을 설명합니다. 주제를 심층적으로 다루는 데는 시간이 오래 걸립니다. 이 가이드는 특정 문제의 빠른 해결 방법을 위한 것이 아니라 전체 Looker 임베딩 사용 사례를 관리하는 데 유용한 구성 요소라는 점을 참고하시기 바랍니다.

사용 사례 개요

이 가이드에서는 회사에서 제품 내에 Looker 콘텐츠를 임베딩하고 서로 다른 데이터 슬라이스를 확인해야 하는 사용자 세그먼트를 서빙하는 일반적인 사용 사례를 설명합니다.

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

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

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

이 Explore를 기반으로 하는 대시보드가 있으며 이 대시보드에는 타일 2개가 있습니다. 하나에는 브랜드 이름이 표시되고 다른 하나에는 해당 브랜드의 제품 수가 표시됩니다.

create_sso_embed_url 엔드포인트를 사용하여 각 임베딩 사용자에 대해 이 대시보드의 임베딩 URL을 생성합니다. 이 예시에서는 Pied Piper와 Hooli라는 두 가지 브랜드를 사용합니다. 다음은 Pied Piper의 create_sso_embed_url 호출에 사용하는 요청 본문이며 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"}
}

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 브랜드를 모두 관리합니다.

비임베딩 관점에서의 접근 방식

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

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

파트너가 안내를 따릅니다. 하지만 두 번째 브라우저 탭에 Hooli 사용자 계정의 사용자 이름과 비밀번호를 입력하고 Pied Piper 대시보드가 이미 로드된 첫 번째 탭으로 돌아간 후 파트너가 새로고침 버튼을 누릅니다. 파트너는 놀랍게도 대시보드에 Hooli 데이터가 표시되는 것을 보게 됩니다.

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

이렇게 하면 불편한데 최선의 방법이 없을까?

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

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

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

동시에 여러 브랜드에 액세스 - 금지사항

맞춤설정 가능한 솔루션과 마찬가지로 피해야 하는 특정 방법이 있습니다. 예를 들어 앱이 앞에서 표시된 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를 사용합니다. 하지만 동작은 동일합니다. 탭을 Pied Piper 대시보드로 새로고침하면 Hooli의 데이터가 대신 표시됩니다.

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

권장사항 사용

'비임베딩 관점에서의 접근 방식' 섹션에 설명된 접근 방식을 적용하려면 파트너가 애플리케이션 전반에서 액세스해야 하는 모든 데이터에 대한 액세스 권한을 부여하는 단일 사용자 속성 값이 필요합니다. 브랜드 속성의 쉼표로 구분된 값 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을 로드하는 유사한 sudo 함수를 앱에 빌드하면 됩니다. 또한 앱에서 API를 사용하는 경우 login_user API 엔드포인트를 사용하여 API를 브랜드 사용자로 가장할 수 있습니다.

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

결론

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