转自：http://www.cnblogs.com/yssoft/archive/2009/01/05/1369784.html
ASP.NET 的安全认证，共有“Windows”“Form”“Passport”“None”四种验证模式。“Windows”与“None”没有起到保护的作用，不推荐使用；“Passport”我又没用过，唉……所以我只好讲讲“Form”认证了。我打算分三部分：
第一部分 —— 怎样实现From 认证；
第二部分 —— Form 认证的实战运用；
第三部分 —— 实现单点登录（Single Sign On）
第一部分 如何运用 Form 表单认证
一、 新建一个测试项目
为了更好说明，有必要新建一个测试项目（暂且为“FormTest”吧），包含三张页面足矣（Default.aspx、Login.aspx、UserInfo.aspx）。啥？有人不会新建项目，不会新增页面？你问我咋办？我看这么办好了：拖出去，打回原藉，从幼儿园学起……
二、 修改 Web.config
1、 双击项目中的Web.config（不会的、找不到的打 PP）
2、 找到下列文字
<authentication mode="Windows" /> 把它改成：
Code
3、 找到<authorization> <allow users="*" /></authorization>换成
Code这里没什么好说的，只要拷贝过去就行。虽说如此，但还是有人会弄错，如下：
Code若要问是谁把 <deny users="?"></deny> 放入 <authentication> 中的，我会很荣幸地告诉你，那是 N 年前的我：<authentication> 与 <authorization> 都是以 auth 字母开头又都是以 ation 结尾，何其相似；英文单词背不下来的我以为他们是一伙的……
三、 编写 .cs 代码——登录与退出
1、 登录代码：
a、 书本上介绍的
Codeb、 偶找了 N 久才找到的
Code以上两种都可发放验证后的 Cookie ，即通过验证，区别：
方法 a) 指验证后返回请求页面，俗称“从哪来就打哪去”。比如：用户没登录前直接在 IE 地址栏输入 http://localhost/FormTest/UserInfo.aspx ，那么该用户将看到的是 Login.aspx?ReturnUrl=UserInfo.aspx ，输入用户名与密码登录成功后，系统将根据“ReturnUrl”的值，返回相应的页面
方法 b) 则是分两步走：通过验证后就直接发放 Cookie ，跳转页面将由程序员自行指定，此方法多用于 Default.aspx 使用框架结构的系统。
2、 退出代码：
Code四、 如何判断验证与否及获取验证后的用户信息
有的时候，在同一张页面需要判断用户是否已经登录，然后再呈现不同的布局。有人喜欢用 Session 来判断，我不反对此类做法，在此我只是想告诉大家还有一种方法，且看下面代码：
CodeUser.Identity 还有两个属性AuthenticationType（验证类型）与 Name（用户名称） ，大家要注意的是 Name 属性，此处的User.Identity.Name将得到，验证通过（RedirectFromLoginPage 或SetAuthCookie）时，我们带入的第一个参数 this.Txt_UserName.Text 。这个参数很重要，关系到种种……种种的情况，何出此言，且听下回分解……
灵活运用 Form 表单认证中的 deny 与 allow 及保护 .htm 等文件
第二部分 Form 认证的实战运用
Web.config 的作用范围
新建项目时， VS.Net 会在项目根目录建立一个内容固定的 Web.config。除了在项目根目录，你还可以在任一目录下建立 Web.config ，条件就是应用程序级别的节点只能在根目录的 Web.config 中出现。至于哪些是应用程序级别节点呢，这个问题嘛，其实我也不太清楚，呵呵。电脑不是我发明的，微软不是我创建的，C# 更不是我说了算的，神仙也有不知道的，所以我不晓得是正常的。话虽如此，只要它不报错，那就是对的。
关于 Web.config 设置的作用范围，记住以下两点：
1、 Web.config 的设置将作用于所在目录的所有文件及其子目录下的所有东东（继承：子随父姓）
2、 子目录下的 Web.config 设置将覆盖由父目录继承下来的设置（覆盖：县官不如现管）
给大家提个问题：有没有比根目录Web.config 的作用范围还大的配置文件呢？看完第三部分便知分晓。
六、 学会拒绝与巧用允许
回到我们在第一回合新建的测试项目“FormTest” ，既然要进行验证，按国际惯例，就得有用户名与密码。那，这些用户是管理员自己在数据库建好呢，还是用户注册、管理员审核好呢。只要不是一般的笨蛋，都知道选择后者。你们还别说，我公司还真有个别项目是管理员连到数据库去建帐号的，属于比较特殊的笨蛋，咱们不学他也罢，还是老老实实添加两个页面吧——注册页面（Register.aspx）与审核页面（Auditing.aspx）。
问题终于就要浮出水面啦，当你做好 Register.aspx 时，想访问它的时候突然觉得不对劲，怎么又回到了登录页面？你仔细瞧瞧网址，是不是成了：Login.aspx?ReturnUrl= Register.aspx 。怎么办，用户就是因为没有帐号才去访问注册页面的呀？（这句纯属废话，有帐号谁还跑去注册。）我时常对我的同事说：“办法是人想出来滴！！”
1、 新建一个目录 Public ，用于存放一些公用的文件，如万年历、脚本呀……
2、 在“解决方案资源管理器”中右击点击目录 Public ，新增一个 Web.config
3、 把上述 Web.config 的内容统统删除，仅留以下即可：
<allow users="*"/> 替换 <deny users="?"></deny>
注解：“allow”允许的意思；“*”表示所有用户；
“deny” 拒绝的意思；“?”表示匿名用户；
因此，处于 Public 目录下的文件，允许所有人浏览，包括未验证的用户。把 Register.aspx 拖进来吧，再也不会有人阻止你浏览啦。
除了注册页面，我们还提到一个审核页面（Auditing.aspx），审核权限一般都在管理员或主管手里，并不想让其他人浏览此页面（真理往往掌握在少数人的手里，这也是没法子的事），怎么办？“办法是人想出来滴”呵呵……新建一个管理员的目录 ManageSys ，在此目录下再新增一个 Web.config。内容如下：
Code
Code之前我曾强调，要注意，第一个参数很重要，重要到什么程度？说到这，恐怕地球人都知道了——它就是allow与deny的依据。假如此处用户填写的是“Admin”即 this.Txt_UserName.Text = "Admin"; 那么进入系统后，他就能访问 ManageSys 目录下的网页了，其它闲杂人等一律拒之门外。
1: 在web.config中，加入form认证；
Code2: 如果有注册页面时还应该允许匿名用户调用注册页面进行注册;
以下代码应该在<configuration><system.web>之间,而不应该包含到<system.web>..</system.web>之间;
----------------表示允许 匿名用户对 userReg.aspx页面进行访问.
Code3 在登录成功后要 创建身份验证票, 表明已经通过认证的合法用户;
if(登陆成功)
Code
1.使用Forms验证存储用户自定义信息
Forms验证在内部的机制为把用户数据加密后保存在一个基于cookie的票据 FormsAuthenticationTicket中，因为是经过特殊加密的，所以应该来说是比较安全的。而.net除了用这个票据存放自己的信息外，还留了一个地给用户自由支配，这就是现在要说的UserData。
UserData可以用来存储string类型的信息，并且也享受Forms验证提供的加密保护，当我们需要这些信息时，也可以通过简单的get方法得到，兼顾了安全性和易用性，用来保存一些必须的敏感信息还是很有用的。
下面来看怎么使用UserData，然后会给出一个实际使用的例子。
Code参数
version 版本号。
name 与身份验证票关联的用户名。
issueDate Cookie 的发出时间。
expiration Cookie 的到期日期。
isPersistent 如果 Cookie 是持久的，为 true；否则为 false。
userData 将存储在 Cookie 中的用户定义数据
使用userdata也很简单，FormsIdentity的Ticket属性就提供了对当前票据的访问，获得票据后就可以用UserData属性访问保存的信息，当然是经过解密的。
Code
下面是一个具体的应用。
由于Forms验证是通过cookie来进行的，它需要传递一个票据来进行工作。虽然票据是加密的，里面的内容不可见，但这并不能阻止别人用一个假冒的身份使用票据（就像我们可以拿别人的钥匙去开别人的锁），比较常见的就是不同ip的用户在不安全通道截获了这个票据，然后使用它进行一些安全范围外的活动。
解决这个问题的办法之一就是使用SSL来传递信息。
但是如果不能使用SSL呢？我们可以判断ip和票据是否匹配，如果发出请求的ip是初次产生票据的ip，则没有问题，否则就销毁这个票据。
为此，我们需要在一开始处理登录时将用户的ip保存起来，这样就可以在以后的请求中随时验证后继请求的ip是否和初始ip相同。保存这个敏感ip的最佳场所当然是UserData啦，而验证的时机则是在AuthenticateRequest事件发生时，即Global.aspx.cs中定义的处理此事件的Application_AuthenticateRequest方法中。
上面的示例实际上已经是把用户ip保存到了UserData中，下面是验证的过程。
Code通过给GenericPrincipal空的GenericIdentity和roles使票据失效，这样将强迫用户重新登录。为了测试这个方法，可以先把条件改为相等，看效果如何 ：）
这个方法也有不足之处，具体为：
1.使用同一代理的用户将拥有同一个ip，这样就不能防范此类假冒攻击了
2.如果用户使用动态ip，则可能造成正常用户被我们强行销毁票据。不过总的来说，这个办法还是比较可行的。
2.使用安全特性配合Forms验证进行安全操作。
PrincipalPermissionAttribute可以配合Forms验证进行基于角色或用户的安全验证，该特性不能用于程序集级别。它的作用范围可以是类或具体的方法。来看一个简单的示例。
Code
注意这个例子一开始是作用于整个类的，生成后执行，如果当前用户不是Notus，就会发生异常System.Security.SecurityException，提示对主体权限的请求失败。反之，则可以顺利访问，并输出两个hello world!，注意是两个。现在的安全作用范围是整个类。
接下来我们改一下特性的作用范围。将特性声明移到sayHello2方法上面，重新编译后运行，就会发现程序在运行到sayHello2方法后抛出了System.Security.SecurityException。这说明现在安全作用范围缩小到了方法级别。
该特性可以通过设置User和Role来进行基于用户和角色的安全保护。另外其使用的第一个参数是SecurityAction枚举，该枚举设置了具体的保护级别或措施。像我们现在使用的这个Demand，是要求调用堆栈中的所有高级调用方都已被授予了当前权限对象所指定的权限。
下面是msdn给的示例
示例
下面的示例说明可以如何以声明方式使用 PrincipalPermission 要求当前用户是 Bob 并且属于 Supervisor 角色。
[PrincipalPermissionAttribute(SecurityAction.Demand, Name="Bob",
Role="Supervisor")]下面的示例说明如何要求当前用户的身份是 Bob，与角色成员条件无关。
[PrincipalPermissionAttribute(SecurityAction.Demand, Name="Bob")]
下面的示例说明如何仅要求对用户进行身份验证。
[PrincipalPermissionAttribute(SecurityAction.Demand, Authenticated=true)]
再要说一下的是，这里面的User和Role是可以和Forms验证集成的，据此，我们可以在一些重要的类或方法中使用PrincipalPermissionAttribute，以将自己的程序武装到家。
而实际上，该特性的作用远不止这些，更详细的信息可以查阅msdn。
或者:
1.配置Web.Config文件
设置为Form认证:
<authentication mode="Forms">
<forms name="oursnet" loginUrl="login.aspx" timeout="10" />
</authentication>
其中:
name: 决定验证用户时所使用的Cookie名称
loginurl: 在用户没有登录是,被重定向的页面
timeout: 超时时间,单位为分钟
不允许匿名登录
<authorization>
<!-- 允许所有用户 -->
<deny users="?" />
<!-- <allow users="[逗号分隔的用户列表]"
roles="[逗号分隔的角色列表]"/>
<deny users="[逗号分隔的用户列表]"
roles="[逗号分隔的角色列表]"/>
-->
</authorization>
其中:
users: 表示禁止访问资源的用户列表,使用通配符“?“拒绝匿名用户访问,使用"*",则表示拒绝所有的用户访问.
2.添加登录成功的代码:
Session.Contents["UserName"]=txtUser.Text;
FormsAuthentication.RedirectFromLoginPage(txtUser.Text,false);
Response.Redirect("index.aspx");
3.添加退出时的代码
System.Web.Security.FormsAuthentication.SignOut();
Response.Redirect("login.aspx");
============
l 综述
当某一个用户使用用户名成功登陆网站时，FormsAuthentication（窗体身份验证机制，下面统一使用英文术语） 将会创建一个authentication ticket (身份验证票),通过这个ticket就可以在网站上全程跟踪这个用户了。Form authentication ticket通常被包含在一个Cookie里面，但是ASP.net2.0也支持不使用Cookie的FormsAuthentication，这时候ticket就需要通过Query string 传递。
当一个用户在登陆某个网站时，需要提供身份验证才能进入网站。如果他还没有输入验证信息（通常是用户名和密码），则此用户将会被重定向到一个登陆页面。用户可以在登陆页面输入验证信息，然后这些信息被发送到服务器与某一个存储用户身份信息的介质（例如Sql Server或者某个文件）进行信息对比。在ASP.Net2.0中，可以通过MemberShip Proivder来访问存储在诸如Sqlserver的信息。（Provider模式有很多优点，稍后会有文章详细说明。）当用户信息通过验证后，此用户将获得允许，访问他所期望的页面。
FormsAuthentication通过FormsAuthenticationModule这个类来执行，这个类是ASP.net页面运行周期的一部分。以下我们将解释FormsAuthentication在ASP.net2.0中是如何工作的。
l IIS 验证
ASP.net验证分为两步。首先，IIS验证当前用户访问网站所使用的windows帐号是否有权限。如果IIS访问被配置为anonymous，则任何用户都能访问页面。
然后，在IIS验证完毕后，ASP.net开始执行自身的验证。验证模式可以在web.config文件中配置，只要在config文件中写上<authentication mode="Forms" />，那么ASP.net就知道使用FormsAuthenticationModule 类进行验证。
l ASP.Net Froms Authentication
Froms Authentication 配置：你可以在config文件中配置。配置如下：
<system.web>
<authentication mode="Forms">
<forms loginUrl="Login.ASPx" protection="All" timeout="30" name=".ASPXAUTH"
path="/"
requireSSL="false"
slidingExpiration="true"
defaultUrl="default.ASPx"
cookieless="UseDeviceProfile" enableCrossAppRedirects="false" />
</authentication>
</system.web>
这些属性详细描述如下：
loginUrl:指向登陆页面，你应改把登陆页面放在一个需要Secure Sockets Layer (SSL)的文件夹里。这样才能保障帐号的安全和完整。
potection:设置为”ALL”表明authentication ticket是加密的，加密算法被定义在machineKey这个元素中，并且通过哈希算法进行签名，这个算法也定义在machineKey中。
timout：该属性定义了验证session的过期时间。默认值为30分钟。
RequireSSL:该属性被设置为false，这表明验证的cookies可以不同过SSL加密传输。如果对session的安全性特别重视的话，则需要设置为true。
slidingExpiration:该属性被设置为true,这表示用户只要在网站上持续保持活动，则session就不会过期。
DefaultUrl:该属性表示登陆后的默认页面。
Cookieless：该属性被设置为UseDeviceProfile，这表示cookie将在任何支持它的浏览器中使用，如果该浏览器不支持cookie的话，form authentication将通过url来传递authentication ticket
enableCrossAppRedirects:该属性表示是否可以将通过身份验证的用户重定向到其他web应用程序。True表示可以，False表示不可以。
l Authorization Configuration（用户配置）
类UrlAuthorizationModule用来执行保障只有通过身份验证的用户才能访问页面。你可以在web.config文件中配置这个类：配置如下：
<ystem.web>
<authorization>
<deny users="?" />
</authorization>
</system.web>
以上配置表明，没有通过验证的用户都将被拒绝访问页面。如果一个没有验证的用户试图访问页面，他将会被重定向到loginUrl属性定义的登陆页面上。
l Forms Authentication 控制流程
Forms Authentication的流程可以参考下图：
我们来分析一下上面的流程：
第一步：用户访问default.ASPx页面，IIS通过了验证，ASP.Net发现 authorization
元素中包含<deny users="?" />的标签。
第二步：服务器寻找包含验证信息的cookie，如果没有找到这个cookie,用户将被重定向到登陆页面。就是loginurl所指定的页面。用户将在那个页面输入登陆信息。：
第三步：浏览器请求浏览登录页面，同时传递ReturnUrl的参数的值。
第四步：服务器调转到登陆页面。
第五步：用户输入身份验证信息，并且提交数据，其中还包含ReturnUrl的参数值。
第六部：服务器通过读取存储介质（例如sqserver数据库）验证用户的信息。登陆页面将创建一个包含form authentication ticket的cookie作为session。
在ASP.net2.0身份验证可以通过membership系统。Membership类提供了ValidateUser的方法，参考如下：
if (Membership.ValidateUser(userName.Text, password.Text))
{if (Request.QueryString["ReturnUrl"] != null) {FormsAuthentication.RedirectFromLoginPage(userName.Text,false); }
else { FormsAuthentication.SetAuthCookie(userName.Text, false); } }
else { Response.Write("Invalid UserID and Password");
}
第七步：用户验证成功，服务器重新让浏览器指向ReturUrl所指定的页面。
第八步：在重定向的同时，浏览器向default.ASPx页面发送request请求，此次请求包含用户的forms authentication cookie。
第九步：FormsAuthenticationModule类侦测到forms authentication cookie并且开始验证，验证成功后，该类将得到当前的用户信息，并传送给HttpContext对象。可以通过HttpContext对象获得当前用户的信息。
第10步：验证成功，来去自如哦！
l FormsAuthenticationModule
ASP.Net 2.0在系统默认的web.config文件中定义了一系列的Http模块(Http Modules).其中包括了一系列的验证模块如下：
<httpModules>
...
<add name="WindowsAuthentication" type="System.Web.Security.WindowsAuthenticationModule" />
<add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" />
<add name="PassportAuthentication" type="System.Web.Security.PassportAuthenticationModule" /> ... </httpModules>
在每一次请求时，只能使用一种验证模块。通常验证模式会被定义在web.config文件中：
<authentication mode="Forms" />这句话表示使用FormsAuthentication
FormsAuthenticationModule类会创建一个GenericPrincipal的对象，然后把它存入Http Context中。GenericPrincipal包含一个FormsIdentity的实例的引用，FormsIdentity实例包含了用户的信息。一般你会通过forms authentication来替你完成以上工作。但是如果你的程序还有别的特殊要求，比如把用户信息传递给一个自定义的类（该类继承IPrincipal接口），你的程序需要在PostAuthenticate Event事件中编写代码。PostAuthenticate Event事件会在 FormsAuthenticationModule验证forms authentication cookie 并且创建完GenericPrincipal和FormsIdentity对象后触发，在该事件触发后，你可以在事件中创建自定义的IPrincipal对象，用此对象封装FormsIdentity对象，然后把自定义的IPrincipal对象存入HttpContext中。
注意：如果自定义IPricipal对象，你必须在当前线程中设置自定义对象的引用：例如：Thread.CurrentPrincipal=newGenericPrincipal(new GenericIdentity( "Bob", "Passport"), rolesArray);
这样才能保证HttpContext对象和线程指向同一个验证用户的信息。
l Forms Authentication Cookies
FormsAuthentication类在调用FormsAuthentication.SetAuthCookie或者FormsAuthentication.RedirectFromLoginPage的方法后会自动创建验证Cookie;
一个典型的验证cookie包含以下两个属性：
Name：Cookie的名称
Value:Cookie的值
在一个典型的forms authentication cookie中，cookie的值是加密的，并且创建一个FormAuthenticationTicket的签名。Cookie包含以下属性：
Expires：此属性标识cookie的过期时间，当用户需要把cookie保存在本地电脑上时，需要设置此属性。
Domain:这个属性表明cookie和哪个域相关联，默认的值为null
HasKeys：这个属性表明cookie是否有子键。
HttpOnly: 这个属性表示cookie是否能被客户端脚本读取，.net2.0中，这个设置始终为true;但在客户端浏览器中，只有IE6.0才能识别这个属性。
Path:这个属性表明cookie的虚拟目录。默认的值为”/”,表示站点根目录。
Secure:这个属性表明cookie是否需要加密。如果设置true,cookie将接受SSL加密
Version:这个属性表明cookie的版本号
l 创建Forms Authentication Cookies
当某个用户验证通过后，Forms Authentication Cookies会被Forms Authentication类在内部自动创建。创建的就是一个FormsAuthenticationTicket类。创建此类的代码如下：
FormsAuthenticationTicket ticket = new FormsAuthenticationTicket(1,
"userName",
DateTime.Now,
DateTime.Now.AddMinutes(30), // value of time out property false, // Value of IsPersistent property
String.Empty,
FormsAuthentication.FormsCookiePath);
然后如果在web.config文件中，forms元素的protection属性被设置成ALL
下面将简要介绍一下当protection属性被设置为true时的流程：
n 创建一个序列化的forms authentication ticket：即创建此对象为一个字节数组（byte array）
n 创建forms authentication ticket的签名。machineKey中的validation和alidationKey的属性所设置了生成签名的算法。我们用此算法计算上面序列化的bytearray，生成MAC（message authentication code）。在默认的选择中，系统使用的是SHA1的算法。
n 加密forms authentication ticket，同时我们将创建另外一个序列化的对象，此对象经过加密算法加密。这个加密算法也可在machineKey中的decryption和decryptionKey的属性中获得。在ASP.net 1.1中使用的是3DES加密，而在ASP.net2.0中，使用的是AES加密算法。
n 创建HttpCookie对象或者生成cookie的query string，（在不支持cookie时，我们只能生成Query String）.HttpCookie 对象创建方法代码如下：
HttpCookie authCookie = new HttpCookie(
FormsAuthentication.FormsCookieName,
encryptedTicket);
加密后的ticket就被添加到了HttpCookie对象中。
n 设置forms authentication cookie为安全的。如果forms authentication ticket被配置成为使用SSL,那么HttpCookie. Secure的属性也必须设置成true.在这种情况下，浏览器只能通过HTTPS协议传送Cookies.
n 设置HttpOnly bit，在ASP.net2.0中,这个属性默认设置完成。
n 设置当前cookie的属性。如果需要，可以设置当前cookie的path, domain and和expires属性
n 添加cookie至cookiecollection,传给客户端。Response.Cookies.Add(authCookie);
每当authentication收到一个请求，FormsAuthenticationModule从客户端Cookie获得一个authentication ticket，然后解码，计算哈希值比对MAC值，这样就确认了cookie没有被人为伪造。最后验证ticket包含的过期时间。
注 ASP.NET 并不依赖于 Cookie 的到期日期，因为该时间很容易伪造。
l 角色授权(Role Authorization)
在 ASP.NET 2.0 中，角色授权已经得到简化。对用户进行身份验证或者将角色细节添加到身份验证 Cookie 时，不再需要检索角色信息。.NET Framework 2.0 包括一个角色管理 API，它使您能够创建和删除角色，将用户添加到角色以及从角色删除用户。该角色管理 API 将其数据存储在一个基础数据存储中，它通过针对该数据存储的适当角色提供程序访问该存储。以下角色提供程序为 .NET Framework 2.0 附带，可以与窗体身份验证一起使用：
? SQL Server。它是默认的提供程序，将角色信息存储在 SQL Server 数据库。
? 授权管理器 (AzMan)。该提供程序使用 XML 文件、Active Directory 或 Active Directory 应用程序模式 (ADAM) 中的一个 AzMan 策略存储作为其角色存储。它通常用于 Intranet 或 Extranet 方案中，其中 Windows 身份验证和 Active Directory 用于进行身份验证。
How To: Use Role Manager in ASP.NET 2.0.
l Cookieless窗体验证
ASP.NET 2.0 支持 cookieless 窗体身份验证。该功能由 forms 元素的 cookieless 属性控制。该属性可以设置为以下四个值之一：
? UseCookies。该值强制 FormsAuthenticationModule 类使用 Cookie 传输身份验证票。
? UseUri。该值指示 FormsAuthenticationModule 类重写 URL 来传输身份验证票。
? UseDeviceProfile。该值指示 FormsAuthenticationModule 类查看浏览器功能。如果浏览器支持 Cookie，则使用 Cookie；否则，重写 URL。
? AutoDetect。该值通过一个动态检测机制指示 FormsAuthenticationModule 类检测浏览器是否支持 Cookie。如果检测逻辑表明不支持 Cookie，则重写 URL。
如果应用程序配置为使用 cookieless 窗体身份验证，并且正在使用 FormsAuthentication.RedirectFromLoginPage 方法，则 FormsAuthenticationModule 类自动设置 URL 中的窗体身份验证票。以下代码示例显示了典型 URL 在重写后的外观：
http://localhost/CookielessFormsAuthTest/(F(-k9DcsrIY4CAW81Rbju8KRnJ5o_gOQe0I1E_jNJLYm74izyOJK8GWdfoebgePJTEws0Pci7fHgTOUFTJe9jvgA2))/Test.ASPx
括号中的 URL 部分包含 Cookie 通常将包含的数据。该数据在请求处理过程中由 ASP.NET 删除。该步骤由 ASP.NET ISAPI 筛选器执行，而不是在 HttpModule 类中执行。如果从一个 .ASPx 页读取 Request.Path 属性，您在 URL 中不会看到任何额外的信息。如果重定向请求，URL 将自动重写。
注:难以保证 URL 中包含的身份验证票的安全。当安全性极为重要时，您应该使用 Cookie 存储身份验证票。
l MemberShip和LoginControl（成员身份和登录控件）
ASP.NET 2.0 引入了MemberShip功能和一组登录 Web 服务器控件，它们简化了使用窗体身份验证的应用程序的实现。
MemberShip为应用程序用户提供凭据存储和管理。它还提供一个MemberShip API，可以在使用窗体身份验证时简化用户凭据的验证任务。该MemberShip功能构建于提供程序模型之上。该模型允许实现和配置指向不同用户存储的不同提供程序。ASP.NET 2.0 包括以下成员关系提供程序：
? Active Directory membership provider。该提供程序使用 Active Directory 或 Active Directory 应用程序模式 (ADAM) 用户存储。
? SQL Server membership provider。该提供程序使用 SQL Server 用户存储。
还可以添加对自定义用户存储的支持。例如，可以添加对其他轻量级目录访问协议 (LDAP) 目录或其他现有公共标识存储的支持。为此，创建一个从 MembershipProvider 抽象基类继承的自定义提供程序。
ASP.NET 登录控件自动使用MemberShip和窗体身份验证，并封装提示用户输入凭据，验证用户，恢复或替换密码等所需的逻辑。实际上，ASP.NET 登录控件在窗体身份验证和MemberShip上提供一个抽象层，并且取代了您使用窗体身份验证时通常必须进行的大多数或全部工作。
有关使用MemberShip功能和登录控件的详细信息，请参阅
How To: Use Membership in ASP.NET 2.0.
l Web Farm Scenarios(Web 场方案)
在 Web 场中，无法确保哪个服务器将处理连续请求。如果用户在一台服务器上经过身份验证，但下一个请求在另一台服务器上进行，则身份验证票将导致验证失败并请求用户重新进行身份验证。
machineKey 元素中的 validationKey 和 decryptionKey 属性用于对窗体身份验证票进行哈希操作和加密。这些属性的默认值为 AutoGenerate.IsolateApps。这些密钥是针对每个应用程序自动生成的，在每台服务器上都不同。因此，在一台计算机上加密的身份验证票无法在 Web 场中的另一台计算机或者同一台 Web 服务器上的另一个应用程序中进行解密和验证。
为了解决该问题， Web 场中所有计算机上的 validationKey 和 decryptionKey 值都必须相同。
有关配置 machineKey 元素的详细信息，请参阅 How To: Configure MachineKey in ASP.NET 2.0
Code终于切入正题了，不容易呀。根据“覆盖”原则，我们知道上述 Web.config 将替代根目录 Web.config 中的 <authorization> 节点设置，即：
