Vérifier l'accès des membres

Utilisez cette skill pour répondre à « que peut faire cette personne ici ? » à partir des outils de contrôle d'accès. Les outils retournent le niveau appliqué et sa source. Cette skill permet de les interpréter correctement.

Quand utiliser cette skill

• « Que peut faire ce membre dans ce projet ? » / « Ce membre peut-il modifier les feature flags ? »
• « Qui peut modifier les dashboards ? » / « Qui n'a accès à aucune expérience ? »
• « Pourquoi ce membre ne peut pas ouvrir ce dashboard ? » / « De quelles tables ce rôle est-il exclu ? »
• « Quelles propriétés sont masquées au rôle support ? »
• « Que donne le rôle analyst ? » / « Quel est l'accès par défaut dans ce projet ? »

Non pour modifier les règles. Les outils de lecture ne peuvent pas écrire, et c'est la page des paramètres où les règles sont modifiées.

Disponibilité par plan

• Les plans gratuit et à l'usage n'ont pas de contrôle d'accès, et les outils de contrôle d'accès ne leur sont pas proposés. Si les outils manquent du catalogue, dites que le plan n'inclut pas le contrôle d'accès et suggérez une mise à niveau vers le plan Boost. Consultez la comparaison des plans : https://posthog.com/platform-packages.
• Boost et Scale incluent les niveaux par défaut et les règles pour les membres individuels sur le projet, sur les outils, sur les objets et sur les propriétés.
• Les rôles existent sur tous les plans, mais les règles de rôles sont une fonctionnalité Enterprise : elles ne peuvent être définies et appliquées que là, et les trois outils d'accès par rôles ne sont proposés que là. Si les outils manquent, dites que le contrôle d'accès basé sur les rôles nécessite le plan Enterprise, avec le même lien. Sur les autres plans, les rôles d'un membre ne changent jamais le niveau appliqué.
• Les outils n'indiquent pas quel plan l'organisation utilise. Une source_subject de role n'importe où dans un résultat members-list prouve que les règles de rôles sont appliquées. Sans cela, demandez à l'utilisateur si l'organisation est sur Enterprise avant de parcourir les rôles à l'étape 4 du flux.

Comment l'accès se résout

• Étendues. Le projet lui-même, puis chaque outil (dashboard, insight, feature_flag, notebook, experiment, warehouse_objects, etc.), puis les objets individuels dans un outil, puis les propriétés des personnes et événements. Les noms d'outils sont les clés de resources dans une entrée members-list.
• Niveaux de projet. member peut voir et modifier les ressources que leurs autres règles permettent. admin peut aussi modifier les paramètres du projet, gérer les règles d'accès du projet et supprimer le projet.
• Niveaux d'outil et d'objet. none ne peut pas voir. viewer peut voir mais pas modifier. editor peut voir et modifier. manager peut aussi gérer les règles d'accès de l'outil ou de l'objet. Ordre : none < viewer < editor < manager.
• Niveaux de propriété. none masque la propriété. read l'affiche. read_write permet aussi les modifications. Chaque propriété est read_write sauf si une règle existe.
• Bornes. minimum et maximum par outil, sur defaults-get, sont les niveaux qu'une règle peut définir. Un outil avec minimum viewer ne peut jamais être défini à none.
• Sujets. Une règle appartient à un membre, un rôle, ou tout le monde dans le projet (par défaut).
• Admins et propriétaires de l'organisation ont un accès complet à tout dans chaque projet. Aucune règle ne s'applique à eux. organization_level est un nombre : 1 membre, 8 admin, 15 propriétaire.
• Créateurs ont un accès complet aux objets qu'ils ont créés, et seulement ceux-là. Un membre avec viewer sur les dashboards peut quand même modifier le dashboard qu'il a créé, et ne peut pas modifier les autres.
• Deux modes de résolution. Les organisations résolvent les règles soit du plus spécifique au plus général (règle membre, puis règles rôles, puis défaut, et règle d'objet avant règle d'outil), soit en mode legacy (le plus élevé entre la propre règle du membre et ses règles rôles gagne). Les outils ne disent pas quel mode s'applique. Le serveur l'a déjà appliqué. Donc faites confiance à effective_access_level et ne le recalculez jamais à partir des règles stockées. Si l'utilisateur demande pourquoi, expliquez à partir de inherited_access, pas à partir de votre propre ordre de préséance.

Outils disponibles

Tous les outils de contrôle d'accès acceptent un id de projet optionnel et utilisent le projet actif par défaut.

Flux

1. Trouvez l'id du sujet. member_id est l'id d'adhésion à l'organisation : l'id de org-members-list, ou organization_membership_id de members-list. Ce n'est pas l'id utilisateur ni l'uuid utilisateur. role_id est l'id de roles-list.
2. Les questions au niveau de l'outil nécessitent un appel. « Ce membre peut-il voir les dashboards ? » ou « Quel accès aux feature flags ce membre a-t-il ? » est members-list avec member_id. L'effective_access_level pour cet outil est la réponse complète. Il inclut déjà les rôles du membre, le défaut du projet et les contournements.
3. Expliquez le niveau à partir de inherited_access. Voir le tableau ci-dessous. Ne mentionnez l'access_level stocké que s'il diffère du niveau appliqué.
4. Les questions sur les objets nécessitent l'objet et ses règles. « Ce membre peut-il ouvrir le dashboard 42 ? » ne peut pas être répondu au niveau de l'outil seul. Vérifiez dans cet ordre, et arrêtez au premier résultat :
   1. organization_level est 8 ou 15 sur l'entrée du membre : accès complet, aucune règle ne s'applique.
   2. Le membre a créé l'objet : accès complet, aucune règle ne s'applique. Les outils de règles ne disent pas qui a créé un objet, donc récupérez-le avec son outil get, par exemple dashboard-get ou insight-get, et comparez created_by.uuid avec user.uuid sur l'entrée du membre.
   3. Une règle sur cet objet. Les outils de membre ne retournent que les règles définies pour ce membre, donc collectez member-objects-list, role-objects-list pour chaque id dans les role_ids du membre, et default-objects-list, et sélectionnez les lignes pour cet objet. Dites à l'utilisateur combien de rôles vous devriez parcourir et demandez avant de le faire pour un membre dans de nombreux rôles.
   4. Aucune règle sur l'objet : la réponse au niveau de l'outil de l'étape 2 s'applique.
5. Plusieurs règles sur un objet. Quand le membre, un rôle et le défaut définissent chacun un niveau sur le même objet, le serveur en choisit un selon le mode de résolution de l'organisation, et aucun outil ne retourne ce choix pour un autre membre. Signalez chaque règle que vous avez trouvée avec son sujet, dites que l'appliquée dépend du mode, et ne devinez pas. Les questions de propriété fonctionnent comme l'étape 4 avec les outils de propriétés, moins la vérification du créateur, puisque les propriétés n'ont pas de créateur.
6. Les questions « Qui peut ... » sont members-list sans member_id, filtrées sur resources.<tool>.effective_access_level. La réponse est chaque membre fois chaque outil et n'a pas de pagination. Pour une grande organisation, demandez d'abord qui l'utilisateur doit vérifier, ou répondez par membre.

Lire une entrée

Comment formuler la réponse :

• source est org_admin : « Ce membre est un admin de l'organisation et a un accès complet à tout. » Les règles stockées ne s'appliquent pas à eux.
• access_level est défini et égal à effective_access_level : « Ce membre a une règle explicite : editor. »
• access_level est null et source_subject est role : « Ce membre a l'accès editor, basé sur un rôle. » Le nom du rôle n'est pas dans l'entrée ; roles-list l'a si l'utilisateur le veut.
• access_level est null et source_subject est default : « Ce membre a l'accès viewer, basé sur le défaut du projet. »
• source est system_default : « Aucune règle n'est définie nulle part, donc le défaut PostHog s'applique. »
• effective_access_level est null : « Rien ne se résout pour cet outil ici. » Ne le lisez pas comme pas d'accès.

Pièges

• Une liste d'objets ou de propriétés vide signifie pas de règles de ce type, pas pas d'accès. L'entrée au niveau de l'outil s'applique toujours.
• Un membre manquant de members-list n'est pas une preuve de pas d'accès. Un appelant qui n'est pas un admin de l'organisation, dans une organisation où les membres ne se voient pas, ne voit que les membres avec accès scoped au projet.
• can_edit sur les listes de membres et de rôles décrit l'appelant, pas le sujet : si la personne exécutant l'outil peut modifier les règles.
• available_project_levels et available_resource_levels sont le vocabulaire, du plus bas au plus élevé. Utilisez-les pour comparer les niveaux au lieu d'assumer un ordre.
• object_rule_resources sur defaults-get liste les outils qui acceptent les règles sur les objets individuels. Un outil qui n'est pas dans cette liste n'a pas de règles d'objet à chercher.