Nutzung
access_grant: access_grant_name {
user_attribute: user_attribute_name
allowed_values: [ "value_1", "value_2" , ... ]
}
|
Hierarchie
access_grant |
Standardwert
Keine
Akzeptiert
Der Name eines Nutzerattributs mit dem Unterparameter user_attribute und eine Liste von Nutzerattributwerten mit dem Unterparameter allowed_values
|
Definition
Eine Zugriffsgewährung ist eine LookML-Struktur, die in einer Modelldatei definiert ist und den Zugriff auf andere LookML-Strukturen steuert, insbesondere auf Explores, Joins, Ansichten und Felder. Der Parameter access_grant definiert eine Zugriffsberechtigung.
access_grant verwendet den Namen eines Nutzerattributs mit dem Unterparameter user_attribute und eine Liste der zulässigen Werte für das Nutzerattribut mit dem Unterparameter allowed_values. Nur Nutzer, denen einer der zulässigen Werte im angegebenen Nutzerattribut zugewiesen ist, können auf Strukturen zugreifen, für die das Zugriffsrecht erforderlich ist.
Nachdem Sie den Parameter definiert haben, können Sie ihn auf Explore-, Join-, View- oder Feldebene verwenden, um den Zugriff auf diese Strukturen zu gewähren.required_access_grants
Mit dem folgenden LookML wird beispielsweise eine Zugriffserteilung mit dem Namen can_view_financial_data erstellt, die auf dem Nutzerattribut department basiert. Nur Nutzer, denen die Werte "finance" oder "executive" im Benutzerattribut department zugewiesen sind, erhalten Zugriff auf das Zugriffsrecht can_view_financial_data:
access_grant: can_view_financial_data {
user_attribute: department
allowed_values: [ "finance", "executive" ]
}
Anschließend verknüpfen Sie die can_view_financial_data-Zugriffsberechtigung mit einer LookML-Struktur, indem Sie den Parameter required_access_grants verwenden:
dimension: financial_data_field
...
required_access_grants: [can_view_financial_data]
}
In diesem Beispiel sehen nur Nutzer, die den richtigen Benutzerattributwert für das Zugriffsrecht can_view_financial_data haben, die Dimension financial_data_field.
Sie können mehrere Zugriffsberechtigungen in einem Modell definieren und einer LookML-Struktur mit dem Parameter required_access_grants mehrere Zugriffsberechtigungen zuweisen. In diesem Fall muss ein Nutzer Zugriff auf alle angegebenen Zugriffsberechtigungen haben, um auf die LookML-Struktur zugreifen zu können.
Im folgenden LookML-Beispiel werden zwei verschiedene Zugriffsgewährungen definiert:
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" ]
}
In der Ansichtsdatei gibt der Parameter required_access_grants dann beide Zugriffsberechtigungen an:
view: payroll {
...
required_access_grants: [can_view_financial_data, can_view_payroll_data]
}
In diesem Fall können nur Nutzer auf die Ansicht zugreifen, denen entweder der Wert "finance" oder der Wert "executive" für das Nutzerattribut department zugewiesen ist und denen der Wert "yes" für das Nutzerattribut view_payroll zugewiesen ist.
Beispiele
Definieren Sie ein Zugriffsrecht, für das Nutzer entweder den Wert "product_management" oder den Wert "engineering" im Nutzerattribut department haben müssen, um Zugriff auf das Zugriffsrecht engineering zu erhalten:
access_grant: engineering {
user_attribute: department
allowed_values: [ "product_management", "engineering" ]
}
Sie können auch Zugriffsberechtigungen mit Nutzerattributen definieren, die numerische oder Datums-/Uhrzeitdaten verwenden. Dazu müssen Sie die zulässigen Werte in doppelte Anführungszeichen setzen, genau wie bei einem String. Im folgenden Beispiel für die Zugriffsgewährung wird auf das Nutzerattribut id verwiesen, das den Datentyp number hat. Nur Nutzer mit dem Wert 1, 2, 3, 4 oder 5 für id erhalten Zugriff:
access_grant: user_id {
user_attribute: id
allowed_values: ["1", "2", "3", "4", "5"]
}
Im folgenden Beispiel wird auf das Nutzerattribut start_date verwiesen, das den Datentyp Datum/Uhrzeit hat. Nur Nutzer mit dem Wert 2020-01-01 im Benutzerattribut erhalten Zugriff:
access_grant: start_date {
user_attribute: start_date
allowed_values: ["2020-01-01"]
}
Wichtige Punkte
Von Nutzern bearbeitbare Nutzerattribute sind bei Zugriffsberechtigungen nicht zulässig
Für Zugriffsrechte können keine Nutzerattribute mit der Zugriffsebene Bearbeiten verwendet werden. Nutzer können die Werte von Nutzerattributen mit der Nutzerzugriffsebene Bearbeiten auf ihrer Kontoseite ansehen und bearbeiten. Aus Sicherheitsgründen sind mit access_grant nur Nutzerattribute mit der User Access-Ebene None oder View zulässig.
Die in allowed_values aufgeführten Werte müssen genau mit den Werten der Nutzerattribute übereinstimmen.
access_grant funktioniert mit Nutzerattributen, die den Datentyp String-Filter (erweitert), Zahlenfilter (erweitert) oder Datums-/Zeitfilter (erweitert) haben. Damit Zugriff gewährt werden kann, müssen die im allowed_values-Parameter aufgeführten Werte genau mit dem Wert im Nutzerattribut übereinstimmen.
Wenn Sie beispielsweise ein Nutzerattribut namens numeric_range mit dem Datentyp Numerischer Filter (erweitert) erstellt haben, können Sie mit einem Looker-Filterausdruck einen Zahlenbereich eingeben, z. B. [1, 20]. In diesem Beispiel gibt der Looker-Filterausdruck im Nutzerattribut einen Bereich von Zahlen zwischen 1 und 20 zurück. Da für access_grant eine genaue Übereinstimmung erforderlich ist, würde die Verwendung des Parameters allowed_values: ["10"] jedoch keinen Zugriff gewähren. Um Zugriff zu gewähren, müssen Sie allowed_values: ["[1, 20]"] verwenden.
Das gilt auch für Nutzerattribute mit mehreren Werten. Ein Nutzerattribut mit dem Datentyp Number Filter (advanced) und dem Wert 1, 3, 5 würde nur einer Zugriffsberechtigung mit dem Parameter allowed_values: ["1, 3, 5"] entsprechen. Ebenso würde ein Zugriffsrecht mit dem Parameter allowed_values: ["1"] keinen Zugriff für den Nutzer mit mehreren Werten im Nutzerattribut gewähren. Auch eine Zugriffsberechtigung mit dem Parameter allowed_values: ["1", "3", "5"] würde keinen Zugriff für diesen Nutzer gewähren, da der Parameter allowed_values: [] zwar mehrere Werte akzeptieren kann, aber keiner der drei Werte im Parameter allowed_values: ["1", "3", "5"] genau mit dem Nutzerattributwert 1, 3, 5 übereinstimmt. In diesem Fall erhält ein Nutzer mit dem Nutzerattributwert 1, 3 oder 5 Zugriff, da jeder dieser Werte mit einer der Optionen im Parameter allowed_values: ["1", "3", "5"] übereinstimmt.
Für access_grant ist ebenfalls eine genaue Übereinstimmung mit Nutzerattributen des Datentyps String-Filter (erweitert) erforderlich. Im Gegensatz zu typischen Looker-Filterausdrücken wird mit dem Parameter allowed_values: [ "Ca%" ] kein Nutzerattribut mit den Werten Canada oder California abgeglichen. Nur ein Nutzerattributwert von genau Ca% würde abgeglichen und Zugriff gewährt.
Nutzer, denen kein Zugriff gewährt wird, sehen je nach LookML-Struktur unterschiedliche Inhalte.
Ein Nutzer, der keinen Zugriff auf eine Zugriffsberechtigung hat, erlebt je nach LookML-Struktur, auf die er zugreifen möchte, ein anderes Verhalten. Informationen dazu, wie der Zugriff auf diese Strukturen eingeschränkt wird, finden Sie in der required_access_grants-Dokumentation auf der Ebene Explore, Join, View oder Feld.
Zugriffsberechtigungen auf mehreren Ebenen werden addiert
Wenn Sie Zugriffsrechte verschachteln, sind sie additiv. Sie können beispielsweise required_access_grants für eine Ansicht und required_access_grants für ein Feld in der Ansicht erstellen. Damit ein Nutzer das Feld sehen kann, muss er Zugriffsberechtigungen für das Feld und die Ansicht haben. Das gilt auch für Joins: Wenn Sie required_access_grants für die Ansichten in einem Join und auch required_access_grants für den Join dieser beiden Ansichten erstellen, muss ein Nutzer Zugriff auf beide Ansichten und den Join haben, um die zusammengeführte Ansicht zu sehen.
Auf Strukturen zugreifen, die auf eingeschränkte Strukturen verweisen
Nutzer können Zugriff auf Looks oder Dashboards haben, die LookML-Objekte enthalten, auf die sie keinen Zugriff haben. In diesen Fällen werden Look oder Dashboard so angezeigt, als wären die LookML-Objekte aus dem Modell entfernt worden.
Angenommen, wir haben ein Explore A, das den Join A, die Ansicht A und das Feld A enthält. Als Nächstes schränken wir den Zugriff auf Explore A ein. Wie erwartet wird diese Einschränkung für Join A, View A und Feld A übernommen, aber nur, wenn Nutzer mit Explore A interagieren. Wenn Join A, Ansicht A oder Feld A in einem anderen Explore B verwendet wird, gelten nicht unbedingt Zugriffsbeschränkungen. Wenn Sie LookML-Elemente wiederverwenden möchten, empfehlen wir, Zugriffsbeschränkungen auf der niedrigsten möglichen Ebene anzuwenden.