https://www.ory.sh/ logo
Join Slack
Powered by
<@U04UQ68083H> ory keto Please help me update my c...
# ory-copilot
s
@chilly-king-10285 ory keto Please help me update my codes, I have some requirements: • A have a table “dashboard” with many records: dashboard_id1, dashboard_id2,… • A have many users, a user can be an owner of a dashboard (dashboard_id1), a user can be a viewer, a user can be a editor, owner also is an editor, user can view dashboard => this means user can view dashboard_id1, dashboard_id2
Copy code
class User implements Namespace {
  related: {
    editors: User[]
    viewers: User[]
    owners: User[]
  }
}

class Dashboard implements Namespace {
  related: {
    members: (User | Dashboard)[]
  }
}

class DashboardInstance implements Namespace {
  related: {
    parents: Dashboard[]
    viewers: (User | SubjectSet<Dashboard, "members">)[]
    owners: (User | SubjectSet<Dashboard, "members">)[]
    editors: (User | SubjectSet<Dashboard, "members">)[]
  }

  permits = {
    view: (ctx: Context): boolean =>
      this.related.parents.traverse((p) =>
        p.related.viewers.includes(ctx.subject),
      ) ||
      this.related.viewers.includes(ctx.subject) ||
      this.related.owners.includes(ctx.subject),

    edit: (ctx: Context): boolean => this.related.editors.includes(ctx.subject),
  }
}
b
A message from kapa.ai
Based on your requirements and the Ory Keto Permission Language (OPL) best practices, here’s how you can update your code: ### Requirements Recap - You have a 
dashboard
table with many records (dashboard_id1, dashboard_id2, ...). - Users can be owners, editors, or viewers of a dashboard. - Owners are also editors. - Editors are also viewers. - If a user can view a dashboard, they can view all dashboard instances under it (hierarchical permission). ### Recommended OPL Model You should model the relationships and permissions to reflect the hierarchy and inheritance of roles. The OPL should use plural relationship names and express the permission inheritance (owner → editor → viewer) and the transitive view permission through parent dashboards. Here’s an updated version of your code, following Ory Keto conventions and your requirements:
Copy code
typescript import { Namespace, Context, SubjectSet } from "@ory/keto-namespace-types"  class User implements Namespace {}  class Dashboard implements Namespace {   related: {     owners: User[]     editors: User[]     viewers: User[]     parents: Dashboard[]   }    permits = {     // Owners are also editors, editors are also viewers     view: (ctx: Context): boolean =>       this.related.viewers.includes(ctx.subject) ||       this.permits.edit(ctx) ||       this.related.parents.traverse((parent) => parent.permits.view(ctx)),      edit: (ctx: Context): boolean =>       this.related.editors.includes(ctx.subject) ||       this.permits.own(ctx),      own: (ctx: Context): boolean =>       this.related.owners.includes(ctx.subject),   } }  class DashboardInstance implements Namespace {   related: {     parents: Dashboard[]     viewers: (User | SubjectSet<Dashboard, "viewers">)[]     editors: (User | SubjectSet<Dashboard, "editors">)[]     owners: (User | SubjectSet<Dashboard, "owners">)[]   }    permits = {     // Inherit view permission from parent dashboard     view: (ctx: Context): boolean =>       this.related.viewers.includes(ctx.subject) ||       this.permits.edit(ctx) ||       this.related.parents.traverse((parent) => parent.permits.view(ctx)),      edit: (ctx: Context): boolean =>       this.related.editors.includes(ctx.subject) ||       this.permits.own(ctx),      own: (ctx: Context): boolean =>       this.related.owners.includes(ctx.subject),   } }
Key points: - Use plural relationship names (
owners
, 
editors
, 
viewers
) as per Ory Keto conventions. - Express permission inheritance using 
this.permits.edit(ctx)
and 
this.permits.own(ctx)
to avoid code duplication and ensure correct role escalation. - Use 
.traverse
to allow transitive permissions from parent dashboards, so if a user can view a parent, they can view all children. - Use 
SubjectSet<Dashboard, "viewers">
etc., to allow group-based permissions if needed. This model is directly aligned with the Ory Keto documentation and best practices for hierarchical and inherited permissions [Create a permission model](https://www.ory.sh/docs/keto/modeling/create-permission-model#define-permissions-in-the-opl), [OPL examples](https://www.ory.sh/docs/keto/reference/ory-permission-language#examples). If you need to support group membership or more complex subject sets, you can further extend the relationships as shown in the OPL examples. Let me know if you need help with the relationship tuples or API usage!
s
@chilly-king-10285 all codes in permission.ts i am using ory keto on docker compose, how can i add this file into ory keto
b
A message from kapa.ai
To use your 
permission.ts
(the Ory Permission Language file) with a self-hosted Ory Keto instance running via Docker Compose, you need to convert your OPL file into a configuration format that Keto understands and then mount it into the container. However, the knowledge sources do not provide a direct, step-by-step guide for mounting a 
.ts
OPL file into a Docker Compose setup for Ory Keto. Here’s what is clear from the documentation: - Ory Keto uses a configuration file (typically YAML) for namespaces and permission rules. - The Ory Permission Language (OPL) is used in Ory Network and can be managed via the Ory Console or CLI. - For self-hosted Keto, you can export/import the permission configuration using the Ory CLI, and the configuration is typically in YAML, JSON, or JSON-pretty format, not TypeScript directly. Recommended approach based on the docs: 1. Write your permission model in OPL (
permission.ts
). 2. Use the Ory CLI to import the configuration into Ory Network, or export from Ory Network to YAML for self-hosted Keto. - Example to export from Ory Network:
Copy code
sh      ory get permission-config --project <project-id> --workspace <workspace-id> --format yaml > permission-config.yaml
- You can then mount 
permission-config.yaml
into your Keto Docker container. 3. Mount the configuration file in Docker Compose: - In your 
docker-compose.yml
, add a volume to mount the config file:
Copy code
yaml      services:        keto:          image: oryd/keto:<version>          volumes:            - ./permission-config.yaml:/etc/config/permission-config.yaml          command:            - serve            - --config            - /etc/config/permission-config.yaml
Summary: You cannot directly mount a 
.ts
OPL file into Ory Keto. You must convert it to a supported configuration format (YAML/JSON) and mount that file. The OPL is mainly used in Ory Network and via the Ory Console or CLI, not directly in self-hosted Keto containers. For more details, see the [Ory CLI configuration guide](https://www.ory.sh/docs/guides/cli/configure-permission-service) and [Ory Permission Language reference](https://www.ory.sh/docs/keto/reference/ory-permission-language). If you need to work locally, consider using the Ory CLI to test and convert your OPL file, then mount the resulting config into your Docker container as described above.
s
@chilly-king-10285 please give me an api to get list identities
b
A message from kapa.ai
To get a list of identities in Ory, you can use the following API endpoint:
Copy code
GET /admin/identities
This endpoint lists all identities in the system. You can use various query parameters for pagination, filtering, and consistency. For example: - `page_size`: Number of items per page (default: 250, max: 500) - `page_token`: Token for the next page - `consistency`: Read consistency level (
strong
or 
eventual
) - `include_credential`: Include credentials such as 
password
or 
oidc
in the response - `organization_id`: Filter identities by organization - `ids`: Retrieve multiple identities by their IDs - `credentials_identifier`: Look up by credential identifier (username, email) Example request:
Copy code
GET /admin/identities?page_size=100&consistency=eventual
Authentication: You must authenticate using an Ory access token to perform this operation. For more details, see the [Ory API Reference for listIdentities](https://www.ory.sh/docs/kratos/concepts/identity-user-model) and the [API documentation](https://raw.githubusercontent.com/ory/docs/master/docs/reference/api.json) (see the "listIdentities" method) and [Kratos API Reference](https://raw.githubusercontent.com/ory/kratos/master/spec/api.json).
Open in Slack
PreviousNext
Powered by