白标服务访问角色
好吧,
我知道我做错了,但找不到更好的方法。 我正在开发一个网站,该网站将允许用户设置自己的迷你网站。
有点像宁。 另外,我只有 1 个基本登录名,并且(现在)通过角色提供对每个迷你网站的访问。
所以我现在这样做的方式是:
每次创建一个新的迷你网站时 - 比如说,我在我的应用程序中创建 2 个角色。 blah_users 和 blah_admin
创建迷你网站的用户被赋予角色 - blah_admin,而所有其他想要加入此迷你网站(或网络)的用户被赋予角色 - blah_user。
任何人都可以查看任何网站的数据。 然而,要添加数据,必须是该迷你站点的成员(必须分配 blah_user 角色)
我面临的问题是,通过创建基于角色的系统,我必须手动执行大量操作。 对 User.IsAuthenticated 属性起作用的 Asp.Net 2 控件现在对我来说基本上没有用处,因为除了 IsAuthenticated 属性之外,我还必须检查用户是否具有正确的角色。
我猜想有更好的方法来构建系统,但我不确定如何做。 有任何想法吗?
该网站正在 IIS 6 上的 ASP.Net 2 中开发。 万分感谢!
Okay,
I know I'm doing something wrong - but can't figure out a better way.
I am developing a website which is going to allow users to setup their own mini-websites.
Something like Ning.
Also, I have only 1 basic login and access to each mini website is provided (right now) via roles.
So the way I am doing this right now is:
Everytime a new mini website is created - say blah, I create 2 roles in my application.
blah_users and blah_admin
The user creating the mini website is given the role - blah_admin and every other user wanting to join this mini website (or network) is given the role - blah_user.
Anyone can view data from any website. However to add data, one must be a member of that mini site (must have the blah_user role assigned)
The problem that I am facing is that by doing a role based system, I'm having to do loads of stuff manually. Asp.Net 2 controls which work on the User.IsAunthenticated property are basically useless to me now because along with the IsAuthenticated property, I must also check if the user has the proper role.
I'm guessing there is a better way to architect the system but I am not sure how.
Any ideas?
This website is being developed in ASP.Net 2 on IIS 6.
Thanks a tonne!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
恐怕 ASP.NET 的标准角色相关内容不是您所需要的。 您可以尝试更改身份验证模块,以便它:
我也不认为为每个站点设置特殊角色是个好主意。 当您有一百个站点时,您也会有两百个角色。 恐怕很难控制。
当我们解决类似的任务时,我们只是没有使用标准控件。 我们在所有站点上都使用一组角色。 具体用户的会员资格根据当前站点及其与本站点的关系确定。
另外:调查的另一种可能性是 ASP.NET 身份验证系统中存在的应用程序。 也许可以将每个子站点隔离到单独的应用程序中?
更新:适用于我们的应用程序的方法。
不要制作大量克隆角色。 仅使用两个:用户和管理员。 如果您的网站是公开的,那么“用户”角色可能只是全局的 - 一个网站上的用户与另一网站上的用户没有区别。 如果“用户”和“所有人”是不同的角色,那么“用户”当然也应该绑定到一个站点。
使用标准 ASP.NET 成员资格用户,但不使用标准角色机制。
制定一种存储站点和用户之间关系的机制。 它可以是保存站点 ID、用户身份和角色的简单表。
您必须重写 IsInRole 方法。 (准确地说,方法s,我稍后会介绍)。 该方法位于 IPrinciple 接口中,因此您必须创建自己的主体对象。 这很简单。
然后您必须将您的主体与请求相关联。 在 PostAuthenticateRequest 事件中执行此操作。
还有 RoleProvider。 老实说我不确定它什么时候使用,但它也有 IsInRole 方法。 我们可以用同样的方式覆盖它。 但该提供者的其他方法更难。 例如 AddUsersToRoles。 它接受用户名和角色的数组,但它应该添加到什么上下文(站点)? 到当前? 不确定,因为我不知道这个方法什么时候被调用。 所以这需要一些实验。 我看到(Reflector 有所帮助)RopePrincipal 本身使用 RoleProvider 来获取角色列表,所以也许它仅使用标准主体实现 RoleProvider。 对于我们的应用程序来说,这不是一个案例,所以我不能说这里可能隐藏什么问题。
I afraid standard roles-related stuff of ASP.NET is not what you need. You can try to change authentication module so it will:
I also don't think that making special roles for each site is good idea. When you would have hundred sites, you would also have two hundred roles. Pretty unmanageable, I afraid.
When we were solving similar task, we were just not using standard controls. We had single set of roles used on all sites. Membership of concrete user is determined according to current site and his relations to this site.
Addition: Another possibility to investigate is Application that exists in ASP.NET authentication system. Maybe it's possible to isolate each subsite into separate application?
Update: Method that works for our application.
Do not make a lot of cloned roles. Use only two: users and admin. If your sites are public then "users" role could be just global - user on one site doesn't differ from user on another site. If "users" and "everyone" are different roles, then of course "users" should also be bound to a site.
Use standard ASP.NET Membership users, but do not use standard role mechanism.
Make a mechanism for storing relation between site and user. It could be simple table that holds site id, user is and role.
What you have to override is IsInRole method. (Methods to be exact, i'll cover it later). This method is in IPrinciple interface, so you have to make your own principal object. It's quite simple.
Then you have to associate your principal with a request. Do it in PostAuthenticateRequest event.
There is also RoleProvider. Honestly I'm not sure when is it used, but it also have IsInRole method. We can override it in the same way. But other methods of this provider are harder. For example AddUsersToRoles. It accepts array of user names and roles, but to what context (site) should it be added? To current? Not sure, because I don't know when this method is called. So it requires some experiments. I see (Reflector helps) that RopePrincipal by itself uses RoleProvider to fetch list of roles, so maybe it's implement only RoleProvider, using standard principal. For our application this is not a case, so I can't say what problems could be hidden here.