Uso
access_grant: access_grant_name {
user_attribute: user_attribute_name
allowed_values: [ "value_1", "value_2" , ... ]
}
|
Hierarquia
access_grant |
Valor padrão
Nenhum
Aceita
O nome de um atributo do usuário com o subparâmetro user_attribute e uma lista de valores de atributos do usuário com o subparâmetro allowed_values
|
Definição
Uma concessão de acesso é uma estrutura do LookML definida em um arquivo de modelo que controla o acesso a outras estruturas do LookML, especificamente Análises, junções, visualizações e campos. O parâmetro access_grant define uma concessão de acesso.
access_grant usa o nome de um atributo do usuário com o subparâmetro user_attribute e uma lista de valores aceitáveis para o atributo do usuário com o subparâmetro allowed_values. Somente os usuários que receberem um dos valores permitidos no atributo especificado poderão acessar as estruturas em que a concessão de acesso é necessária.
Depois de definido, você pode usar o parâmetro required_access_grants no nível da análise detalhada, da junção, da visualização ou do campo para exigir a concessão de acesso a essas estruturas.
Por exemplo, o LookML a seguir cria uma concessão de acesso chamada can_view_financial_data, que se baseia no atributo do usuário department. Somente os usuários que recebem os valores "finance" ou "executive" no atributo do usuário department têm acesso à concessão de acesso can_view_financial_data:
access_grant: can_view_financial_data {
user_attribute: department
allowed_values: [ "finance", "executive" ]
}
Em seguida, associe a concessão de acesso can_view_financial_data a uma estrutura do LookML usando o parâmetro required_access_grants:
dimension: financial_data_field
...
required_access_grants: [can_view_financial_data]
}
Neste exemplo, somente os usuários que têm o valor de atributo correto para a concessão de acesso can_view_financial_data vão ver a dimensão financial_data_field.
É possível definir várias concessões de acesso em um modelo e atribuir várias concessões de acesso a uma estrutura do LookML com o parâmetro required_access_grants. Nesse caso, um usuário precisa ter acesso a todas as concessões de acesso especificadas para acessar a estrutura do LookML.
Por exemplo, a LookML a seguir define duas concessões de acesso diferentes:
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" ]
}
Em seguida, no arquivo de visualização, o parâmetro required_access_grants especifica as duas concessões de acesso:
view: payroll {
...
required_access_grants: [can_view_financial_data, can_view_payroll_data]
}
Nesse caso, somente os usuários que têm o valor "finance" ou "executive" atribuído ao atributo de usuário department e têm o valor "yes" atribuído ao atributo de usuário view_payroll podem acessar a visualização.
Exemplos
Defina uma concessão de acesso que exija que os usuários tenham o valor "product_management" ou "engineering" no atributo de usuário department para ter acesso à concessão engineering:
access_grant: engineering {
user_attribute: department
allowed_values: [ "product_management", "engineering" ]
}
Também é possível definir concessões de acesso com atributos de usuário que usam dados numéricos ou de data/hora. Para isso, coloque os valores permitidos entre aspas duplas, assim como faria com uma string. Por exemplo, a concessão de acesso a seguir faz referência ao atributo do usuário id, que tem um tipo de dados de número. Somente os usuários com o valor 1, 2, 3, 4 ou 5 em id terão acesso:
access_grant: user_id {
user_attribute: id
allowed_values: ["1", "2", "3", "4", "5"]
}
O exemplo a seguir faz referência ao atributo do usuário start_date, que tem o tipo de dados Data/hora. Somente os usuários que têm o valor 2020-01-01 no atributo de usuário vão receber acesso:
access_grant: start_date {
user_attribute: start_date
allowed_values: ["2020-01-01"]
}
Informações importantes
Não é permitido usar atributos de usuário editáveis com concessões de acesso
As concessões de acesso não podem aceitar atributos de usuário com um nível de acesso do usuário de edição. Os usuários podem ver e editar os valores dos atributos que têm um nível de Acesso do usuário de Edição na página da conta. Por motivos de segurança, somente atributos de usuário com um nível de Acesso do usuário Nenhum ou Visualizar são permitidos com access_grant.
Os valores listados em allowed_values precisam corresponder exatamente aos valores dos atributos do usuário
O access_grant funciona com atributos do usuário que têm o tipo de dados Filtro de string (avançado), Filtro de número (avançado) ou Filtro de data/hora (avançado). No entanto, para conceder acesso, os valores listados no parâmetro allowed_values precisam corresponder exatamente ao valor no atributo do usuário.
Por exemplo, se você criou um atributo do usuário chamado numeric_range com o tipo de dados Filtro de número (avançado), pode usar uma expressão de filtro do Looker para inserir um intervalo de números, como [1, 20]. Nesse exemplo, a expressão de filtro do Looker no atributo do usuário vai retornar um intervalo de números entre 1 e 20, inclusive. Como access_grant exige uma correspondência exata, o uso do parâmetro allowed_values: ["10"] não concede acesso. Para conceder acesso, você precisaria usar allowed_values: ["[1, 20]"].
Isso também vale para atributos de usuário com vários valores. Por exemplo, um atributo de usuário com o tipo de dados Filtro de número (avançado) e o valor 1, 3, 5 só corresponderia a uma concessão de acesso com o parâmetro allowed_values: ["1, 3, 5"]. Da mesma forma, uma concessão de acesso com o parâmetro allowed_values: ["1"] não concederia acesso ao usuário com vários valores no atributo de usuário. Uma concessão de acesso com o parâmetro allowed_values: ["1", "3", "5"] também não concederia acesso a esse usuário. Embora o parâmetro allowed_values: [] possa aceitar vários valores, nenhum dos três valores no parâmetro allowed_values: ["1", "3", "5"] corresponde exatamente ao valor do atributo do usuário 1, 3, 5. Nesse caso, um usuário com um valor de atributo de 1, 3 ou 5 receberia acesso, já que cada um desses valores corresponde a uma das opções no parâmetro allowed_values: ["1", "3", "5"].
Da mesma forma, access_grant exige uma correspondência exata com os atributos do usuário do tipo de dados Filtro de string (avançado). Ao contrário das expressões de filtro do Looker típicas, o uso do parâmetro allowed_values: [ "Ca%" ] não corresponde a um atributo do usuário com os valores Canada ou California. Somente um valor de atributo do usuário exatamente igual a Ca% seria correspondente e receberia acesso.
Os usuários que não têm acesso apresentam comportamentos diferentes dependendo da estrutura do LookML
Um usuário sem acesso a uma concessão de acesso terá um comportamento diferente dependendo da estrutura LookML que estiver tentando acessar. Consulte as páginas de documentação do required_access_grants nos níveis Explorar, junção, visualização ou campo para saber como o acesso a essas estruturas é restrito.
As concessões de acesso em vários níveis são adicionadas
Se você aninhar permissões de acesso, elas serão aditivas. Por exemplo, é possível criar required_access_grants para uma visualização e required_access_grants para um campo dentro da visualização. Para ver o campo, o usuário precisa ter concessões de acesso ao campo e à visualização. Da mesma forma para junções: se você criar required_access_grants para as visualizações em uma junção e também criar required_access_grants para a junção dessas duas visualizações, um usuário precisará ter concessões de acesso às duas visualizações e à junção para ver a visualização unida.
Acessar estruturas que referenciam estruturas restritas
Os usuários podem ter acesso a Looks ou dashboards que contêm objetos do LookML a que não têm acesso. Nessas situações, o Look ou painel vai aparecer como se esses objetos do LookML tivessem sido removidos do modelo.
Suponha que temos uma Análise A, que contém junção A, visualização A e campo A. Em seguida, colocamos uma restrição de acesso no Explorar A. Como esperado, a junção A, a visualização A e o campo A vão herdar essa restrição, mas apenas quando os usuários interagirem com a análise detalhada A. Se a junção A, a visualização A ou o campo A forem usados em outra análise detalhada B, eles não terão necessariamente restrições de acesso. Portanto, se você planeja reutilizar elementos da LookML, recomendamos que aplique restrições de acesso no nível mais baixo possível.