高级 .NET 会员/角色提供者
我需要具有以下功能的 RoleProvider：
将角色动态分配给任务
基于他们有权访问的系统中动态分配的任务对 IPrincipals 进行身份验证/授权
报告显示当前登录的人员以及其他常见使用情况统计信息。
我很确定我必须自己推出，但想确保我没有错过 OSS 甚至 MS 的任何东西。
我也在使用 ASP.NET MVC，所以我的基本计划是编写一个自定义属性，例如： [Authorize(Task=Tasks.DeleteClient)] 并将其放在需要授权的方法上。 我将根据用户在数据库中配置的任何设置来针对角色授权任务，而不是针对角色进行授权。
想法？
I'm in need of a RoleProvider with the following functionality:
Dynamic Assignment of Roles to Tasks
Authentication / Authorizaiton of IPrincipals based on the dynamically allocated tasks in the system they have privilege to access
Reporting showing who is currently logged in, and other common usage statistics.
I'm pretty sure I'm going to have to roll my own, but wanted to make sure I didn't miss out on something OSS or even from MS.
I'm also using ASP.NET MVC and so my basic plan is to write a custom attribute like: [Authorize(Task=Tasks.DeleteClient)]
and place it over the methods that need authorization.
Rather than authorizing against the Role, I'll authorize the task against the role based on whatever settings the user has configured in the DB.
Thoughts?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可能想查看 NetSqlAzMan。它允许您定义任务并将其分配给角色，然后对您的 IPrincipal 对象进行身份验证和授权。
您可能需要滚动自己的安全属性，但 NetSqlAzMan 应该有助于使这成为一项相当简单的任务。
You might want to check out NetSqlAzMan. It allows you to define tasks and assign them to roles and then authenticate and authorise your IPrincipal objects.
You may need to roll your own security attribute but NetSqlAzMan should help make that a reasonably easy task.
我们的一个系统也遇到了类似的问题。我要做的第一件事是为您的特定任务创建更多 AuthorizeAttribute 类 - 例如 DeleteClientAuthorize 等。然后您可以将特定逻辑添加到您的类中。
只要您可以访问触发当前用户角色更改的例程，就应该没问题。只需调用 Membership.DeleteCookie() ，这将强制下一个授权请求重新查询您的数据存储。此时您就可以确定现在需要哪些角色。
We had a similar issue with one of our systems. The first thing I'd do is create more AuthorizeAttribute classes for your specific tasks - e.g. DeleteClientAuthorize etc. You can then add specific logic into your classes.
As long as you can access the routines that trigger the change of roles for the current user you should be OK. Just call Membership.DeleteCookie() and this will force the next authorisation request to re-query your data store. It's at that point that you can determine what roles are required now.