accesso_concesso

Utilizzo

access_grant: access_grant_name {
user_attribute: user_attribute_name
allowed_values: [ "value_1", "value_2" , ... ]
}
Gerarchia
access_grant
Valore predefinito
Nessuna

Accetta
Il nome di un attributo utente con il sottoparametro user_attribute e un elenco di valori degli attributi utente con il sottoparametro allowed_values

Definizione

Una concessione di accesso è una struttura LookML che controlla l'accesso ad altre strutture LookML, in particolare Explore, join, visualizzazioni e campi. Il parametro access_grant definisce una concessione di accesso.

access_grant assume il nome di un attributo utente con il sottoparametro user_attribute e un elenco di valori accettabili per l'attributo utente con il sottoparametro allowed_values. Solo gli utenti a cui è assegnato uno dei valori consentiti nell'attributo utente specificato possono accedere alle strutture a cui è richiesta la concessione dell'accesso.

Una volta definiti, puoi utilizzare il parametro required_access_grants a livello di Esplora, join, view o field per richiedere l'accesso a queste strutture.

Ad esempio, il codice LookML riportato di seguito crea una concessione di accesso denominata can_view_financial_data, basata sull'attributo utente department. Solo agli utenti a cui sono assegnati i valori "finance" o "executive" nell'attributo utente department è concesso l'accesso alla concessione can_view_financial_data:

access_grant: can_view_financial_data {
  user_attribute: department
  allowed_values: [ "finance", "executive" ]
}

Associa quindi la concessione dell'accesso can_view_financial_data a una struttura LookML utilizzando il parametro required_access_grants:

dimension: financial_data_field
  ...
  required_access_grants: [can_view_financial_data]
}

Nell'esempio precedente, solo gli utenti con il valore dell'attributo utente corretto per la concessione dell'accesso a can_view_financial_data vedranno la dimensione financial_data_field.

Puoi definire più concessioni di accesso in un modello e assegnarle a una struttura LookML con il parametro required_access_grants. In quel caso, un utente deve poter accedere a tutte le concessioni di accesso specificate per poter accedere alla struttura LookML.

Ad esempio, il codice LookML di seguito definisce due diverse concessioni di accesso:

access_grant: can_view_financial_data {
  user_attribute: department
  allowed_values: [ "finance", "executive" ]
}

access_grant: can_view_payroll_data {
  user_attribute: view_payroll
  allowed_values: [ "yes" ]
}

Successivamente, nel file di visualizzazione in basso, il parametro required_access_grants specifica entrambe le concessioni di accesso:

view: payroll {
  ...
  required_access_grants: [can_view_financial_data, can_view_payroll_data]
}

In questo caso, solo gli utenti a cui è stato assegnato il valore "finance" o il valore "executive" all'attributo department utente e il valore "yes" assegnato all'attributo utente view_payroll possono accedere alla vista.

Esempi

Definisci una concessione di accesso che richiede agli utenti di avere il valore "product_management" o il valore "engineering" nell'attributo utente department per poter accedere alla concessione di accesso engineering:

access_grant: engineering {
  user_attribute: department
  allowed_values: [ "product_management", "engineering" ]
}

Puoi anche definire le concessioni di accesso utilizzando gli attributi utente che utilizzano dati numerici o di data/ora. Per farlo, devi racchiudere i valori consentiti tra virgolette doppie, proprio come faresti con una stringa. Ad esempio, la seguente concessione di accesso fa riferimento all'attributo utente id, che ha un tipo di dati pari a number. Verrà concesso l'accesso solo agli utenti con il valore id pari a 1, 2, 3, 4 o 5:

access_grant: user_id {
  user_attribute: id
  allowed_values: ["1", "2", "3", "4", "5"]
}

L'esempio seguente fa riferimento all'attributo utente start_date, che ha il tipo di dati Date/Time. Verrà concesso l'accesso solo agli utenti che dispongono del valore 2020-01-01 nell'attributo utente:

access_grant: start_date {
  user_attribute: start_date
  allowed_values: ["2020-01-01"]
}

Aspetti da considerare

Gli attributi utente modificabili dagli utenti non sono consentiti con le concessioni di accesso

Le concessioni di accesso non possono accettare attributi utente con un livello di accesso utente pari a Modifica. Gli utenti possono vedere e modificare i valori degli attributi utente che hanno un livello di Accesso utente pari a Modifica nella loro pagina account. Per motivi di sicurezza, con access_grant è consentito utilizzare solo gli attributi utente con livello di accesso utente pari a Nessuno o Vista.

I valori elencati in allowed_values devono corrispondere esattamente ai valori degli attributi utente

access_grant funzionerà con gli attributi utente che hanno il tipo di dati Filtro stringa (avanzato), Filtro numero (avanzato) o Filtro data/ora (avanzato). Tuttavia, per concedere l'accesso, i valori elencati nel parametro allowed_values devono corrispondere esattamente al valore dell'attributo utente.

Ad esempio, se hai creato un attributo utente denominato numeric_range con il tipo di dati Filtro numero (avanzato), puoi utilizzare un'espressione di filtro Looker per inserire un intervallo di numeri, come [1, 20]. In questo esempio, l'espressione di filtro di Looker nell'attributo utente restituirà un intervallo di numeri compreso tra 1 e 20 inclusi. Poiché access_grant richiede una corrispondenza esatta, l'utilizzo del parametro allowed_values: ["10"] non concede l'accesso. Per concedere l'accesso, devi utilizzare allowed_values: ["[1, 20]"].

Questo vale anche per gli attributi utente che hanno più valori. Ad esempio, un attributo utente con il tipo di dati Filtro numero (avanzato) in base al valore 1, 3, 5 corrisponderebbe solo a una concessione di accesso con il parametro allowed_values: ["1, 3, 5"]. Analogamente, una concessione di accesso con il parametro allowed_values: ["1"] non concederà l'accesso all'utente con più valori nell'attributo utente. Né una concessione di accesso con il parametro allowed_values: ["1", "3", "5"] concede l'accesso a questo utente perché, mentre il parametro allowed_values: [] accetta più valori, nessuno dei tre valori nel parametro allowed_values: ["1", "3", "5"] corrisponde esattamente al valore dell'attributo utente 1, 3, 5. In questo caso, a un utente con valore dell'attributo utente 1, 3 o 5 verrebbe concesso l'accesso, poiché ognuno di questi valori corrisponde a una delle opzioni del parametro allowed_values: ["1", "3", "5"].

Allo stesso modo, access_grant richiede una corrispondenza esatta con gli attributi utente del tipo di dati Filtro stringa (avanzato). A differenza delle tipiche espressioni di filtro di Looker, l'utilizzo del parametro allowed_values: [ "Ca%" ] non corrisponde a un attributo utente con i valori Canada o California. Solo un valore di attributo utente pari esattamente a Ca% verrebbe abbinato e ottenuto l'accesso.

Gli utenti a cui non viene concesso l'accesso registrano un comportamento diverso a seconda della struttura di LookML

Un utente che non ha accesso a una concessione di accesso avrà un comportamento diverso a seconda della struttura LookML a cui sta tentando di accedere. Consulta le pagine della documentazione required_access_grants a livello di esplorazione, unione, visualizzazione o campo per informazioni su come l'accesso a queste strutture è limitato.

Le concessioni di accesso a più livelli vengono sommate

Se nidificate, le concessioni di accesso sono additive. Ad esempio, puoi creare required_access_grants per una vista e required_access_grants per un campo all'interno della vista. Per vedere il campo, un utente deve disporre delle autorizzazioni di accesso sia al campo sia alla vista. Allo stesso modo per gli join: se crei required_access_grants per le viste in un join e crei anche required_access_grants per l'unione di queste due viste, un utente deve disporre delle autorizzazioni di accesso a entrambe le viste e all'unione per vedere la vista unita.

Accesso alle strutture che fanno riferimento a strutture limitate

Gli utenti possono accedere a Look o dashboard che contengono oggetti LookML a cui non hanno accesso. In queste situazioni, l'aspetto o la dashboard vengono visualizzati come se gli oggetti LookML fossero stati rimossi dal modello.

Supponiamo di avere un'esplorazione A, contenente l'unione A, la vista A e il campo A. In seguito, applichiamo una limitazione di accesso su Esplora A. Come previsto, unisciti a A, alla vista A e il campo A erediterà questa restrizione, ma solo quando gli utenti interagiscono con Esplora A. Se utilizzi la vista A, la vista A o il campo A in un'altra esplorazione B, non verranno necessariamente applicate restrizioni di accesso. Pertanto, se prevedi di riutilizzare gli elementi LookML, ti consigliamo di applicare le restrizioni di accesso al livello più basso possibile.