https://www.ory.sh/ logo
Join Slack
Powered by
Or any reference implementation maybe? When experi...
# talk-keto
f
Or any reference implementation maybe? When experimenting with the CLI and REST API, I get confusing results (relation tuples and permission model in thread): The CLI (works as expected):
Copy code
❯ ory is allowed User:David view ContentItem Recept1

Allowed
The REST API (not working as expected):
Copy code
❯ curl --location 'https://[APIENDPOINT]/relation-tuples/check/openapi?namespace=ContentItem&object=Recept1&relation=view&subject_id=User%3ADavid' \
--header 'Authorization: Bearer [APITOKEN]'

{"allowed":false}
What part am I overlooking?
Relationships:
Copy code
❯ ory list relationships

NAMESPACE	OBJECT	RELATION NAME	SUBJECT			
Organization	Plate	admins		User:David		
ContentItem	Recept2	owner		Organization:Gr		
ContentItem	Recept1	owner		Organization:Plate
Permission Config:
Copy code
import { Namespace, SubjectSet, Context } from "@ory/permission-namespace-types"

class Organization implements Namespace {
  related: {
    admins: User[],
    contentEditors: User[]
  }
}

class User implements Namespace {

}

class ContentItem implements Namespace {
  related: {
    owner: Organization[]
  }

  permits = {
    view: (ctx: Context): boolean =>
      this.related.owner.traverse((p) => p.related.admins.includes(ctx.subject)) ||
      this.related.owner.traverse((p) => p.related.contentEditors.includes(ctx.subject))
  }
}
f
try to pass the 
subject_namespace
and 
subject_object
, not 
subject_id
. I’m using also the js client and only that works for me.
probably you need also define 
subject_relation
as empty string (if you will see error that given parameters aren’t supported).
f
Like so you mean?
Copy code
curl --location '<https://XXXX/relation-tuples/check/openapi?namespace=ContentItem&object=Recept1&relation=view&subject_namespace=User&subject_id=David>' \
--header 'Authorization: Bearer XXXX'
Still returns allowed: false sadly.
f
subject_object
not 
subject_id
I didn’t test HTTP calls manually, but only by JS client, and that works for me:
Copy code
const result = await oryPermissionAPI.checkPermission({
    namespace: 'Organization',
    object: 'organization1',
    relation: 'view',
    subjectSetNamespace: 'Member',
    subjectSetObject: 'XXX',
    subjectSetRelation: '',
  });
sorry… It should be 
subject_set.namespace
and 
subject_set.object
-> https://www.ory.sh/docs/keto/reference/rest-api#tag/permission/operation/checkPermission
f
Ah that works, weird, I was sure I tried that configuration as well but probably not exactly then. Thanks! But now I have the same problem with how to do "expandPermissions":
Copy code
permissionApi.expandPermissions({
    namespace: "ContentItem",
    object: "Recept1",
    relation: "view",
  },
)...
This returns:
Copy code
{
  "code": 404,
  "status": "Not Found",
  "message": "no relation tuple found"
}
Any chance you've seen this before as well?
f
expandPermissions
reads 
relation
as relationships, not permission levels, so please pass 
relation
as keys of 
related
object in namepsaces
I had also this same problem to understand that, more info -> https://ory-community.slack.com/archives/C012RBZFMDG/p1686295464918189
if you will find a better way to list all relationships which allow the given permission levele with omitting the several API calls (but only by one), please write to me, because I also need that 😄
f
Ah I see, but can we then do this transitively? So I want all users at the end of the path (ContentItem)-[owner]-(Organization)-[admins]-(User).
I just confirmed that I can get all Organizations for a ContentItem (through the owner relation, so the first step)
f
it depends on the relationships that you had, for example I have this relationship rules:
Copy code
class Member implements Namespace {}

class Organization implements Namespace {
  related: {
    owners: Member[]
    members: Member[]
    solutions: Solution[]
  }

  permits = {...}
}

class Solution implements Namespace {
  related: {
    owners: (Member | SubjectSet<Organization, "owners">)[]
    members: Member[]
    organizations: Organization[]
  }

  permits = {...}
}
so if executed the 
expandPermissions
method with (as I remember, with 
maxDepth: 3
)
Copy code
{
    namespace: 'Solution',
    object: 'solution1',
    relation: 'owners',
}
I see the deepest relationships with 
Organization:organization1:owners
-> then I had to call another HTTP API call to retrieve all owners of 
organization1
f
So that means you basically get 1 step per request?
f
Now I’m looking that maybe maxDepth4 or 5 could fetch me all the relationships (even those related to who is the owner of the organization) under a given query, but I haven’t checked it.
f
So you always needed to do 1 + (# of organizations) requests to get all members?
f
So that means you basically get 1 step per request?
you can call it then as:
Copy code
{
    namespace: 'Organization',
    relation: 'owners',
}
and you will see all relationships between Members and Organizations, so you can easy filter them based on needed object (in my case, the organization)
so you will have 2 API calls.
f
Yeah ok, so still 2 requests then indeed. THat seems to miss the whole point of the permission expansions right?
f
but maybe 
maxDepth
can fix that issue, I will try to do this tomorrow
yeah 😄 checking all relationships (even deepest) based on permission level should save a lot of computing time and resources. As you can read in the thread that I pasted, it’s on the roadmap.
f
Yeah I see, but I think maxDepth defaults to a number > 1 already right? So you should've been getting the deeper relations already
@steep-lamp-91158 are we missing anything here?
f
perhaps, I have to test it tomorrow, I defined it as 
maxDepth: 3
f
Ok. Thanks for your help so far at least!! This is really helping to understand it
f
no problem 🙂 glad I helped.
8 Views
Open in Slack
PreviousNext
Powered by