https://authzed.com logo
Join Discord
Powered by
and then you can write `user ` to say
# spicedb
y
and then you can write 
user:*
to say "all users can read this" or 
user:<id>
to say "a specific user can read this"
f
I think I am still lost here 
relation reader: user | user:*
is the user without an id supposed to represent an anonymous user? I explicitly want it defined as an anonymous user as there will be read only boards
Ahh i think I fixed it I was thinking something like this: Which means a viewer can either be a specific user, any signed in user, or any anonymous user 
relation reader: user | user:* | anonymous_user:*
board:whiteboard-4444#reader@user:222 board:whiteboard-4444#reader@user:* board:whiteboard-4444#reader@anonymous_user:* all seemed to work which I guess makes sense since if I only wanted to grant a certain user like board:whiteboard-4444#reader@anonymous_user:12 I would need to change the relation to 
relation reader: user | user:* | anonymous_user | anonymous_user:*
This is very cool
j
yeah, if you want a specific anon user, you'd use the above
v
another way is to use a special "singleton" user ID you know no other user in the system can have and that is used to represent the anonymous user
f
Ok maybe I’m prematurely optimizing but let’s say if a room has a anonymous wildcard user on a board for read access. Is there a way to do this through a check on spicedb or would I need to write the logic for this in js / node
j
do what, exactly?
f
So let’s say anytime I give access to the board to any anonymous user for reads (anonymous_user:*). This implicitly means that any signed in user will also have access. Does this mean I need to have to entries in my spicedb instance for this?
is that a good pattern for dealing with this or should I remodel my access model schema to take this into account
j
> This implicitly means that any signed in user will also have access. if you use a different subject type 
user
, yes, you'll need to write 
user:*
you could also combine the two user types and just have anonymous users represented as 
user:anonymous
or a defined-name
but you'll need to make sure that name can't be a real user
f
ya I’m honestly thinking that might be easier for now since I don’t have any difference between the anonymous users since it’s a read only access pattern for now so thinking about it I don’t really need to differentiate between anonymous users (which seems to be more for an editing flow)
I can always revisit the model later if I add more functionality
Ok so moving forward I have some questions I have the following schema
Copy code
definition branchboard/board {
    relation writer: branchboard/user
    relation reader: branchboard/user | branchboard/user:*
    permission edit = writer
    permission view = reader + edit
}

definition branchboard/user {}
` I am guessing if a user is being added to a board here, then both of the relationships should be added to accordingly. My write relationship code seems to only add in the board definition only and no idea why

https://cdn.discordapp.com/attachments/1151623073167056937/1154175905439154237/image.png▾

Copy code
typescript
 const lol = v1.WriteRelationshipsRequest.create({
    "updates": [
      v1.RelationshipUpdate.create({
        relationship: v1.Relationship.create({
          resource: v1.ObjectReference.create({
            objectType: 'branchboard/board',
            objectId: board_id,
          }),
          relation: 'writer',
          subject: v1.SubjectReference.create({
            object: v1.ObjectReference.create({
              objectType: 'branchboard/user',
              objectId: user_id,
            }),
          }),
        }),
        operation: v1.RelationshipUpdate_Operation.TOUCH,
      }),
    ],
  })
j
> then both of the relationships should be added to accordingly
can you expand on this?
f

https://cdn.discordapp.com/attachments/1151623073167056937/1154176671679795320/image.png▾

i get something in board but not in user
if that makes sense
i am guessing both should be added no?
j
no
you're using user as a subject in the relationship
the dropdown shows relationships where the user is the resource
which there are none
f
so this would be if there was some permissions on a user specifically instead of a board?
j
yep
f
intresting makes sense 🙂
i appreciate the github examples and postman
j
more accurately: if there were some relationships where the user was the resource (left hand side)
f
it really helped getting it going
j
let us know where we can improve on the examples
f
will do! I am actually using authzed for my own permissions on something on top of github so still building it out i am basically building something where if a user gets added to a github review request they can become an editor on a documentation tool 🙂 so using authzed to build my own generic authz on top of github 🙂
j
sweet!
f
trying to setup removing permissions
Copy code
tsx
const removeUserPermissionToBoard = async (board_id: string, user_id: string, permission: 'writer' | 'reader') => {
const remove_user_write_access_to_board = v1.DeleteRelationshipsRequest.create({
    relationshipFilter: v1.RelationshipFilter.create({
      resourceType: "branchboard/board",
      optionalResourceId: board_id,
      optionalRelation: permission,
      optionalSubjectFilter: v1.SubjectFilter.create({
        subjectType: 'user',
        optionalSubjectId: user_id
      })
    })
  })}
;
I keep getting 
Error: 3 INVALID_ARGUMENT: the length of the unpacked is not equal to the provided input
Copy code
code: 3,
  details: 'the length of the unpacked is not equal to the provided input',
  metadata: Metadata {
    internalRepr: Map(2) {
      'io.spicedb.respmeta.dispatchedoperationscount' => [Array],
      'io.spicedb.respmeta.cachedoperationscount' => [Array]
    },
    options: {}
  }
I think a node example for this would be super helpful
I do see it in postman but not in the node examples
nvm it worked after i changed 
user
to 
branchboard/user
v
yeah in serverless, being multitenant, you always have to specify the prefix
the error mesage is not great tho
3 Views
PreviousNext
Powered by