New answers tagged

0

You can mimic the structure of the AuthorizeAttribute. In one of my past projects, I segregated "authorizable" functionality into different methods and appended a customized authorization attribute to those methods. So if you need to authorize a sub-function of your controller methods, put that functionality into it's own method. You can pass static data to ...


0

Here is how I would approach the situation: You keep your Users table What you consider as Roles are, basically, groups of Users. So, we create a new table Groups What you call PermissionLevel is the equivalent to Roles that members of Groups can have (eg. a user who is Tech_Admin can have the role of Tech_Account and Non_Tech_account I would replace the ...


1

Your current design is this: You should ask yourself: does entity PERMISSION_LEVEL represent actual levels? Is they are actual levels it means that when a user is granted two different roles and both roles have the same command but with different levels, the app should take the highest level of them. In role-permission models with no permission level, ...


1

Does this look like a reasonable design for Role and Permission management ? The term "reasonable" is somewhat ambiguous here. Fit for purpose This design achieves it's purpose. It enables to determine what operations any logged-in user can do on any specific business object : Users are identified Roles are identified Users are assigned to roles ...



Top 50 recent answers are included