ASP.NET 安全认证—UML软件工程组织

UML软件工程组织

ASP.NET 安全认证

2008-02-21 作者:寒羽枫(cityhunter172) 来源:csdn

序

代码写 N 久了，总想写得别的。这不，上头说在整合两个项目，做成单一登录（Single Sign On），也有人称之为“单点登录”。查阅相关文档后，终于实现了，现在把它拿出来与大家一起分享。或许大家会问：“这与标题不符呀？”别急，在下笔之前，我脑子里想到了我刚使用 Form 认证时遇到的一些问题，以及使用过程用到的一些技巧（实乃投机取巧是也 ^_^ ）。偶打初中那时，语文水平就不怎么滴，考试常常作文写不出来，所以写作水平有限，还请大家海量。对了，本人不仅写作水平有限，编程能力也不是很好，此文供大家学习交流之用，欢迎广大劳苦群众拎着鸡蛋、捧着鲜花前来评论。转载请注明原创作者乃寒羽枫是也，不甚感激！

废话也说的差不多了，言归正传， ASP.NET 的安全认证，共有“Windows”“Form”“Passport”“None”四种验证模式。“Windows”与“None”没有起到保护的作用，不推荐使用；“Passport”我又没用过，唉……所以我只好讲讲“Form”认证了。我打算分三部分：

第一部分 —— 怎样实现From 认证；

第二部分 —— Form 认证的实战运用；

第三部分 —— 实现单点登录（Single Sign On）

第一部分 —— 怎样实现From 认证；

一、新建一个测试项目

为了更好说明，有必要新建一个测试项目（暂且为“FormTest”吧），包含三张页面足矣（Default.aspx、Login.aspx、UserInfo.aspx）。啥？有人不会新建项目，不会新增页面？你问我咋办？我看这么办好了：拖出去，打回原藉，从幼儿园学起……

二、修改 Web.config

1、双击项目中的Web.config（不会的、找不到的打 PP）

2、找到下列文字 <authentication mode="Windows" /> 把它改成：

</authentication>

3、找到<authorization> <allow users="*" /></authorization>换成

这里没什么好说的，只要拷贝过去就行。虽说如此，但还是有人会弄错，如下：

</authentication>

若要问是谁把 <deny users="?"></deny> 放入 <authentication> 中的，我会很荣幸地告诉你，那是 N 年前的我：<authentication> 与 <authorization> 都是以 auth 字母开头又都是以 ation 结尾，何其相似；英文单词背不下来的我以为他们是一伙的……

三、编写 .cs 代码——登录与退出

1、登录代码：

a、书本上介绍的

private void Btn_Login_Click(object sender, System.EventArgs e)

{

if(this.Txt_UserName.Text=="Admin" && this.Txt_Password.Text=="123456")

{

System.Web.Security.FormsAuthentication.RedirectFromLoginPage(this.Txt_UserName.Text,false);

}

b、偶找了 N 久才找到的

private void Btn_Login_Click(object sender, System.EventArgs e)

{

if(this.Txt_UserName.Text=="Admin" && this.Txt_Password.Text=="123456")

{

System.Web.Security.FormsAuthentication.SetAuthCookie(this.Txt_UserName.Text,false);

Response.Redirect("Default.aspx");

}

以上两种都可发放验证后的 Cookie ，即通过验证，区别：

方法 a) 指验证后返回请求页面，俗称“从哪来就打哪去”。比如：用户没登录前直接在 IE 地址栏输入 http://localhost/FormTest/UserInfo.aspx ，那么该用户将看到的是 Login.aspx?ReturnUrl=UserInfo.aspx ，输入用户名与密码登录成功后，系统将根据“ReturnUrl”的值，返回相应的页面

方法 b) 则是分两步走：通过验证后就直接发放 Cookie ，跳转页面将由程序员自行指定，此方法多用于 Default.aspx 使用框架结构的系统。

2、退出代码：

private void Btn_LogOut_Click(object sender, System.EventArgs e)

{

System.Web.Security.FormsAuthentication.SignOut();

}

四、如何判断验证与否及获取验证后的用户信息

有的时候，在同一张页面需要判断用户是否已经登录，然后再呈现不同的布局。有人喜欢用 Session 来判断，我不反对此类做法，在此我只是想告诉大家还有一种方法，且看下面代码：

if(User.Identity.IsAuthenticated)

{

//你已通过验证，知道该怎么做了吧？

}

第二部分 Form 认证的实战运用

话说上回，简单地说了一下 Form 表单认证的用法。或许大家觉得太简单，对那些大内高手来说应该是“洒洒水啦”“小 Kiss 啦（小意思）”。今天咱们来点的花样吧：古有六扇门，拒收叶孤城；东门不刮风，吹雪姓西门；缎带作凭证，决战紫禁城。

五、 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 的内容统统删除，仅留以下即可：

<?xml version="1.0" encoding="utf-8"?>

<system.web>

</system.web>

</configuration>

终于切入正题了，不容易呀。根据“覆盖”原则，我们知道上述 Web.config 将替代根目录 Web.config 中的 <authorization> 节点设置，即：

注解：“allow”允许的意思；“*”表示所有用户；

“deny” 拒绝的意思；“?”表示匿名用户；

因此，处于 Public 目录下的文件，允许所有人浏览，包括未验证的用户。把 Register.aspx 拖进来吧，再也不会有人阻止你浏览啦。

除了注册页面，我们还提到一个审核页面（Auditing.aspx），审核权限一般都在管理员或主管手里，并不想让其他人浏览此页面（真理往往掌握在少数人的手里，这也是没法子的事），怎么办？“办法是人想出来滴”呵呵……新建一个管理员的目录 ManageSys ，在此目录下再新增一个 Web.config。内容如下：

<?xml version="1.0" encoding="utf-8"?>

<system.web>

</authorization>

</system.web>

</configuration>

现在的问题就是怎么才能知道谁是“Admin”呢，这个问题就有点象“我的鞋底有个洞”—— 天不知地知，你不知我知。闲话少说（要是有稿费多好，我就有多写几个字的动力，唉……），大家还记得我在第一部分的结尾吗？什么，忘啦！罚你回去看一百遍，记住了再回来。站住，回来！一想到你的记性，我就不放心，第一部分的浏览网址是http://blog.csdn.net/cityhunter172/archive/2005/11/06/524043.aspx ，回到此处的网址是http://blog.csdn.net/cityhunter172/archive/2005/11/13/528463.aspx

好了，不管那些记不好的家伙了，大伙继续往下看。

System.Web.Security.FormsAuthentication.SetAuthCookie(this.Txt_UserName.Text,false); //通过验证，发放 Cookie

之前我曾强调，要注意，第一个参数很重要，重要到什么程度？说到这，恐怕地球人都知道了——它就是allow与deny的依据。假如此处用户填写的是“Admin”即 this.Txt_UserName.Text = "Admin"; 那么进入系统后，他就能访问 ManageSys 目录下的网页了，其它闲杂人等一律拒之门外。

为巩固上述内容，给大伙留个课外作业：此项目有两部门使用，其中每个部门分别都有些特定的页面仅供本部门用户浏览使用，请问该如何使用 Web.config 达到效果？同样，答案在第三部分揭晓

七、分散与集中

乍看之下，就象是马克思列宁主义、毛泽东思想、邓小平理论中的辩证关系，大伙放心，偶是学理科的，只明白“高举程序员的伟大旗帜，以编写代码为中心”。停……

到目前为此，我们的测试项目“FormTest”已经拥有两个目录三个 Web.config ，伴随用户需求的多样化，Web.config 也会越来越多，比如常用的文件上传功能等等。众多的 Web.config 分布在不同的目录里面，维护起来肯定比较烦人。能不能集中起来管理呢，应该咋办哩？“办法是……”哟，有人先说出来啦。不错，“办法的确是人想出来滴” ，我不说，你是不是只有在一边凉伴？开玩笑的，为了让更多的人记住这句话，我打算告诉你集中管理的办法。

要想集中管理，不得不用到 <location> 节点与 path 属性。在本项目中，我们将目录 Public 与 ManageSys 下的设置放在根目录下的 Web.config 里面，如下：

<?xml version="1.0" encoding="utf-8"?>

<system.web>

</authorization>

</system.web>

</location>

<system.web>

</authorization>

</system.web>

</location>

<system.web>

</system.web>

</configuration>

需要提醒的是

1、 <location> 节点的位置是在 <configuration> 的一个子节点，它与原有的 <system.web> 属于并列关系

2、 <location> 节点只需要放入对应子目录 Web.config 中的 <system.web> 的节点内容

八、额外的保护

第二部分就要结束了，现在时间已是凌晨 4 点50分，我容易嘛我。认证的目的就是为了防止他人非法浏览页面，或未经许可使用某些功能。当然，世上没有绝对的安全，如今 MD5 加密都被我们国人给破解了，就是最好的例证。

细心的人可能早就发现 ASP.NET 的安全认证只针对 .aspx、.ascx …… 等 ASP.NET 文件起作用，而对普通页面与文件却“视而不见”，如 .htm、.js 、.jpg 等。通过以下步骤你就可以保护你想保护的文件类型。

1、打开 Internet 信息服务(IIS)管理器 → 右击本项目虚拟 → 属性，如下图

2、点击按钮“配置”，出现如下对话框：

3、双击 .aspx 的应用程序扩展 → 查看对话框内容，如下图：

4、复制“可执行文件”的全路径名称后 → 点击“取消”返回上一层对话框 → 点击按钮“添加”

5、粘贴刚才复制的内容（我的系统装在 D 盘，所以内容为 D:/WINDOWS/Microsoft.NET/Framework/v1.1.4322/aspnet_isapi.dll ） → 填写后缀名为 .htm → 填写动作限制为“GET,HEAD,POST,DEBUG”（为方便省事你可选全部）

6、最后点击“确定” → 往项目中添加 HtmlPage1.htm → 在 IE 浏览器的地址栏直接输入http://localhost/FormTest/HtmlPage1.htm → 观看测试效果

最后送大家一段 Web.config 设置，发完睡觉，实在是困的不行了。

<system.web>

</authorization>

</system.web>

</location>

<system.web>

</authorization>

</system.web>

</location>

第三部分实现单点登录（Single Sign On）

“等了好久终于等到今天，写了好久终于就快完结，但是网友的反应却让我有一些的伤心。盼了好久终于盼到今天，忍了好久终于把此文撰写，那些受冷落的无奈早就无所谓，累也不说累”（歌词《今天》新演绎）。看着人家的 Blog 文章的评论是一条接一条，再瞧瞧自己：“无人问津呐，真…无…奈……唉，没人理我，还是回家吧。”“哎，还没开始写，怎么就走了？回去干什么呢？”回去写作业去啊，上回交待的课外作业你做了没？（注：http://blog.csdn.net/cityhunter172/archive/2005/11/13/528463.aspx 在第二部分第六节布置的课外作业：此项目有两部门使用，其中每个部门分别都有些特定的页面仅供本部门用户浏览使用，请问该如何使用 Web.config 达到效果？）

不知有多少人做了作业，其实答案并不难。只需要在验证用户名与密码后，取得该用户的部门名称或部门代码，把它作为判断的依据就行了。最好不要用部门的数字ID，那样不利于以后的维护。

有一个秘密，一般人我不告诉他。Web.config 中的 <location> 节点的path 属性可以是一张具体页面的相对 URL 路径，如下：<location path ="ManageSys/Auditing.aspx">

好了，接下来就要揭开“比根目录Web.config 的作用范围还大的配置文件”之谜啦，它就是藏匿在 Windows 系统目录下，支配整个 .Net Framework 配置的传说中的Machine.config ！！下面请大家以热烈的掌声，欢迎我们这位神秘侠客的闪亮登场……

九、 Machine.config

Machine.config ，性别不详，年龄未知，家庭出身：XML。深藏于“云深不知处”的操作系统目录下的某某地方（注：C:\WINDOWS【或 WINNT 】\Microsoft.NET\Framework\v1.1.4322【或 v1.0.3705 】\CONFIG），控制着“更上一层楼”的 .NET Framework 的本机配置。接下来简要的讲解一下它的内容，以及它与 Web.config 的关系。

经过“松下问童子”，我们好不容易找到这位隐者，打开一看，乖乖，足有 3700 多行！！“叫我怎么能不难过，偶只想看看是啥结构，可内容实在是太多太繁琐……”还记得偶经常对同事说的一句话么：“办法是人想出来的！”它不是有三千七百多行吗，那我们就不管三七能否得出二十一啦，把它拷出来先。它不是 XML 出身吗，那咱们就还其正身，重新命名为“machine.xml”。接着用 IE 浏览器将这位改头换面的隐者打开，把节点与注释一一合拢。这回你看到了吧，是不是很有成就感？你要是想谢谢我，就让我看到你在此文下面的评论吧。多多益善，呵呵。

Machine.config 与 Web.config 是啥关系？四个字 —— 父子关系。记得我在第二部分第五节讲解 Web.config 作用范围的时提到两点 —— 继承与覆盖（详见http://blog.csdn.net/cityhunter172/archive/2005/11/13/528463.aspx），在此也同样适用。

1、 Machine.config 中的设置将作用于运行在本机的所有站点及其虚拟目录，遇到子目录将一直继承下去。

2、 Web.config 中的设置将覆盖由 Machine.config 中继承下来的对应的节点设置

说到这，再告诉大家一个秘密 —— “世上本无秘密，知道的人多了，便成了不是秘密的秘密！”

a、 Machine.config 中的 <system.web> 节点所有内容都能出现在项目根目录下的 Web.config 中，也就是说能在 Web.config 中的内容已经在 Machine.config 中一一列出；

b、其中 <system.web> 节点下的 <pages> 还能出现在页面上，如： HTML 视图下，在WebForm1.aspx 的第一行加上<pages> 的节点内容validateRequest="false" （此句意思是不对WebForm1.aspx页面文本框输入的值，是否包含 “<” “>” 等等具有危险性的代码进行检查，下一节将具体运用到）

<%@ Page language="c#" Codebehind="WebForm1.aspx.cs" AutoEventWireup="false" Inherits="FromTest.WebForm1" validateRequest="false" %>

十、单点登录（Single Sign On）的前提条件

之前说了这么多关于 Machine.config 的事，都是为了实现单点登录作铺垫，那何为单点登录（Single Sign On）？从字面理解就是在一个地方登录，通常运用于 ASP.NET 分布式环境中（跨单个服务器上的多个应用程序或在网络场中）的 Forms 身份验证。打个比方，就好比现在 Sohu（搜狐）与 Chinren（中国校友录）的做法，我在 Sohu 登录以后就不需要在 Chinaren 登录了。台湾与香港又把 Single Sign On 称之为“单一登入”。

要想实现此功能，首要条件是需要一组用于加密与验证加密的密钥。它们位于 Machine.config 中，修改 <system.web> 节点下的 <machineKey> 节点属性，如下：

1、 validationKey 为用于验证加密数据的密钥。最小长度为 40 个字符（20 字节），最大长度为 128 个字符（64 字节）。

2、 decryptionKey 为用于加密数据的密钥。长度只有 16 个字符（8 字节）与 48 个字符（24 字节）两种。

3、 validation 为用数据验证使用的加密类型。拥有“SHA1”“MD5”“3DES”三种方法

4、大伙参照上述 <machineKey> 试着在WebForm1.aspx运行下列语句：

this.TextBox2.Text ="ht"+"tp"+"://"+firstKey+"."+secondKey +"."+thirdKey

大家在修改之前请先备份一下 Machine.config ，到时要是出错可别怪我没提醒你。以上密钥并不是胡乱得来的，接下来向大家介绍生成密钥的方法。

我们把上一节中提到的 WebForm1.aspx 拖入本项目的 Public 目录下，再往页面上拖入一个 TextMode=MultiLine 的TextBox3 与一个 Button 编写按钮事件与函数：

private void Button1_Click(object sender, System.EventArgs e)

{

string decStr = this.CreateKeyString(int.Parse(this.TextBox1.Text));

string valStr = this.CreateKeyString(int.Parse(this.TextBox2.Text));

this.TextBox3.Text=string.Format("<machineKey validationKey=\"{0}\" decryptionKey=\"{1}\" validation=\"SHA1\"/>",valStr,decStr);

}

/// <summary>

/// 生成加密型强随机 Key 值

/// </summary>

/// <param name="i">Key 的有效长度：

/// decryptionKey 的有效值为 8 或 24；

/// validationKay 的有效值为 20 至 64

/// </param>

private string CreateKeyString(int i)

{

System.Security.Cryptography.RNGCryptoServiceProvider rng = new System.Security.Cryptography.RNGCryptoServiceProvider(); //加密随机数生成器

byte[] bt = new byte[i];

rng.GetBytes(bt);//用加密型强随机值序列填充字节数组

System.Text.StringBuilder str = new System.Text.StringBuilder();

for(int j= 0;j<i;j++)

{

str.Append(string.Format("{0:X2}",bt[j])); //转换成大写的十六进制文本

}

return str.ToString();

}

每次点击按钮生成密钥都不同，大家不妨多点几次。切换至 HTML 视图，到WebForm1.aspx 第一行把 validateRequest="false" 去掉，然后再多点几次 Button1试试，看看会有什么效果，嘿嘿………

十一、单点登录（Single Sign On）的站点示例

将上述 TextBox3 产生的文本，覆盖Machine.config 中的，现在你的机器已经具备了单点登录的条件。大伙可以再新建一个项目 FormTest2 ，从 FormTest2 登录后直接输入 FormTest 中的Default.aspx 的网址（http://localhost/FormTest/ Default.aspx），反之亦可。

下面结合实例讲解：偶在山东每步科技网站申请了一个免费二级域名 172.meibu.com，并下载了每步的 4.0 版的动态域名解析客户端。现在使用 ADSL 拔号上网，也就是说我的电脑已经成了 Web 服务器，同时支持 SQL Server 、Oracle 空间高达 200 G 想怎么弄就怎么弄，够牛吧，嘿嘿。布署上来的项目有环胜数码网站、权限管理系统、IT 内部管理网，以上三个项目是偶一人全权开发的。所谓全权就是从数据库存储过程写到 .cs 代码再到 javascript ，最后到美工都是偶一手搞定的。^_^ 我把这三个不相干的项目做成了单点登录的模式，加上整合站点的主页面，共有四个地方可以进行登录。因为用户 Table 的结构不同，因此只有一个入口能在进入后，在跳转站点时不会出错，那就是在整合页面登录。

现在我想把环胜数码这个站点单独脱离出来，而剩下的两个站点继续实现单点登录，该怎么做呢？或者是我的 ASP.NET 的空间是租的，服务商肯定不可能让我修改 Machine.config ,我又咋办哩？“办法是人想出来滴！！”，根据上述 Machine.config 与 Web.config 的关系，我们可以把 <machineKey> 节点放入项目根目录下Web.config的 <system.web> 节点。如下：

1、权限管理系统项目的 Web.config 用于 Form 认证的设置

</authentication>

2、 IT 内部管理网项目的 Web.config 用于 Form 认证的设置

</authentication>

大家可能会迫不急待的去试一把，偶赞成这样的做法，因为事实是检验真理的唯一办法。你不去试着自己动手，光看我在这说是很难提高的。先别急，我已经知道你想说什么，听听我慢慢向你解释：

a) 两个项目Web.cinfig的<machineKey> 节点确保以下几个字段完全一样：validationKey 、decryptionKey 、validation

b) 两个项目的 Cookie 名称必须相同，也就是 <forms> 中的 name 属性，这里我们把它统一为 name ="172.MEIBU.COM_PROJECT"

c) 注意区分大小写

在整合的过程中，我把遇到的问题向大伙说一下，以免你们走同样的路。

1) 首先应该是用户管理的问题，把两个项目的用户整合在一起，可不是一件容易的事，原则是新建一个新的 Table 只存放帐号与密码，用账号做关联，编写触发器，做到 Table 之间的同步；

2) 不要指望两个项目间用 Session 进行传值，两个应用程序的 Session 是无法共享的。网上有人曾把类库（编译后的 .dll 文档）放入同一个 bin 文件夹实现过 Session 共享，这样的做法实际上是把两个项目变相合并成一个应用程序，不是我们所想要的，理由很简单：Sohu 与 Chinaren 的服务器分处两地该怎么办？

3) 项目间的传值，可用 Cookie 实现。在第一部分的第三节（http://blog.csdn.net/cityhunter172/archive/2005/11/06/524043.aspx）我们介绍了只要运行 System.Web.Security.FormsAuthentication.SetAuthCookie 方法即可实现登录，单点登录的实质就是含有身份验证票的 Cookie 能在项目间共用。

接下来，有必要向大家介绍一下 Cookie 在 .Net 中的用法。

十二、 Cookie 在 ASP.NET 中的用法

大家也许和我一样，很少在 ASP.NET 中使用 Cookie ，传参数呀，存变量呀，用的比较多的是 Session 或 ViewState 以及隐藏控件，有的干脆用“ ? ”的请求方式。

1、 Cookie 存放的目录

Cookie 是存放在客户端的东东，放在“Temporary Internet Files”目录，所以说存在安全性的问题。大伙可通过以下方式找到具体位置：打开控制面板 → Internet 选项 → 常规 → Internet 临时文件 → 设置 → 即可看到“当前位置”，→ 点击“查看文件”将直接打开该文件夹，你也可以点击“移动文件夹”变更它所在的位置。参照下图

2、 Cookie 的有效期

从上图我们可以清楚的看到每个 Cookie 文档的“截止期”（即为有效期）。在有效期内，当登录计算机的用户 Administrator 再次访问 172.meibu.com 时，那么 IE 就会在请求页面的同时，连同上述的名称为“Cookie:administrator@172.meibu.com”的Cookie 文档内容一起发送给服务器。

若该文档包含多个 Cookie 的值时，截止期则以最后的失效期为准。

3、 Cookie 的类型

这里我们按有效期来分，分为两种：

a)即时型

指的是关闭浏览器（所有浏览 172.meibu.com 的 IE）后，Cookie 便失效，此类 Cookie 不会在“Temporary Internet Files”目录出现。其实它也有截止期的，为“0001-01-01”

b)持久型

就是已指定具体“截止期”的，能够在“Temporary Internet Files”目录里面找到的 Cookie

4、 Cookie 的内容

双击打开“Cookie:administrator@172.meibu.com”，我们看到以下内容，如下图：

上图中，“■”是换行符，你若是要打破什么锅来问我到底是怎么知道的话。我倒是会很乐意的告诉你：这就是经验！偶从学习 C# 那刻起，就拿第一个 Windows 程序 €€€€ 记事本来开刀，保存文档时得来的经验。

所以服务器读出来的格式如下图：

5、在 ASP.NET 页面发放 Cookie

发送上述 Cookie 的 .cs 代码为：

System.Web.HttpCookie ck = new HttpCookie("ckValue0");

ck["Author"] ="CityHunter";

ck.Expires = System.DateTime.Now.AddMinutes(10);//若不指定，则为即时型 Cookie

//ck.Path="/FormTest/ManageSys"; //设置 Cookie 的虚拟路径，注意一定要以“/”开头，否则为无效 Cookie ；请大家自行看一下它与在客房端的 Cookie 文档“名称”与 “Internet 地址”的关系

Response.Cookies.Add(ck);

ck = new HttpCookie("ckValue1"); //重新新建一个名为 ckValue1 的 Cookie

ck.Expires = System.DateTime.Now.AddMinutes(20); //即刻起 20 分钟后失效

ck["E_Mail"] ="cityhunter172@126.com"; //设置 ckValue1 中的 E_Mail 值

ck["PersonalWeb"] ="172.meibu.com";

Response.Cookies.Add(ck); //添加此 Cookie

6、取回已发放 Cookie 的值

Response.Write(Request.Cookies["ckValue0"]["Author"]+"<br>");//用不着说明了吧

Response.Write(Request.Cookies["ckValue1"]["E_Mail"]+"<br>");

Response.Write(Request.Cookies["ckValue1"]["PersonalWeb"]);

好久没有出作业啦（何出此言？），这第三篇呀，可是花了偶两个星期的业余时间调试、总结、撰写哪，都说时光贵如金，不知我花的这些时间能换来多少银子？换银子，我看是没指望啦，能得到阁下的一句评论，偶也满足了。记住，你的评论就是偶继续写下去的动力。

作业：给 Cookie 赋于以下值，怎样得到它的正确值

ck["str1"] ="2222";

ck["str"] ="str0=11111&str1=223";

可以肯定的是Request.Cookies["ckValue1"]["str"] 得不到 “str0=11111&str1=223”这个字串，大家不妨试一下 Request.Cookies["ckValue1"]["str1"] 会得到意想不到的字串哟。

提示：使用 Server.UrlEncode()与Server.UrlDecode()

十三、发放永久性的验证 Cookie

终于……终于……最后一个章节，蓦然回首，洋洋洒洒十二章。没想到年少时写不完作文的偶，居然也能编出几千余字的文章来呀，不得不佩服偶自己呀！再回首，一大片晕倒的人……。永远到底有多远？永久究竟是多久？只有天知道。

大家登录 CSDN的时候是否留意到一个“2 周内不用再登录”的复选框，它又是怎么做到的呢？大家是否曾遇到过这样的困惑：在执行System.Web.Security.FormsAuthentication.SetAuthCookie 时明明已指定createPersistentCookie 为 true 为何关闭浏览器仍不能直接访问网站？下面我们就这个问题给大家解释一下，且介绍如何手工创建身份验证票并加入 Cookie 中。

System.Web.Security.FormsAuthenticationTicket tk = new System.Web.Security.FormsAuthenticationTicket(

1, //指定版本号：可随意指定

"Admin", //登录用户名：对应 Web.config 中 <allow users="Admin" … /> 的 users 属性

System.DateTime.Now, //发布时间

System.DateTime.Now.AddYears(100), //失效时间：100 年以后，够永够久了吧

false, //是否为持久 Cookie：尚未发现有何用，至少目前偶还不知，下面会有说明

"测试用户数据"//用户数据：可用 ((System.Web.Security.FormsIdentity)User.Identity).Ticket.UserData 获取

);

string str = System.Web.Security.FormsAuthentication.Encrypt(tk);//加密身份验票

//声明一个 Cookie，名称为 Web.config 中 <forms name=".APSX" … /> 的 name 属性，对应的值为身份验票加密后的字串

System.Web.HttpCookie ck = new HttpCookie(System.Web.Security.FormsAuthentication.FormsCookieName,str);

//指定 Cookie 为 Web.config 中 <forms path="/" … /> path 属性，不指定则默认为“/”

ck.Path=System.Web.Security.FormsAuthentication.FormsCookiePath;

//此句非常重要，少了的话，就算此 Cookie 在身份验票中指定为持久性 Cookie ，也只是即时型的 Cookie 关闭浏览器后就失效；因此上面我说：我是真的还不知在身份验票中指定为持久性 Cookie 有何用。

ck.Expires = System.DateTime.Now.AddYears(100);

Response.Cookies.Add(ck); //添加至客房端

后记

此系列文章共三部分，历时一个月完成（2005-11-05 ~ 2005-12-06）。以上是我学习并用于实践的一些经验，在此拿出来与大家一起分享。代码都是经过调试的，如有任何疑问，可在 CSDN 论坛（http://community.csdn.net/）找到我，我的 ID 是 cityhunter172 （可用此 ID 发短消息给我），昵称为寒羽枫，欢迎大家批评指正。

第四部分 Form 认证的补充

前三篇在 CSDN 论坛公布后，效果如同“神仙放屁——果然不同凡（反）响”。为感谢广大网友的热情与支持，这不，经过这一阵子的酝酿、修炼，特意准备了这第四响。

之前我们讲述的使用 Form 认证实现单点登录，正如网友所说的那样，只能在同一域名下使用。对于跨域名的单点登录，除了使用 Passport 认证外，我们还是可以用 Form 认证的，只是要讲究方法而已啦。正所谓“山不转水转，人不转心转”。

一、跨域名的解决思路

在MSDN 2003 上搜索关键字“Passport”，偶找到一篇“Passport 身份验证提供程序”。文章讲述了 Passport 的认证原理，共 8 条，我就不多说了，大伙自个看吧。其中有一句话，引起偶的注意：“……响应在查询字符串中包含一个加密的 Passport Cookie……”。也正是此句才有了下面的思路。

所谓认证的通过与否，其实质就是检测有无发放有效的 Cookie ，使用 Form 也好，运用 Passport 也罢，都是 Cookie 在起作用。也就是说，我们只要把有效的 Cookie 在登录后一次性发放给客户端就得了。

二、跨域名、跨服务器的单点登录方法

1、如何在本机模拟跨域名、跨服务器的Single Sign On

只要浏览网址不同就相当于不同域名，在本机至少有以下三种。它们虽然是同一项目，彼此却不能共用 Session与 Cookie ，也就无法共享身份验证票：

a). http://localhost/FormTest/Login.aspx

b). http://127.0.0.1/FormTest/Login.aspx

c). http://My_Computer_Name/FormTest/Login.aspx //以电脑名称浏览站点

d). http://192.168.0.8/FormTest/Login.aspx //以网卡地址浏览站点

e). http://172.meibu.com/FormTest/Login.aspx //拥有国际域名

2、在 ASP.NET 中如何提交给其它页面

用过ViewState 的大概都知道，ViewState是保存在客户端的。不知大伙注意没有，ASP.NET 为每张 .aspx 页面都配备了独自的 ViewState，且被解析后都是以一个 name=" __VIEWSTATE" 的隐藏控件值来保存ViewState。每次页面提交，服务器都会检查该控件的值有无被篡改，如此一来就注定 .aspx 只能提交给本页。服务器是死的，人是活的，我们不能被这些条条框框限定死了，我们要把程序写成活的。

下面咱们从 http://localhost/FormTest/Login.aspx 输入用户名与密码，然后提交给http://127.0.0.1/FormTest/Public/LoginTransfer.aspx 。Login.aspx与LoginTransfer.aspx都包含用户名输入框一个、密码输入框一个、登录按钮一个。在 Login.aspx 页面加入以下代码：

this.Btn_Login.Attributes["onclick"]="SingleSignOn()"; //指定执行脚本事件

在 Login.aspx 页面上插入以下脚本：

function SingleSignOn()

{

//只能用脚本改变指定 Form 提交的对象

document.getElementById("Form1").action="http://127.0.0.1/FormTest/Public/LoginTransfer.aspx?FromUrl="+window.location.href;

//把隐藏控件 __VIEWSTATE 中的值变更为 LoginTransfer.aspx 解析后出现的值，以实际看到的值为准

document.all.__VIEWSTATE.value = "dDwtMTkyODUzMTMyNzs7Pv1cp2RaxUcr5hGYf8ILX9/EMKy8";

}

</script>

注意事项

a). LoginTransfer.aspx 出现的控件及其 ID ，必须能够在 Login.aspx 找到

b). 控件的 ID 必须一致，且能一一对应

c). 关于 __VIEWSTATE中的值，它与页面控件ID 无关，与浏览该页面的网址无关，目前我只知道和控件的数量、类型、名字空间（namespace FormTest.Public ）以及存在的 ViewState有关系。大家在测试时，以直接浏览http://127.0.0.1/FormTest/Public/LoginTransfer.aspx 后，查看页面源文件所看到的值为准。

d). 提交后，将触发并执行LoginTransfer.aspx 中的Btn_Login_Click 事件

3、基本思路

各个站点的登录页面统一将用户名与密码提交给 LoginTransfer.aspx ，同时各个站点需要一个增加 Cookie 的页面，用于将加密后的身份验证 Cookie 添加至客户端。此乃经过一番考量后，最终确定的可行性方案。

4、第一种思路——天女散花

何谓天女散花，就是把 Cookie 在登录后一次性全发放出去，就如同天仙在空中散花一样，场面是何等的壮观。下面开始写代码：

为更好的区分，我们将负责添加 Cookie 的页面分开命名：

a). http://localhost/FormTest/Public/AddCookie_A.aspx

b). http://127.0.0.1/FormTest/Public/AddCookie_B.aspx

c). http://My_Computer_Name/FormTest/Public/AddCookie_C.aspx

这三张页面的功能一样，所以代码也就相同啰

private void Page_Load(object sender, System.EventArgs e)

{

string from = Request["FromUrl"]; //起始 URL 路径

string next = Request["NextUrl"]; //还需要跳转的 URL

string key = Request["CookieTicket"]; //已加密的 Cookie 文本

if(key != null && key !="")

{

System.Web.HttpCookie ck = new HttpCookie(System.Web.Security.FormsAuthentication.FormsCookieName,key);

ck.Path=System.Web.Security.FormsAuthentication.FormsCookiePath;

ck.Expires = System.DateTime.Now.AddYears(100);

Response.Cookies.Add(ck); //将传过来的已加密的身份验证票添加至客房端

string url = next.Split(';')[0]; //从 URL 中拆分出将要跳转的下一张页面

next = next.Replace(url+";",""); //带入下一轮跳转的字串

if(url!="")

{

//跳至下一页面 Response.Redirect(url+"?CookieTicket="+key+"&FromUrl="+from+"&NextUrl="+next);

}

else //已没有下一页面可供跳转

{

Response.Redirect(from); //回到起始页面

}

接下来编写 LoginTransfer.aspx 的代码：

//页面常量 allLoginUrl 存放所有站点的 AddCookie.aspx 的 URL，注意以 ; 分隔

public const string allLoginUrl =

"http://localhost/FormTest/Public/AddCookie_A.aspx;"

+"http://127.0.0.1/FormTest/Public/AddCookie_B.aspx;"

+"http://My_Computer_Name/FormTest/Public/AddCookie_C.aspx;";

偶已在上面讲述了，如何点击 Login.aspx 中的登录按钮Btn_Login将用户名与密码提交给 LoginTransfer.aspx ，并执行LoginTransfer.aspx 中的Btn_Login_Click 事件。

private void Btn_Login_Click(object sender, System.EventArgs e)

{

string from = Request["FromUrl"]; //起始 URL 路径

string next = this.allLoginUrl;

//由于控件 ID 相同，所以此处得到的是由 Login.aspx 提交过来的用户名与密码

if(this.Txt_LoginName.Text=="Admin"&&this.Txt_Password.Text=="123456")

{

System.Web.Security.FormsAuthenticationTicket tk = new System.Web.Security.FormsAuthenticationTicket(1,"Admin", System.DateTime.Now, System.DateTime.Now.AddYears(100),false,"测试用户数据" );

string key = System.Web.Security.FormsAuthentication.Encrypt(tk); //得到加密后的身份验证票字串

string url = next.Split(';')[0]; //从 URL 中拆分出将要跳转的下一张页面

next = next.Replace(url+";",""); //带入下一轮跳转的字串

Response.Redirect(url+"?CookieTicket="+key+"&FromUrl="+from+"&NextUrl="+next); //跳至下一页面

}

5、第二种思路——后羿射日

后羿射日，意思指的是用户点哪就跳哪。他若是点“火坑”，你也得往里跳，因为用户是上帝嘛。我们增加一个通行证页面 MyPassport.aspx ，由 http://127.0.0.1/FormTest/Public/LoginTransfer.aspx 发放验证 Cookie 后直接跳转至 http://127.0.0.1/FormTest/MyPassport.aspx 。不要告诉我你不会，你要是真不会，那偶也没法子啦，还得请你回头看看，偶在第三篇是如何讲述发放永久性验证 Cookie 吧（http://blog.csdn.net/cityhunter172/archive/2005/12/06/545301.aspx）。还需要一张用作跳板的跳转页面 MyTransfer.aspx 。

MyPassport.aspx 的代码：

<a target ="_blank"

href="MyTransfer.aspx?goto=http://localhost/FormTest/Public/AddCookie_D.aspx">

美丽的天使</a>

<a target ="_blank"

href="MyTransfer.aspx?goto=http://127.0.0.1/FormTest/Public/AddCookie_E.aspx">

快乐的天堂</a>

<a target ="_blank"

href="MyTransfer.aspx?goto=http://My_Computer_Name/FormTest/Public/AddCookie_F.aspx">

大大的火坑</a>

MyTransfer.aspx 的代码：

private void Page_Load(object sender, System.EventArgs e)

{

//获取身份验证票

System.Web.Security.FormsAuthenticationTicket tk =((System.Web.Security.FormsIdentity)User.Identity).Ticket;

string key = System.Web.Security.FormsAuthentication.Encrypt(tk); //每次加密后的字串都是不同的

string next = Request["goto"]; //将要跳转的 URL

Response.Redirect(url+"?CookieTicket="+key); //跳转至下一页面

}

AddCookie_D.aspx、AddCookie_E.aspx、AddCookie_F.aspx 这三张页面的代码：

string key = Request["CookieTicket"]; //已加密的 Cookie 文本

if(key != null && key !="")

{

System.Web.HttpCookie ck = new HttpCookie(System.Web.Security.FormsAuthentication.FormsCookieName,key);

ck.Path=System.Web.Security.FormsAuthentication.FormsCookiePath;

ck.Expires = System.DateTime.Now.AddYears(100);

Response.Cookies.Add(ck); //将传过来的已加密的身份验证票添加至客房端

Response.Redirect("../Index.aspx"); //跳转至你真正想带客户去的地方

}

6、点评

两者共同点：

a). 每个站点都需要一个登录的提交点、一张添加 Cookie 的页面。

b). 因为只能靠发放验证 Cookie 来识别身份，所以一台电脑不能同时登录两个帐号。

c). 都存在不同程度的安全隐患。

两者不同点：(天女散花以下简称“开女”，后羿射日就简称“后羿”)

a). 天女一次性发放 Cookie ，如果站点较多，处理起来还是需要一些时间的。而后羿则相反，站点再多也不怕。

b). 天女在散花的过程中，如果中途被卡住，则需要一个错误处理机制做回退处理。后羿则不需要。

c). 天女在登录后可以直接在 IE 地址浏览其想看的站点；而后羿则必须从通行证的跳板页面进入才行。

根据上述问题，给几点建议：

a). 不要使用永久性 Cookie ，应指明身份验证票的过期时间，注意不是 Cookie 的有效期。

b). 在身份验证票的 UserData 中加入其它的验证信息或存放用户 ID

c). 在网络通畅的情况下，比如局域网，站点又相对较少，建议选用天女。50 个站点之间做跳转应该不会超过 10 秒（前提是已编译好了，且不是初次访问）。

三、跨域名、跨服务器的退出方法

只要理解了“天女散花”，退出就比较容易啦。为每个站点准备一个用于退出的页面，如下：

a). http://localhost/FormTest/Public/Logout.aspx

b). http://127.0.0.1/FormTest/Public/Logout.aspx

c). http://My_Computer_Name/Public/FormTest/Logout.aspx

private void Page_Load(object sender, System.EventArgs e)

{

System.Web.Security.FormsAuthentication.SignOut();//删除 Cookie 中的身份验证票

string from = Request["FromUrl"];

string next = Request["NextUrl"];

string url = next.Split(';')[0];

next = next.Replace(url+";","");

if(url!="")

{

Response.Redirect(url+"?FromUrl="+from+"&NextUrl="+next);

}

else

{

Response.Redirect(from);

}

对啦，还有一张 LogoutTransfer.aspx. ，代码偶就不写，大家自个完成吧。

序

第一部分 —— 怎样实现From 认证；

第二部分 Form 认证的实战运用

第三部分 实现单点登录（Single Sign On）

第四部分 Form 认证的补充

第三部分实现单点登录（Single Sign On）