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
What's your scenario? What do you want to achieve?
I would love to get some advice on where to draw the border between model and policy. I have a simple RBAC model with some additional constraints modeled via the matcher. (This is all very clear, I don't need info about the matcher.) Model, policy and example requests can be seen at https://casbin.org/casbin-editor/#FNFCVSP37
Given the two approaches a) and b), which one is more casbin-idiomatic/better any maybe why? Should Casbin models and policies written so that there is as much logic/info in the model or in the policy? I'm asking because the static initial policy bits in variant a) never change and I have to preload them to my db-backed adapter always, which creates some noticeable boilerplate.
I know this is more of an aesthetic question, but I'd like to read some comments and learn about best practices for writing Casbin models/policies.
The text was updated successfully, but these errors were encountered:
Want to prioritize this issue? Try:
What's your scenario? What do you want to achieve?
I would love to get some advice on where to draw the border between model and policy. I have a simple RBAC model with some additional constraints modeled via the matcher. (This is all very clear, I don't need info about the matcher.) Model, policy and example requests can be seen at https://casbin.org/casbin-editor/#FNFCVSP37
Now that I have logic about my user groups in the matcher, I ask myself if the initial policy bits (lines 2 and 3 in the policy section of https://casbin.org/casbin-editor/#FNFCVSP37) are better coded in the model's matcher too as they're static anyway. https://casbin.org/casbin-editor/#CV9XS6HHF goes in that direction.
Given the two approaches a) and b), which one is more casbin-idiomatic/better any maybe why? Should Casbin models and policies written so that there is as much logic/info in the model or in the policy? I'm asking because the static initial policy bits in variant a) never change and I have to preload them to my db-backed adapter always, which creates some noticeable boilerplate.
I know this is more of an aesthetic question, but I'd like to read some comments and learn about best practices for writing Casbin models/policies.
The text was updated successfully, but these errors were encountered: