如何使用 MS 角色和角色设计用户对象模型 会员资格
我想为一个典型的 Web 应用程序构建一个“用户”对象模型……但是我无法决定如何最好地设计对象模型和对象模型。 角色系统。
基本上我计划有大约 4 种用户类型……这将对应于会员资格提供商中的用户“角色”。
这些类型将是: • 工人 • 雇主 • 客人 • Admin
超级类型是: • 用户
此外——用户可以是“工人”和“工人”。 有时是“雇主”。
我想使用 MS 角色和角色 会员提供商和 将导航 UI 设置为响应用户角色。
我的问题是: 我怎样才能最好地将这些用户设计得更加灵活(用户可以是工人和雇主)。 如何处理登录/角色程序?
(我正在考虑一个具有“行为”对象工厂(工人行为、雇主行为)的用户)
对于登录用户登录...找到其角色并转换为其子类型。
这是应该这样做的吗?
I would like to build a ‘User’ Object model for a somewhat typical web application…however I cannot decide how best to design the object model & role system.
Basically I plan to have about 4 user types…which will correspond to user ‘roles’ in the membership provider.
These types will be:
• Worker
• Employer
• Guest
• Admin
The super type is:
• User
In addition – a User could be both a ‘Worker’ & an ‘Employer’ at times.
I would like to use the MS Roles & Membership provider & have navigation UI set to respond to User Role.
My question is:
How can I best design these Users to be flexible (User can be Worker & Employer).
How do I handle the Login / Roles Procedure?
(I am thinking about a User with a Factory for ‘Behavior’ objects (worker behavior, Employer Behavior ) )
For Login-User logins in … finds its role and Casts to its subtype.
Is this how it should be done?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
事实证明,仅使用角色概念本身就足以满足我的需要。 它没有提供足够低的粒度来控制权限。 举个例子,您可能有一个工作者角色和一个管理员角色,然后在代码中使用principal.IsInRole("Admin")来检查他们的角色,以确定他们是否可以修改某些值(比如工资)。 然后有人改变了主意,说主管可以改变工资,但仍然不是管理员。 现在您必须更改访问检查以添加另一个角色检查。 痛苦且例行公事。
因此,我所做的就是列出应用程序中的所有功能,然后允许它们与数据库中的所有功能关联。 我的访问检查看起来像principal.HasPermission("CHANGESALARY")。 我根据用户登录时所附加的角色加载用户权限。这样,企业就可以创建所需数量的功能组并为其命名。 然后它们可以应用于任何用户。
我创建一个自定义主体对象并将其附加到线程,以便我可以在整个页面生命周期的任何代码中使用它。 该对象具有从数据库加载权限的代码和检查权限的方法。
我通常发现框架中的“提供者”适合一小类应用程序,但无法满足大多数需求。 当你按照自己的意愿弯曲它们时,从头开始编写会更容易。
Using just the concept of role by itself has always proven to be in adequate for me. It doesn't provide low enough granularity to control permissions. AS an example you may have a worker role and and an admin role and then in code you use principal.IsInRole("Admin") to check their role to determine if they can modify some value (say salary). Then someone changes their mind and says that supervisors can change salaries but still aren't admins. Now you have to go change you access check to add in another role check. Painful and routine.
So what I do is make a list of all the features in the application and then allow them to be associated in to a role all in the database. The my access checks look like principal.HasPermission("CHANGESALARY"). I load up the users permissions based on the role they are attached to when they log in. This way the business can create as many groups of features they want and name them. They can then be applied to any user.
I create a custom principal object and attach it to the thread so that I can use it in any code throughout the page life cycle. This object has the code for loading the permissions from the database and the methods for checking permissions.
I generally find that the "providers" in the framework are good for a small class of applications and come up short for most needs. By the time you are done bending them to your will, it would have been easier to just write it from scratch.
老实说,这可能不是一个很好的解决方案,但它可能有助于产生一些其他想法。
我的角色是所有可能的权限组合:
在我的代码中,我有一个用于各个权限的枚举
,并且有一个与数据库中的角色相对应的枚举。 整数值是权限的按位或:
然后我可以使用一组方法来查找权限之类的:
如果您想出更好的方法或进行改进,请告诉我,以便我可以将其合并到我的中自己的代码。 :-)
To be honest, this is probably not a very good solution, but it might help to generate some other ideas.
My Roles are all of the possible combinations of permissions:
In my code I have an enum for the individual permissions
and I have an enum that corresponds to the Roles in the database. The integer values are the bitwise OR of permissions:
Then there's a set of methods I can use to look up permissions and whatnot:
If you come up with a better method or make improvements, please let me know so I can incorporate it back into my own code. :-)