[question] where would you put object based permission logic
benjaminch opened this issue · 0 comments
Hello @katzien !
First of all, thanks a lot for this amazing repo showing all great examples :)
I was wondering, in a clean design, where would you put the object based permission logic?
- In domain services logic injecting a permission manager as done for repositories ?
PROS: logic will be the same across all transports (REST, CLI, etc)
CONS: I feel like it might not really be the proper place to put it (but maybe it is right to check permissions logic in the domain directly (e.q user, blog, post, comments)) - In the transport handlers
PROS: do not pollute domain logic
CONS: logic should be rewritten for every transport method (REST, CLI, etc)
Also, I would like to permissions information into the models so API clients knows what's possible or not to do on this model for the given user. For example, user 123
GET post 456
getting the following JSON response:
{
"id": 456,
"title": "Example",
"content": "blablabla",
"permissions": {
"userId": 123,
"canView": true,
"canEdit": true
}
}
This way, we don't need to do any extra call asking whatever the user can do X or Y on the given object like GET /permissions/posts/456
with user 123
which would return:
{
"userId": 123,
"canView": true,
"canEdit": true
}
Feels like option 1 (put logic in domain service) is better but it just doesn't sound right to have to handle this extra permission
model for each object ...
Did you have to tackle such things in the past? If so how did you do? What do you think about the above?
Thanks a lot :)