Request for separate Channel object type in spiceDB #2289
arvindh123
started this conversation in
General
Replies: 1 comment
|
There is a pre check condition in spiceDB for adding policy for group with parent group, This pre check condition check for parent ID is present in same domain to which group is present. This precondition check helps to solve partially the Case 1 . Then While adding group with channel ID's UUID as parent , It will fails in pre condition check, since channel ID's UUID will be member of domain, |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Case 1
Both Group and Channels share the same implementation
pkg/groups/groups.go,internal/groups/service.goand same data structure in database.Groups are present in
usersservice. Their tables are present inusers dbWhen you try to create group with parent as channel, It wont happens, it get fails.
Example :
User service logs
{"time":"2024-06-13T16:43:33.794708577Z","level":"WARN","msg":"Create group failed to complete successfully","duration":"66.09458ms","group":{"id":"","name":""},"error":{"error":"failed to create entity in the db","message":"failed to create entity"}}Logs from users service database
It fails due to Foreign key reference in groups table, which requires
parent_idthat need to present in same table.Here the
channel_idis not present in same table ,they are present in table in database to whichthingsservice is connected .On any entity creation, there will two major action take place, Adding policy to spice db and adding entity to database
First the adding of policy take place , then followed by adding of entity to database.
So here in this case, If we the policy is added to spicedb, then it is remove , because if entity is failed to add to database ,the service will rollback the policy,
Suggestion:
We should detect before adding to repo, during policy addition we should have this check.
So that we can avoid adding and rollback of policy.
To do this like of check in policy, we need some kind distinguish between channels and groups in spicedb
The one of way i see is by having different object type for channels and groups
Case 2
Things could not be related to groups as subscribe or publish relation , Instead group related to thing as publish or subscribe relation.
In present case , thing is object and group becomes subject.
If we have publish and subscribe relation, then it would be like
Group(Subject)havepublishrelationwithThing(object)Group(Subject)havesubscriberelation withThing(object)Because of this we could not check
thinghavepub/subpermissionongroup(channel)Instead we check like following :
Does
GrouphavepublishpermissiontothingDoes
Grouphavesubscribepermissiontothing?This concept will work, it is one of the practical way of implementation, but it doesn't match with theoretical architecture of MG
In theoretical architecture, channels are communication conduit, to which thing are connect.
So according to this theory, permission check should be like:
Does the
thinghavepub/subpermissionongroup(channel)If we want to have the same the theoretical architecture in MG
Then we need to change thing to subject and group to object.
Relation will be like
Thing``(subject)havepublishrelation withGroup``(object)Thing(subject)havesubscriberelation withGroup``(object)`Then we can have permission check will be like
Does
ThinghavepublishpermissiontoGroupDoes
ThinghavesubscribepermissiontoGroup?To have this change we need to separate group and channels in spicedb
Because Group and channel share the type in spicedb , Type name is
GroupGroup/Channelcan havegroup(like connect) relation withthingobjectExisting:
if we didn't separate the group and channels and tries to implement,
then Group want to be object, then
thingshould havepub/subrelation withGroup/ChannelThis leads to

thinghavingpub/subrelation touser group, since we could not distinguish between channels and groups in spicedbSo If we have separate object type channel, the have dedicated pub/sub relation for thing to channel.
This will avoid the thing having pub/sub relation with groups
All reactions