https://authzed.com logo
Join Discord
Powered by
How to implement feature flags / feature gating wi...
# spicedb
b
Just looking for some confirmation that the only way to solve a particular problem is the way i'm thinking: I have the following entities:
Copy code
definition user {
relation current:user
relation org:organization

permission is_admin = org->admin & current // ie: to check that the user object is both in 'current' (will only be one entry per user) and org->admin (multiple users)
}

definition organization {
relation admin: user
relation some_role: user
}
in order to check that a user is 'admin' through checking the 'user' object alone without caveats; is the only approach to create the following relations: user:1#org@organization:1 user:1#current@user:1 organization:1#admin@user:1
v
This is a bit convoluted, although it works. It does not feel right because this is conceptually asking spicedb "is user1 admin of user1", which is not what you are actually doing, and my collision the moment you application starts using the 
user
as a resource to authorize access to for. What's the actual requirement you want to implement? Is it to show in a UI which roles does the user have? The way this is typically solved is by running 
ReadRelationships
over the relation that assigns the admin role to a user. For example, this could be 
organization#admin
. You can use the 
ReadRelationship
API to do a exact match over the user you are looking for, so that the API returns either one or zero relationships.
b
I dont disagree with it feeling convoluted and wrong. At a fundamental level, I'll likely have to use something similar to this to be able to check whether X user has access to Y feature (if their organization purchased it) - and i'm trying to avoid managing individual user objects for permissions as much as possible (creating one org relationship seems much easier to me than modifying potentially a hundred user obj's when I get a stripe sync).
While it will be a bit of a duplication to write permissions on the user object that mirror the org; ive fell into that pattern as i've been learning SpiceDB. I rarely check 'org' permissions directly.
v
why checking if the user has access to a feature, instead of checking whether the user can actually perform the operation enabled by a feature?
Let's imagine this is github and you've purchased GitHub Enterprise so that you can do thins like advanced security. You'd model it as follows:
Copy code
definition organization {
  relation member: user
  relation repos: repository
  relation advanced_security: user:*

  permission can_enable_dependabot: advanced_security & member
}

definition repository {
  relation owner: organization | user
  
  permission can_enable_dependabot: owner->can_advanced_security
}
so instead if checking if a user is member of an organization that has advanced security enabled, you'll actually authorize the operation that is enabled as part of that feature, which is to enable_dependabot (this is just an example, may not be like this in real life GitHub Enterprise)
if the "feature flag" wildcard relationship is not written, the user will be denied
b
thats a really good solution - thanks!
11 Views
PreviousNext
Powered by