扩展 ASP.NET 角色提供程序
因为 RoleProvider 接口似乎将角色视为只不过是简单的字符串，所以我想知道是否有任何非 hacky 的方法可以为每个用户的角色应用可选值。
我们当前的登录管理系统将角色实现为键值对，其中值部分是可选的，通常用于明确或限制角色授予的权限。
例如，角色“编辑”可能包含用户“巴里”，但对于“巴里”，它将有一个可选值“猛禽”，系统会将其解释为意味着巴里只能编辑在“猛禽”下提交的文章类别。
我在其他地方看到过一个建议，即简单地创建额外的分隔角色，例如“editor.raptors”或类似的角色。这并不是真正理想的，因为它会大大增加角色的数量，而且我可以说，要取代我们当前的实现（这也不太理想，但具有自定义的优点）将是一个非常困难的事情与我们的用户数据库一起使用）。
我已经可以看出，上面提到的连接方法将涉及大量繁琐的字符串分割和部分匹配。
有更好的办法吗？
编辑：我最初的目标是使用更多内置的 ASP.NET 功能。例如，通过 Web.config 中的
回答 mnemosyn 的问题
- 是的。我们有一个用于用户、应用程序及其授权的中央数据库。这是一个核心系统，没有什么可以绕过的。
- 目前我们的系统是没有层级的，维护起来其实需要花费相当多的精力。创建应用程序时，会定义一组授权（例如，“admin”、“user”、“poweruser”、“gatekeeper”、“keymaster”等）。然后，将用户与这些授权关联起来，并使用可选值来实现用户和（特定于应用程序的）授权的唯一组合。
- 您能详细说明一下您所说的这些“类别”吗？
Because the RoleProvider interface seems to treat roles as nothing more than simple strings, I'm wondering if there is any non-hacky way to apply an optional value for a role on a per-user basis.
Our current login management system implements roles as key-value pairs, where the value part is optional and usually used to clarify or limit the permissions granted by a role.
For example, a role 'editor' might contain a user 'barry', but for 'barry' it will have an optional value 'raptors', which the system would interpret to mean that Barry can only edit articles filed under the 'raptors' category.
I have seen elsewhere a suggestion to simply create additional delimited roles, such as 'editor.raptors' or somesuch. That's not really going to be ideal because it would bloat the number of roles greatly, and I can tell it's going to be a very hard sell to replace our current implementation (which is also very less than ideal, but has the advantage of being custom made to work with our user database).
I can tell already that the concatenation method mentioned above is going to involve a lot of tedious string-splitting and partial matching.
Is there a better way?
EDIT: My initial goal was to use more built-in ASP.NET functionality. For instance, control access via <authorization/> elements in the Web.config. Doing this, as far as I can see, requires implementing roles themselves. Our current system's concept of auths seemed to fit very well apart from that one limitation.
Answering mnemosyn's questions
- Yes. We have a central database for users, applications and their authorisations. It's a core system and there's no going around it.
- Currently our system is not hierarchical, and it actually takes quite a lot of effort to maintain. When an application is created, a set of authorisations are defined (e.g., 'admin', 'user', 'poweruser', 'gatekeeper', 'keymaster', etc.). Users are then associated with those authorisations with the optional value for a unique combination of user and (app-specific) authorisation.
- Can you elaborate on these 'categories' of which you speak?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
对我来说，这确实听起来像是一个架构问题。
首先，您需要准确地确定您需要什么。第二步，将其映射到具体的实现。继续这一点：除了最简单的情况之外，我不会使用内置提供程序。另外，这个问题很快就会变得非常复杂，所以我会尽量保持简单。
为了详细说明您的需求，请尝试确定：
这里有一些提示：不要选择白名单，始终使用黑名单。控制白名单是一件痛苦的事情，尤其是。当很多规则聚集在一起时。例如，在 drupal 中，我认为这是主要缺陷之一（这就是为什么他们在版本 7 中重建它以使用黑名单）。允许用户做他们不应该做的事情通常比相反的问题要大得多。
Windows 文件访问概念非常复杂，因为它有黑名单和白名单，而且还可以继承 - 因此请尽量让您的解决方案比这简单得多。
字符串连接的事情对我来说听起来相当危险，无论如何我都会寻求更干净的解决方案。这种类型的元逻辑让人头疼。
This really sounds like an architectural issue to me.
First, you need to determine what you need, exactly. In a second step, map this to a concrete implementation. To jump ahead on that one: I wouldn't use the built-in providers for anything but the most simplistic cases. Also, this problem quickly gets very complicated, so I'd try to keep it as simple as possible.
To elaborate your needs, try to determine:
A few tips there: Don't go for whitelists, always use blacklists. Controlling whitelists is a pain, esp. when a lot of rules come together. In drupal, for example, I think this is one of the major flaws (which is why they're rebuilding it to use blacklists in version 7). Allowing a user to do something they shouldn't is usually a much bigger issue than the other way around.
The windows file access concept is very complicated, because it has both black- and whitelisting, which additionally can be inherited - so try to keep your solution much simpler than that.
The string concatenation thingie sounds rather dangerous to me, I'd go for a cleaner solution in any case. This type of meta-logic gives headache.