I'm having trouble checking permissions using the ...
# talk-keto
g
I'm having trouble checking permissions using the REST API. When I use the CLI to check a permission that I expect to be allowed, it does indeed return
Allowed
ory is allowed User:Gordon view Document document-id-1
However, when I make the equivalent check via the REST API, I always get
{ "allowed": false }
.
Copy code
POST https://<redacted>.projects.oryapis.com/relation-tuples/check/openapi
{
  "namespace": "Document",
  "object": "document-id-1",
  "subject_id": "User:Gordon",
  "relation": "view"
}
Why is this? I've tried different variations of input (using
Gordon
instead of
User:Gordon
), but I never get back allowed: true using REST.
e
I am also wondering.. what is the difference between
Gordon
and
User:Gordon
effectively? I couldn't find any information on this in the docs. I am asking, because i actually get different results when checking permissions, whether i am defining the subject id including the namespace, or without it in the relation tuples. In addition i get very confusing results when i do permission checks with the go sdk. I might do somethin wrong, but i find the documentation also quite confusing, even contradicting in terms of how to to do things. Not very helpful in the end. The issues i am experiencing might also be related to this bug (which seems like very basic thing to me), i don't know. After all, it's a rather frustrating experience, and doesn't give me the impression of keto being a product i can actually use at all. 😕 (using the cloud version, not self hosted)
w
Gordon
is just a
subjectId
or an
objectId
, depending on how it's being used.
User:Gordon
is a
subjectSet
where
namespace=User
and
object=Gordon
and
relation=
(empty). Idiomatically, that would be written:
User:Gordon#
That's why you get different results. If you set up a tuple such as
Permission:admin#members@User:Gordon
vs
Permission:admin#members@Gordon
those are two, distinct subjects. One is a
subjectSet
the other is a
subjectId
. So, yes, no wonder you get two different results depending on how you set up your tuples. My fork handles this particular situation such that both scenarios work in `check`s.
https://github.com/cmmoran/keto branch:
feat/kitchen-sink
I've added a few missing features to my fork.