To list all files a user has access to in an Ory Permissions system (similar to Google Drive's access control), you would use the List API. This API allows you to query relationships by providing a partial relationship, which is perfect for finding all objects a user has access to. ## Using the List API The List API is specifically designed for use cases like: - Listing objects a user has access to - Listing users who have specific roles - Listing members of groups - Auditing permissions in the system [API overview](https://www.ory.sh/docs/keto/concepts/api-overview) explains that the List API allows you to "list objects a user has access to" by querying relationships. ## Implementation Example Here's how you might approach this: 1. Query for direct access: First, query for all files where the user has direct access permissions. 2. Query for group-based access: Then, find all groups the user belongs to, and query for files accessible to those groups. For example, as shown in the [RBAC guide](https://www.ory.sh/docs/keto/guides/rbac#display-all-objects-a-user-has-access-to), you could:

# Get all groups for a user (e.g., Dilan) keto relation-tuple get --subject-id=Dilan --relation=member --format json --read-remote localhost:4466  # Then for each group, get permissions to objects keto relation-tuple get --subject-set="groups:marketing#member" --format json --read-remote localhost:4466

## Important Considerations 1. Subject Sets: The List API does not automatically expand subject sets. As noted in the [List API documentation](https://www.ory.sh/docs/keto/guides/list-api-display-objects#application-context): > "It's important to note that the list API does not expand subject sets. Usually the application has some context to determine what tuples to query anyway." 2. Application Context: Your application should have context about the structure of permissions to make efficient queries. For example, knowing the hierarchy of files and folders. 3. Alternative Approach: If you need to expand subject sets, you might need to use the [Expand API](https://www.ory.sh/docs/keto/guides/expand-api-display-who-has-access) instead, though this is typically used to show who has access to an object rather than what objects a user can access. For a file-sharing application with hierarchical permissions, you'll likely need to combine multiple queries to get a complete picture of what files a user can access, especially if you have complex permission inheritance through folders and groups.

Yes, that's a good approach. After using the List API to get all files a user has access to, you would collect the file IDs into an array and then query your database to retrieve the actual file data. This two-step process is necessary because Ory Permissions (Keto) only stores relationships and permissions, not the actual file content or metadata. As mentioned in the [Expand API documentation](https://www.ory.sh/docs/keto/guides/expand-api-display-who-has-access#example): > "Directories and files are stored in Ory Keto within the

directories

and

files

namespaces respectively. They're identified by a UUID that the application maps to the actual object metadata." ## Implementation Flow: 1. Use the List API to get all relationship tuples where the user has access 2. Extract the object IDs (file IDs) from these tuples 3. Use these IDs to query your application database for the actual file data This approach aligns with best practices for integrating Ory Permissions into your application as described in the [integration guide](https://www.ory.sh/docs/keto/guides/simple-access-check-guide). ## Important Considerations: 1. Pagination: The List API returns paginated results, so you might need to handle multiple pages if the user has access to many files. As noted in the [List API documentation](https://www.ory.sh/docs/keto/guides/list-api-display-objects#pagination): > "The list API only returns paginated results... The response returns an opaque token that has to be used to retrieve the following page." 2. Don't Cache Permission Checks: While you'll be querying your database with the file IDs, remember not to cache the permission results themselves, as mentioned in the [best practices](https://www.ory.sh/docs/keto/guides/simple-access-check-guide#best-practices): > "Ory Network provides a low-latency, globally distributed system with appropriate caching... You don't need to worry about caching the permission checks in your application." 3. Batch Retrieval: If you need to retrieve a large number of identities or files, you might face limitations with the current API. There was a [GitHub issue](https://github.com/ory/network/issues/305) discussing the need for batch retrieval of identities, which suggests similar limitations might exist for other resources. This approach effectively separates your permission logic (handled by Ory) from your data storage, allowing you to maintain a clean architecture while still providing efficient access to resources.