ASP.NET身份验证机制membership入门（转）

原文地址：http://yumincq.blog.163.com/blog/static/50776820108395417220/?fromdm&fromSearch&isFromSearchEngine=yes

几乎所有的系统中都会使用到访问控制和角色管理这样的功能，例如：新建、修改、删除用户和角色，为用户分配角色，管理角色中的用户等等。于是MS在ASP.NET 2.0开始，实现了这些功能，使得我们在开发中，不需要考虑这方面的内容，把更多的精力投入到业务逻辑的开发中去。从而大大的提高了开发的效率。下面我们就来学习一下如何使用membership。

1.添加数据库支持

　　　　要使用membership首先需要数据库的支持，所以我们第一步就是创建用来存放用户、角色等信息的表结构。别担心，MS早就把创建表的语句写好了，并且还提供了用户界面，让我们点点鼠标就可以创建好所需的结构了。

　　　　具体操作如下：进入C:\WINDOWS\Microsoft.NET\Framework\v2.0.xxxxx(vs2010的目录是v4.0.xxxx)这个目录下，找到aspnet_regsql.exe直接双击运行，就会弹出一个界面，直接下一步。第二个界面让我们选择是添加表结构还是移除，我们当然选择添加，继续下一步。在这个界面中需要填写服务器ip地址以及身份验证信息。在填写完毕后，就可以选择你要将表结构添加到哪个数据库中了。需要注意的是：如果选择默认，则会创建一个新的名叫aspnetdb的数据库，然后将表结构加入其中。一路下一步就完成了数据库结构的添加。

2.web.config配置

　　　　好了，表结构添加完毕，接下来就是需要在项目中进行一些简单的配置了。我们在vs中新建一个网站，随后再用记事本打开C:\WINDOWS\Microsoft.NET\Framework\v2.0.xxxxx\CONFIG\machine.config这个文件,找到system.web节点下的membership节点，将整个节点复制到我们新建网站的web.config中的system.web节点中。

　　　　复制过来的代码如下:

　　　　下面是主要的几个属性的含义:

　　　　　　name：数据提供程序的名称，由于我们是从machine.config复制过来的，所以必须改名，防止重名

　　　　　　type：数据提供程序类型,如果使用的是MSSQL数据库,则保持不变即可，如果使用的是Oracle等其他数据库，则必须自己创建一个类来继承MembershipProvider抽象基类，重写里边的所有抽象方法，然后把类型写在这里即可。

　　　　　　connectionStringName：该属性必须指定在<connectionStrings>节点中,一个连接字符串的名字。

　　　　　　applicationName：应用程序名称，membership允许多个应用程序共同使用一个数据库来管理自己的用户、角色信息，各应用程序只需配置不同的applicationName即可，当然，如果想要多个应用程序使用同一份用户角色信息，只需设置一样的applicationName即可。

　　　　　　requiresUniqueEmail：顾名思义，用户注册时，是否需要提供未注册过的邮箱。

　　　　　　passwordFormat：密码存储格式，密码保存在数据库中的格式，最常用的有Clear（不加密）和Hashed（使用SHA1算法加密）
　　　　　　minRequiredPasswordLength：最小密码长度。

　　　　　　minRequiredNonalphanumericCharacters：指定有效密码中必须包含的特殊字符的最小数量，就是说不是字母也不是数字的字符的数量，比如+-*/,.什么的，增加密码强度

　　　　　　好了,我们将配置修改一下并添加连接字符串：

　　　　上面用黄色高亮字体标注出来的属性，是为了告诉membership采用我们刚才添加的mySqlMembershipProvider这个配置，因为machine.config中有一个AspNetSqlMembershipProvider，我们又在web.config中又添加了一个mySqlMembershipProvider，现在有了两个配置，所以应该使用defaultProvider属性指明本网站使用哪个配置。随后又指定了连接字符串配置的名称，一个Email不允许重复注册，最小密码长度为6，不限制密码中必须含有标点符号等配置。

3.ASP.NET身份验证配置

　　　　membership算是配置到这里了，但是还没有结束，我们还需要把ASP.NET的身份验证机制配置为Forms身份验证。

　　补充内容：

　　ASP.NET一共有三种身份验证方式，分别为：

Forms验证
Windows验证
Passport验证

　　　　Windows验证是一种把能够访问到IIS的用户认为是已经通过身份验证的用户。可以通过windows自带的身份验证策略来控制哪些页面用户可以访问，哪些不能访问。这是一种最简单的方式，基本不用写多少代码，全部通过配置就可以实现访问的控制。

　　　　Passport验证是由微软提供身份验证服务。当然这是收费的。

　　　　Forms验证就是在用户登录时，向浏览器中添加一个cookie，然后在用户每次访问时都检测这个cookie，从而达到身份验证的目的。

　　　　配置Forms身份验证其实就是把下面代码复制到web.config中去就可以了：

<system.web>
  <authentication mode="Forms">
    <forms loginUrl="Login.aspx"
           protection="All"
           timeout="30"
           name=".ASPXAUTH"
           path="/"
           slidingExpiration="true"
           defaultUrl="default.aspx"
           cookieless="UseDeviceProfile"/>
  </authentication>
</system.web>

　　　　下面是说明(msdn抄的)：

loginUrl 指向应用程序的自定义登录页。应该将登录页放在需要安全套接字层 (SSL) 的文件夹中。这有助于确保凭据从浏览器传到 Web 服务器时的完整性。

protection 设置为 All，以指定窗体身份验证票的保密性和完整性。这导致使用 machineKey 元素上指定的算法对身份验证票证进行加密，并且使用同样是 machineKey 元素上指定的哈希算法进行签名。

timeout 用于指定窗体身份验证会话的有限生存期。默认值为 30 分钟。如果颁发持久的窗体身份验证 Cookie，timeout 属性还用于设置持久 Cookie 的生存期。

name 和 path 设置为应用程序的配置文件中定义的值。

requireSSL 设置为 false。该配置意味着身份验证 Cookie 可通过未经 SSL 加密的信道进行传输。如果担心会话窃取，应考虑将 requireSSL 设置为 true。

slidingExpiration 设置为 true 以执行变化的会话生存期。这意味着只要用户在站点上处于活动状态，会话超时就会定期重置。

defaultUrl 设置为应用程序的 Default.aspx 页。

cookieless 设置为 UseDeviceProfile，以指定应用程序对所有支持 Cookie 的浏览器都使用 Cookie。如果不支持 Cookie 的浏览器访问该站点，窗体身份验证在 URL 上打包身份验证票。

enableCrossAppRedirects 设置为 false，以指明窗体身份验证不支持自动处理在应用程序之间传递的查询字符串上的票证以及作为某个窗体 POST 的一部分传递的票证。

　　　　需要说明一下的是LoginUrl和DefaultUrl属性：LoginUrl指向登录页面，当ASP.NET判断出该用户请求的资源不允许匿名访问，而该用户未登录时，ASP.NET会自动跳转到LoginUrl所指向的页面，当登录成功后，则跳转回原来请求的页面。DefaultUrl指向默认页面。当我们直接访问登录页面，并登录成功后，这时ASP.NET会跳转到DefaultUrl指向的页面。其他的选项不写都可以，因为有默认值。

上篇讲到如何配置membership以及ASP.NET Forms身份验证，本篇将对权限控制部分，做一个详细的解释。

　　　　在所有的基本配置都完毕后，我们还需要配置哪些目录允许被匿名访问，哪些是需要用户登录后允许访问的页面。

　　　　首先：我们在项目中建立一个admin文件夹，在admin文件夹中添加一个web.config文件，然后在其中的<system.web>节点下面添加如下代码：

　　　　然后我们在admin目录下再添加一个页面，然后访问该页面，看一下效果。如果您按照我们上篇所说的内容全部正确配置了，那么你会发现，页面并没有显示出来，而是跳转到了我们之前在<authentication>下<forms>节点的LoginUrl属性所指向的页面，要求登录！这不就是我们需要的效果吗？

　　　　现在来解释一下上面配置的含义：

　　　　<allow>节点：顾名思义就是允许访问的意思，<allow users="admin"/>就是允许用户名为"admin"的用户访问。

<deny>节点：就是禁止访问。这里用到了一个通配符“*”，通配符有两个：*代表所有用户，还有一个“?”代表所有匿名用户。所以<deny users="*"/>就是不允许所有用户访问的意思啦，当然如果是：<deny users="?"/>那意思就是不允许所有匿名用户访问。

需要说明的是：所有的配置都是按照从上到下的顺序来匹配的，一但匹配成功，就不再向下匹配。举个例子：

ASP.NET首先检测当前登录的用户名=="admin"？如果等于则不继续判断，直接允许该用户访问。如果不等于则继续判断当前登录的用户名=="zhangsan"等于，则允许访问，不等于则接着向下，读取到了<deny users="*"/>这个配置，拒绝所有用户访问，跳转到LoginUrl指定的页面要求重新登录。

　　　　可是如果这样，只能实现目录一级的权限控制，如果要控制某个文件的访问权限，又该如何做呢？难道非得把这个文件放到一个文件夹中，然后再添加web.config进行控制么？答案是否定的，对于单个文件的访问控制，ASP.NET也有相应的配置：

　　　　看上面这个配置，我们可以在<system.web>节点之上（必须是上面）再增加一个<location>节点，通过path属性指明location内的配置是单独针对哪个文件即可。具体内容我就不多说了，想必大家也都看得懂。不过需要注意的一点就是：location节点可以有多个。这意味着同一个目录下的不同文件可以有不同的访问权限。

　　　　好了，配置到这里算是完成一多半了。还有一个问题就是：如果我们的用户比较多，那么需要在配置文件中把这些用户全部罗列其中。并且以后添加了新用户，还得继续修改配置，太麻烦了！该怎么办呢？通用的做法就是引入角色的概念。给所有的用户分配一个角色，比如：users，admin等。然后我们只需要控制这些角色的访问权限即可。以后添加了新用户只需给这个新用户分配角色，而不用去修改配置，实在是方便。其实，membership也提供了角色的概念，只需要简单的配置一下就可以实现了。

　　　　要实现角色功能，非常简单，我们还是去machine.config的<system.web>节点下面找到<roleManager>节点，然后整个节点复制过来到web.config中去，一般会有两个<add>子结点,我们删除一个，留下一个就可以了。全部内容如下：

　　　　这个配置比较简单，各项配置和前面配置都一样，不再多说。稍微修改一下：

　　　　注意：这个roleManager多了个属性enable="true"，这是因为角色管理默认情况下是关闭的，所以我们必须得设置为开启才行。