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
I have an authorization scenario which I find myself unable to implement, and the documentation / tutorials on the docs.osohq website don't seem to mention such a scenario at all:
I have an Event class with attendees, and some of the attendees are managers. The troublesome case is the following: Managers of an Event can remove attendees unless the attendee to be removed is another manager. has_permission(p: Person, "remove", e: Event)` where p is the actor, does not do it because the person to be removed is not referenced. The problem is that the action must be of type string.
What is the typical way to handle such a policy? It seems to be common enough.
Some additional thoughts I explored:
adding oso.authorize(current_user, "remove_attendee", event) and `oso.authorize(current_user, "remove_attendee", attendee) as separate enforcement checks does not suffice.
adding a Relation during class registration does not help either. It might give us access to the list of managers of the event, but the relevant parameter (namely which attendee we are trying to remove) is still missing.
Is this scenario not enforceable with the current API of strictly only string-type actions or have I overlooked something in the documentation? If it is possible, an example in the tutorials would probably be great, since this type of access policy is probably fairly common.
Thanks for commenting
The text was updated successfully, but these errors were encountered:
You're right, an example would be a good idea, because this is indeed a pretty common scenario.
The way I would think about handling that is as a mutation of an EventAttendee resource. E.g. oso.authorize(current_user, "delete", event_attendee).
The EventAttendee resource could potentially correspond to a through table like event <-> event_attendees <-> user, or if that's not something exposed in your model, then perhaps you could create a small class to encapsulate that logic?
In any case, to me that most closely matches the semantics of what you're asking -- more granular than "can the user remove attendees (generically) from the event", it's, "can the user remove this specific event attendee".
How does that sound to you? do you think that would be feasible?
The container class EventAttendee sounds like a decently elegant solution to me and should work in my case :) Thanks for very much for commenting. Hoping to see the example in the tutorials some time in the future :)
Hi,
I have an authorization scenario which I find myself unable to implement, and the documentation / tutorials on the docs.osohq website don't seem to mention such a scenario at all:
I have an Event class with attendees, and some of the attendees are managers. The troublesome case is the following: Managers of an Event can remove attendees unless the attendee to be removed is another manager.
has_permission
(p: Person, "remove", e: Event)` where p is the actor, does not do it because the person to be removed is not referenced. The problem is that the action must be of type string.What is the typical way to handle such a policy? It seems to be common enough.
Some additional thoughts I explored:
oso.authorize(current_user, "remove_attendee", event)
and `oso.authorize(current_user, "remove_attendee", attendee) as separate enforcement checks does not suffice.Is this scenario not enforceable with the current API of strictly only string-type actions or have I overlooked something in the documentation? If it is possible, an example in the tutorials would probably be great, since this type of access policy is probably fairly common.
Thanks for commenting
The text was updated successfully, but these errors were encountered: