You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using the data from the userset-rewrites example, the expand route does not include implicit tuples from defined by the userset rewrites. A check command will return "Allowed" but the corresponding expand command returns an empty tree.
Reproducing the bug
Note: You may need to include --insecure-disable-transport-security flag for the commands below.
Load the tuple data referenced from the userset-rewrites example
Run "keto relation-tuple get" and ensure the output is as follows:
NAMESPACE OBJECT RELATION NAME SUBJECT
Folder keto/ viewers Group:developer#members
Folder keto/src/ parents Folder:keto/
File private owners User:Henning
Group developer members patrik
Group developer members User:Henning
File keto/src/main.go parents Folder:keto/src/
File keto/README.md parents Folder:keto/
Group developer members User:Patrik
Run "keto check User:Henning edit File private"
Note the output is "Allowed"
Run "keto expand edit File private"
Note the output is "Got an empty tree. This probably means that the requested relation tuple is not present in Keto." Expected -- The tree would include some implicit tuple representing the rewrite.
Run "keto expand owners File private"
Note that the output includes the explicit tuple loaded from the sample data:
yup I'm struggling to understand the subject-set rewrites for precisely this reason. The permits attribute of the namespace configuration seem to allow you to specify subjet-set rewrites. That the permits section is effectively the subject-set rewrite feature is also not well explained in my opinion. I couldn't build that bridge in my mind, until I read the original paper. But back to the point, the edit permission is effectively a relation and in my opinion should be represented by an edge in the tree of the flattened DAG. Which is what the expand command should be doing no?
I wonder if this rationale should also apply to the List API.
If the permits section is "just" a way to define a relation using subject-set rewrites. Then supporting the subject-set rewrites for both the expand and list endpoint's relation argument would be consistent right?
But yes, would love to see this feature 👍 since as it stands the only workarounds appear to be:
Duplicate your understanding of the rewrites in your application, by listing the normal relationships instead.
Do a large number of check queries for each potential tuple.
Preflight checklist
Describe the bug
Using the data from the userset-rewrites example, the expand route does not include implicit tuples from defined by the userset rewrites. A check command will return "Allowed" but the corresponding expand command returns an empty tree.
Reproducing the bug
Note: You may need to include --insecure-disable-transport-security flag for the commands below.
NAMESPACE OBJECT RELATION NAME SUBJECT
Folder keto/ viewers Group:developer#members
Folder keto/src/ parents Folder:keto/
File private owners User:Henning
Group developer members patrik
Group developer members User:Henning
File keto/src/main.go parents Folder:keto/src/
File keto/README.md parents Folder:keto/
Group developer members User:Patrik
Note the output is "Allowed"
Note the output is "Got an empty tree. This probably means that the requested relation tuple is not present in Keto."
Expected -- The tree would include some implicit tuple representing the rewrite.
Note that the output includes the explicit tuple loaded from the sample data:
or :#@file:private#owners
└──∋ :#@user:Henning️
Relevant log output
No response
Relevant configuration
No response
Version
0.10.0-alpha.0
On which operating system are you observing this issue?
Linux
In which environment are you deploying?
Binary
Additional Context
No response
The text was updated successfully, but these errors were encountered: