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
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:
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:
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 :)
The text was updated successfully, but these errors were encountered:
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?
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))
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 post456
getting the following JSON response: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 user123
which would return: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 :)
The text was updated successfully, but these errors were encountered: