Skip to content

perform-list-users.mdx

Latest commit

 

History

History
300 lines (223 loc) · 10.8 KB

perform-list-users.mdx

File metadata and controls

300 lines (223 loc) · 10.8 KB
Raw
title Perform a List Users call
sidebar_position 4
slug /getting-started/perform-list-users
description List all users that have a certain relation with a particular object

import { SupportedLanguage, languageLabelMap, ListUsersRequestViewer, DocumentationNotice, ProductConcept, ProductName, ProductNameFormat, RelatedSection, SdkSetupHeader, SdkSetupPrerequisite, } from '@components/Docs'; import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem';

Perform a List Users call

This section will illustrate how to perform a request. The List Users call allows you to retrieve a list of that have a specific with a given . This can be used in scenarios such as retrieving users who have access to a resource or managing members in a group.

Before You Start

  2. You have installed the SDK.
  3. You have configured the authorization model and updated the relationship tuples.
  4. You have loaded FGA_STORE_ID and FGA_API_URL as environment variables.
  2. You have installed the SDK.
  3. You have configured the authorization model and updated the relationship tuples.
  4. You have loaded FGA_STORE_ID and FGA_API_URL as environment variables.
  2. You have installed the SDK.
  3. You have configured the authorization model and updated the relationship tuples.
  4. You have loaded FGA_STORE_ID and FGA_API_URL as environment variables.
  2. You have installed the SDK.
  3. You have configured the authorization model and updated the relationship tuples.
  4. You have loaded FGA_STORE_ID and FGA_API_URL as environment variables.
  2. You have installed the SDK.
  3. You have configured the authorization model and updated the relationship tuples.
  4. You have loaded FGA_STORE_ID and FGA_API_URL as environment variables.
  2. You have configured the authorization model.
  3. You have loaded FGA_STORE_ID and FGA_API_URL as environment variables.
  2. You have configured the authorization model and updated the relationship tuples.
  3. You have loaded FGA_STORE_ID and FGA_API_URL as environment variables.

Step by step

Consider the following model which includes a user that can have a reader relationship with a document:

model
  schema 1.1

type user

type document
  relations
    define reader: [user]

Assume that you want to list all users of type user that have a reader relationship with document:planning:

01. Configure the API client

Before calling the List Users API, you will need to configure the API client.

To obtain the access token:

02. Calling List Users API

To return all users of type user that have have the reader relationship with document:planning:

<ListUsersRequestViewer authorizationModelId="01HVMMBCMGZNT3SED4Z17ECXCA" objectType="document" objectId="planning" relation="reader" userFilterType="user" expectedResults={{ users: [{ object: { type: 'user', id: 'anne' } }, { object: { type: 'user', id: 'beth' } }], }} skipSetup={true} allowedLanguages={[ SupportedLanguage.JS_SDK, SupportedLanguage.GO_SDK, SupportedLanguage.DOTNET_SDK, SupportedLanguage.PYTHON_SDK, SupportedLanguage.JAVA_SDK, SupportedLanguage.CLI, SupportedLanguage.CURL, ]} />

The result user:anne and user:beth are the user objects that have the reader relationship with document:planning.

:::caution Warning The performance characteristics of the List Users endpoint vary drastically depending on the model complexity, number of tuples, and the relations it needs to evaluate. Relations with 'and' or 'but not' are particularly expensive to evaluate. :::

:::info Conditions and List Users When a relation uses a condition with a per-user attribute (e.g., user_clearance), the List Users API may not return correct results. The API accepts a single context per call, but each candidate user may have a different value for that attribute. If you need to enumerate users based on a per-user attribute comparison, consider modeling the attribute as a type hierarchy using relationship tuples instead of a condition. See Conditions: Limitations for details. :::

Usersets

In the above example, only specific subjects of the user type were returned. However, groups of users, known as usersets, can also be returned from the List Users API. This is done by specifying a relation field in the user_filters request object. Usersets will only expand to the underlying subjects if that type is specified as the user filter object.

Below is an example where usersets can be returned:

model
  schema 1.1

type user

type group
  relations
    define member: [ user ]

type document
  relations
    define viewer: [ group#member ]

With the tuples:

user relation object
group:engineering#member viewer document:1
group:product#member viewer document:1
user:will member group:engineering

Then calling the List Users API for document:1 with relation viewer of type group#member will yield the below response. Note that the user:will is not returned, despite being a member of group:engineering#member because the user_filters does not target the user type.

<ListUsersRequestViewer authorizationModelId="01HXHK5D1Z6SCG1SV7M3BVZVCV" objectType="document" objectId="1" relation="viewer" userFilterType="group" userFilterRelation="member" expectedResults={{ users: [ { userset: { id: 'engineering', relation: 'member', type: 'group', }, }, { userset: { id: 'product', relation: 'member', type: 'group', }, }, ], }} skipSetup={true} allowedLanguages={[ SupportedLanguage.JS_SDK, SupportedLanguage.GO_SDK, SupportedLanguage.DOTNET_SDK, SupportedLanguage.PYTHON_SDK, SupportedLanguage.JAVA_SDK, SupportedLanguage.CLI, SupportedLanguage.CURL, ]} />

Type-bound public access

The List Users API supports tuples expressing public access via the wildcard syntax (e.g. user:*). Wildcard tuples that satisfy the query criteria will be returned with the wildcard root object property that will specify the type. A typed-bound public access result indicates that the object has a public relation but it doesn't necessarily indicate that all users of that type have that relation, it is possible that exclusions via the but not syntax exists. The API will not expand wildcard results further to any ID'd user object. Further, specific users that have been granted access will be returned in addition to any public access for that user's type.

:::caution A List Users response with a type-bound public access result (e.g. user:*) doesn't necessarily indicate that all users of that type have access, it is possible that exclusions exist. It is recommended to perform a Check on specific users to ensure they have access to the target object. :::

Example response with type-bound public access:

{
  "users": [
    {
      "wildcard": {
        "type": "user"
      }
    },
    {
      "object": {
        "type": "user",
        "id": "anne"
      }
    }
  ]
}

Related Sections

<RelatedSection description="Take a look at the following section for more on how to perform list users in your system" relatedLinks={[ { title: '{ProductName} List Users API', description: 'Read the List Users API documentation and see how it works.', link: '/api/service#Relationship%20Queries/ListUsers', }, ]} />