Jake
10/28/2021, 8:27 PMversion: "3.8"
services:
db:
image: postgres:9.4
volumes:
- db-data:/var/lib/postgresql/data
networks:
- backend
environment:
- POSTGRES_PASSWORD
ports:
- "5432:5432"
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres"]
interval: 10s
timeout: 5s
retries: 5
sleipnir042
10/28/2021, 8:27 PMJake
10/28/2021, 8:28 PMJake
10/28/2021, 8:28 PMsleipnir042
10/28/2021, 8:29 PM✅ spicedb-sync-poc % docker-compose up
ERROR: The Compose file './docker-compose.yml' is invalid because:
services.spicedb.depends_on contains {"psql": {"condition": "service_healthy"}}, which is an invalid type, it should be a string
❌ 1 spicedb-sync-poc %
Jonathan Whitaker
10/28/2021, 9:06 PMfukuroutoimasu
10/28/2021, 9:56 PMfukuroutoimasu
10/28/2021, 9:56 PMJonathan Whitaker
10/28/2021, 10:20 PMJonathan Whitaker
10/28/2021, 10:39 PMdefinition user {}
definition group {
relation member: user | group#member
}
definition portfolio {
relation owner: user
relation viewer: user | portfolio#editor | group#member
relation editor: user | portfolio#owner | group#member
permission view = viewer
permission edit = editor
}
I write a relation and then subsequently read a relation. Here's the read that I get back:
{
"readAt": {
"token": "GgMKATQ="
},
"relationship": {
"relation": "owner",
"resource": {
"objectId": "1",
"objectType": "portfolio"
},
"subject": {
"object": {
"objectId": "jonwhit",
"objectType": "user"
}
}
}
}
If I do a check(portfolio:1, view, user:jonwhit)
I get PERMISSIONSHIP_NO_PERMISSION
. Shouldn't that user have the permission since he is an owner and owners are editors and editors can view?Jonathan Whitaker
10/28/2021, 10:41 PMecordell
10/28/2021, 10:55 PMpermission view = viewer + editor + owner
permission edit = editor + owner
To clarify, when you write a relation like this:
relation editor: user | portfolio#owner | group#member
What you're saying is "Let (spicedb) users write relationships for this namespace where the subject is a user, or the subject is an owner of a portfolio or the subject is a member of a group" - but those relationships still need to be written into the db by someone (you)
permissions
are what let you compute over relationships, which is probably what you were going for:
permission view = viewer + editor + owner
This says "we'll pretend there's a view
relationship between resource and the subject if there's a relationship that says the subject is a viewer, editor, or owner of the resource"Jonathan Whitaker
10/28/2021, 11:16 PMJoey
10/28/2021, 11:48 PMJoey
10/28/2021, 11:48 PMJoey
10/28/2021, 11:49 PMJoey
10/28/2021, 11:52 PMjon.whit
10/29/2021, 12:33 AMRNDude
10/29/2021, 7:09 AMorganization:123#member@user:john
?
definition user {}
definition invitation {
relation acceptor : user;
}
definition organization {
relation invite : invitation;
}
definition org_role {
relation invite : organization#invite;
relation member : user;
permission access = member & invite->acceptor
}
definition resource {
relation reader: org_role#access;
}
Jake
10/29/2021, 1:18 PMJake
10/29/2021, 1:19 PMemail
Jake
10/29/2021, 1:20 PMcheck("org:bigco", "can_join", "email:theusersemail")
Jake
10/29/2021, 1:21 PM@
symbols in object IDsJake
10/29/2021, 1:22 PMmember
relationshipJake
10/29/2021, 1:22 PMJake
10/29/2021, 1:24 PMpermission access = thing + otherthing + anotherthing + afourththing
will be evaluated in parallel, whereas things that are deeply nested will need to resolve things in sequencesleipnir042
10/29/2021, 1:28 PM...
relation means?Jake
10/29/2021, 2:02 PMJake
10/29/2021, 2:02 PMJake
10/29/2021, 2:03 PM