问题描述

我有一个 ASP.NET 2.0 [没有 ajax...yet] 网站，它将以编译形式部署在多个客户网站上.通常，该站点将仅用于 Intranet.一些客户信任他们所有人，不关心限制对站点和/或页面功能的访问，其他客户不信任任何人，只希望某些人和/或组能够查看某些页面、单击某些按钮等

I have an ASP.NET 2.0 [no ajax...yet] web site that will be deployed in compiled form on multiple customer sites. Typically the site will be intranet only. Some customers trust all of their people and don't care about limiting access to the site and/or page functions, others trust no one and want only certain people and/or groups to be able to view certain pages, click certain buttons, et al.

我可以做一些自己开发的解决方案，可能会从数据库表中驱动访问权限，但在我走这条路之前，我想我会问:这种情况有什么好的解决方案?最好是可以在 web.config 文件和/或数据库中完全控制的一个，因为重建网站是不可能的(对于客户端，我不想一遍又一遍地为他们做).Active Directory 集成将是一个奖励，但不是必需的(除非这样做更简单).

i could do some home-grown solution, possibly drive the access permissions from a database table, but before i go down that road i thought i'd ask in SO: what is a good solution for this situation? preferably one that can be controlled completedly in the web.config file and/or database, since rebuilding the web site is not possible (for the client, and i don't want to have to do it for them over and over). Active Directory integration would be a bonus, but not a requirement (unless that's just easier).

作为起点，我认为站点中的每个页面/功能点都被赋予一个身份并与一个权限组相关联......

as a starting point, i'm thinking that each page/function point in the site be given an identity and associated with a permission group...

允许/拒绝按角色和用户访问的 web.config 授权部分很好，但这只是问题的一半 - 另一半是控制对每个页面上各个方法(按钮，无论如何)的访问.例如，一些用户可以查看 whatchamacallits，而其他用户则可以编辑、创建、删除或禁用/启用它们.所有这些按钮/链接/操作都在查看页面上...

web.config authorization section to allow/deny access by role and user is good, but that is only half of the problem - the other half is controlling access to the individual methods (buttons, whatever) on each page. For example, some users can view whatchamacallits while others are allowed to edit, create, delete, or disable/enable them. All of these buttons/links/actions are on the view page...

[理想情况下我会让禁用的按钮不可见，但这在这里并不重要]

[ideally i would make the disabled buttons invisible, but that is not important here]

目前有一些不错的建议，但还没有完整的解决方案 - 仍然倾向于数据库驱动的解决方案......

some good suggestions so far, but no complete solution yet - still leaning towards a database-driven solution...

• 安全权限需求属性在按钮被点击时会抛出异常，这不是一件友好的事情；我宁愿隐藏不允许用户使用的按钮
• LoginView 控件也很有趣，但需要多次复制大部分页面内容(每个角色一次)并且可能无法处理用户具有多个角色的情况 - 我不能假设角色是分层，因为它们将由客户定义

平台为 Win2K/XP、Sql Server 2005、ASP.NET 2.0，未使用 AJAX

platform is Win2K/XP, Sql Server 2005, ASP.NET 2.0, not using AJAX

推荐答案

我更喜欢向 AD 组而不是特定用户授予访问权限.我发现它更灵活.

I prefer to grant access rights to AD groups rather than specific users. I find it's much more flexible.

我不太了解您的应用程序，但您可能想查看 web.config 文件中的授权标记:

I don't know much about your application, but you might want to look at the authorization tag in the web.config file:

<authorization>
    <!--  
        <deny users="?" />
        <allow     users="[comma separated list of users]"
                   roles="[comma separated list of roles]"/>
        <deny      users="[comma separated list of users]"
                   roles="[comma separated list of roles]"/>
    -->
</authorization>

您可以将 Web 应用程序中的每个目录的 web.config 文件分开，并且可以嵌套目录.每个 web.config 文件都可以有自己的授权部分.如果您在每个目录中放置不同的页面，您可以通过在每个 web.config 中允许特定角色并拒绝其他所有内容来有效地严格管理安全性.然后您可以管理活动目录中每个角色的成员.我发现这是一个有效的解决方案，因为它很好地利用了 Microsoft 的 Active Directory 和 ASP.NET 安全框架，而无需编写您自己的自定义内容，并且如果您使用角色，则可以将角色成员资格的管理分流给那些无需接触 web.config 文件，他们只需要知道如何使用 AD 管理控制台.

You can separate web.config files each directory within your web application, and you can nest directories. Each web.config file can have it's own authorization section. If you put different pages in each directory you can effectively tightly manage security by allowing a specific role in each web.config, and denying everything else. Then you can manage members of each role in active directory. I've found this to be an affective solution because it makes good use of Microsoft's Active Directory and ASP.NET security framework without writing your own custom stuff, and if you use roles, it's possible to offload the management of role membership to someone who doesn't ever have to touch the web.config file they just need to know how to use the AD management console.