asp.net单点登录
转自：http://blog.163.com/fgofh_janet/blog/static/1360925882010112292457133/
如何运用 Form 表单认证
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、 找到下列文字
3、 找到
这里没什么好说的，只要拷贝过去就行。虽说如此，但还是有人会弄错，如下：
若要问是谁把
三、 编写 .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)
{
//你已通过验证，知道该怎么做了吧？
}
User.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 的内容统统删除，仅留以下即可：
<&xml version="1.0" encoding="utf-8"&>
终于切入正题了，不容易呀。根据“覆盖”原则，我们知道上述 Web.config 将替代根目录 Web.config 中的
注解：“allow”允许的意思；“*”表示所有用户；
“deny” 拒绝的意思；“&”表示匿名用户；
因此，处于 Public 目录下的文件，允许所有人浏览，包括未验证的用户。把 Register.aspx 拖进来吧，再也不会有人阻止你浏览啦。
除了注册页面，我们还提到一个审核页面（Auditing.aspx），审核权限一般都在管理员或主管手里，并不想让其他人浏览此页面（真理往往掌握在少数人的手里，这也是没法子的事），怎么办？“办法是人想出来滴”呵呵……新建一个管理员的目录 ManageSys ，在此目录下再新增一个 Web.config。内容如下：
<&xml version="1.0" encoding="utf-8"&>
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 分布在不同的目录里面，维护起来肯定比较烦人。能不能集中起来管理呢，应该咋办哩？“办法是……”哟，有人先说出来啦。不错，“办法的确是人想出来滴” ，我不说，你是不是只有在一边凉伴？开玩笑的，为了让更多的人记住这句话，我打算告诉你集中管理的办法。
要想集中管理，不得不用到
<&xml version="1.0" encoding="utf-8"&>
需要提醒的是
1、
2、
八、 额外的保护
第二部分就要结束了，现在时间已是凌晨 4 点50分，我容易嘛我。认证的目的就是为了防止他人非法浏览页面，或未经许可使用某些功能。当然，世上没有绝对的安全，如今 MD5 加密都被我们国人给破解了，就是最好的例证。
细心的人可能早就发现 ASP.NET 的安全认证只针对 .aspx、.ascx …… 等 ASP.NET 文件起作用，而对普通页面与文件却“视而不见”，如 .htm、.js 、.jpg 等。通过以下步骤你就可以保护你想保护的文件类型。
1、 打开 Internet 信息服务(IIS)管理器 → 右击本项目虚拟 → 属性，如下图
(screen.width-461) window.open('http://blog.csdn.net/images/blog_csdn_net/cityhunter172/85935/r_aspxForm01.JPG');" src="http://blog.csdn.net/images/blog_csdn_net/cityhunter172/85935/r_aspxForm01.JPG" border=0>)
2、 点击按钮“配置”，出现如下对话框：
(screen.width-461) window.open('http://blog.csdn.net/images/blog_csdn_net/cityhunter172/85935/r_aspxForm02.JPG');" src="http://blog.csdn.net/images/blog_csdn_net/cityhunter172/85935/r_aspxForm02.JPG" border=0>)
3、 双击 .aspx 的应用程序扩展 → 查看对话框内容，如下图：
(screen.width-461) window.open('http://blog.csdn.net/images/blog_csdn_net/cityhunter172/85935/r_aspxForm03.JPG');" src="http://blog.csdn.net/images/blog_csdn_net/cityhunter172/85935/r_aspxForm03.JPG" border=0>)
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 设置，发完睡觉，实在是困的不行了。
ASP.NET 安全认证（三）
看了之后，再写点自己的做法（属于初学级别）
其实
.............
(中间很可以加上很多权限控制的页面)
..............
达到的效果是一样的。以下是贴MSDN上的内容。
可选属性
属性选项说明
path 应用指定配置设置的资源。使用缺少路径属性的
allowOverride 指定配置设置是否可以被子目录中的 Web.config 文件的配置设置重写。
true指定配置设置可以被重写。默认值为 true。
false指定配置设置不可以被重写。
示例
以下示例允许匿名用户访问 Logon.aspx 页。
以下示例仅将指定页的上载文件大小限制设置为 128KB。
以下示例防止配置设置被子目录中的 Web.config 文件更改。
第三部分 —— 实现单点登录（Single Sign On）
单点登录SSO（Single Sign-On）是身份管理中的一部分。SSO的一种较为通俗的定义是：SSO是指访问同一服务器不同应用中的受保护资源的同一用户，只需要登录一次，即通过一个应用中的安全验证后，再访问其他应用中的受保护资源时，不再需要重新登录验证。 目前的企业应用环境中，往往有很多的应用系统，如办公自动化（OA）系统，财务管理系统，档案管理系统，信息查询系统等等。这些应用系统服务于企业的信息化建设，为企业带来了很好的效益。但是，用户在使用这些应用系统时，并不方便。用户每次使用系统，都必须输入用户名称和用户密码，进行身份验证；而且应用系统不同，用户账号就不同，用户必须同时牢记多套用户名称和用户密码。特别是对于应用系统数目较多，用户数目也很多的企业，这个问题尤为突出。问题的原因并不是系统开发出现失误，而是缺少整体规划，缺乏统一的用户登录平台，使用SSO技术可以解决以上这些问题。
系统的基本架构 我们假设一个系统System包含Service客户服务中心、Shop网上购物中心和Office网上办公中心三个独立的网站。Service管理客户的资料，登录和注销过程。不论客户访问System的任何一个页面，系统都会转到登录界面，在用户登录后，系统会自动转会到客户上次请求的页面。并且用户此后可以在System中无缝切换。不需要再次进行登录。即在System中实现单点登录SSO（Single Sign-On）。 我们知道，用户的即时状态通常是使用Application、Session、Cookie和存储的。而这些都是不能在程序中跨站点访问的。我们必需通过站点间相互通讯来确认用户的即时状态。 简单的实现 如图所示，该图描述了用户访问System的流程。
第三部分 实现单点登录（Single Sign On）
“等了好久终于等到今天，写了好久终于就快完结，但是网友的反应却让我有一些的伤心。盼了好久终于盼到今天，忍了好久终于把此文撰写，那些受冷落的无奈早就无所谓，累也不说累”（歌词《今天》新演绎）。看着人家的 Blog 文章的评论是一条接一条，再瞧瞧自己：“无人问津呐，真…无…奈……唉，没人理我，还是回家吧。”“哎，还没开始写，怎么就走了？回去干什么呢？”回去写作业去啊，上回交待的课外作业你做了没？（注：http://blog.csdn.net/cityhunter172/archive/2005/11/13/528463.aspx 在第二部分第六节布置的课外作业：此项目有两部门使用，其中每个部门分别都有些特定的页面仅供本部门用户浏览使用，请问该如何使用 Web.config 达到效果？）
不知有多少人做了作业，其实答案并不难。只需要在验证用户名与密码后，取得该用户的部门名称或部门代码，把它作为判断的依据就行了。最好不要用部门的数字ID，那样不利于以后的维护。
有一个秘密，一般人我不告诉他。Web.config 中的
好了，接下来就要揭开“比根目录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 中的
b、 其中
<%@ 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 中，修改
1、 validationKey 为用于验证加密数据的密钥。最小长度为 40 个字符（20 字节），最大长度为 128 个字符（64 字节）。
2、 decryptionKey 为用于加密数据的密钥。长度只有 16 个字符（8 字节）与 48 个字符（24 字节）两种。
3、 validation 为用数据验证使用的加密类型。拥有“SHA1”“MD5”“3DES”三种方法
4、 大伙参照上述
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("
}
///
/// 生成加密型强随机 Key 值
///
/// Key 的有效长度：
/// decryptionKey 的有效值为 8 或 24 ；
/// validationKay 的有效值为 20 至 64
///
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 { 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 的关系，我们可以把 1、 权限管理系统项目的 Web.config 用于 Form 认证的设置 2、 IT 内部管理网项目的 Web.config 用于 Form 认证的设置 大家可能会迫不急待的去试一把，偶赞成这样的做法，因为事实是检验真理的唯一办法。你不去试着自己动手，光看我在这说是很难提高的。先别急，我已经知道你想说什么，听听我慢慢向你解释： a) 两个项目Web.cinfig的 b) 两个项目的 Cookie 名称必须相同，也就是 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:[email protected]”的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:[email protected]”，我们看到以下内容，如下图： 上图中，“■”是换行符，你若是要打破什么锅来问我到底是怎么知道的话。我倒是会很乐意的告诉你：这就是经验！偶从学习 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"] ="[email protected]"; // 设置 ckValue1 中的 E_Mail 值 ck["PersonalWeb"] ="172.meibu.com"; Response.Cookies.Add(ck); // 添加此 Cookie 6、 取回已发放 Cookie 的值 Response.Write(Request.Cookies["ckValue0"]["Author"]+" Response.Write(Request.Cookies["ckValue1"]["E_Mail"]+" 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 中 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 中 System.Web.HttpCookie ck = new HttpCookie(System.Web.Security.FormsAuthentication.FormsCookieName,str); // 指定 Cookie 为 Web.config 中 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 发短消息给我），昵称为 寒羽枫，欢迎大家批评指正。 前三篇在 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 页面上插入以下脚本： 注意事项 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 target ="_blank" href="MyTransfer.aspx?goto=http://127.0.0.1/FormTest/Public/AddCookie_E.aspx" > 快乐的天堂 < a target ="_blank" href="MyTransfer.aspx?goto=http://My_Computer_Name/FormTest/Public/AddCookie_F.aspx" > 大大的火坑 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. ，代码偶就不写，大家自个完成吧。 由于某些原因，在我们的应用中会遇到一个用户只能在一个地方登录的情况，也就是我们通常所说的单点登录。在ASP.NET中实现单点登录其实很简单，下面就把主要的方法和全部代码进行分析。 实现思路 利用Cache的功能，我们把用户的登录信息保存在Cache中，并设置过期时间为Session失效的时间，因此，一旦Session失效，我们的Cache也过期；而Cache对所有的用户都可以访问，因此，用它保存用户信息比数据库来得方便。 查看示例 SingleLogin.aspx代码 SingleLogin.aspx.cs代码
");//用不着说明了吧
"); ASP.NET单点登录简单实现
嗨！欢迎您访问【孟宪会之精彩世界】"； Msg.Text += "，祝您浏览愉快！：）
"; } else { // 在 Cache 中发现该用户的记录，表名已经登录过，禁止再次登录 Msg.Text="抱歉，您好像已经登录了呀：－（
"; return; } } } }
ASP.NET单点登录复杂实现
代码分析
从上面的流程中我们可以看出，系统中Shop和Office的代码是完全类似的。只要Shop可以实现，Office也可以同样的克隆。所以我们的重点分析的对象是Shop和Service的代码。
1、Shop的Web.config和Project.cs
在Shop的Web.config里，我们配置了Service站点和Shop站点，以方便我们在部署时方便修改。
＜appsettings＞＜add key="Service" value="http://localhost:8001" /＞＜add key="WebSite" value="http://localhost:8002" /＞＜/appsettings＞
在Project类里进行引用。
using System; using System.Configuration; namespace Amethysture.SSO.Shop { public class Project { public static string Service = ConfigurationSettings.AppSettings["Service"]; public static string WebSite = ConfigurationSettings.AppSettings["WebSite"]; } }
2、Shop的Global.cs
Shop的Global.cs定义了四个Session变量，UserID用来标识用户身份。Pass标识用户即时状态，Security用于保存往来Service和Shop的通讯不是被仿冒的。Url保存了上次请求的页面，以保证在用户登录后能转到用户请求的页面。
protected void Session_Start(Object sender, EventArgs e) { this.Session.Add("UserID", 0); this.Session.Add("Pass", false); this.Session.Add("Security", ""); this.Session.Add("Url", ""); }
3、Shop的Any.cs
Shop的Any.cs并没有包含代码，因为Any类从Page继承而来，为了代码分析方便，我们将代码集中到Page.cs中。
using System; using System.Web; namespace Amethysture.SSO.Shop { public class Any : Amethysture.SSO.Shop.Page { } }
4、Shop的Page.cs
Page类有两个方法，CustomerValidate和Initialize。CustomerValidate用户检查用户的即时状态，而Initialize是页面登录后发送给用户的信息。我们的重点是CustomerValidate。
CustomerValidate是一个非常简单的流程，用条件语句检查Pass的状态，如果Pass为否，则表示用户没有登录，页面跳转到Service的Validate页面中。我们要分析的是其中保存的Url和递交的WebSite和Security几个参数。Url的作用在前面已经讲清楚了，只是为了保证用户登录后能回到原来的页面。而WebSite是为了保证该站点是被Service所接受的，并且保证Service知道是哪个站点请求了用户即时状态。因为这个例子是个简单的例子，在后面的Validate里没有验证WebSite是否是接受的请求站点，但是在实际应用中应该验证这一点，因为Shop和Service等同于服务器和客户端，服务器出于安全考虑必须要检查客户端是否是被允许的。Security是非常重要的一点。Shop对Service发送的是请求，不需要保证该请求没有被篡改，但是在Service应答Shop请求时就必须要保证应答的数据没有被篡改了。Security正是为了保证数据安全而设计的。
在代码中，Security是通过Hash一个随机产生的数字生成的。具有不确定性。和保密性。我们可以看到，Security同时保存在Session中和发送给Service。我们把这个Security当作明文。在后面我们可以看到，Security在Service经过再一次Hash后作为密文发送回Shop。如果我们将Session保存的Security经过同样的Hash方法处理后等到的字符串如果和Service返回的密文相同，我们就能够在一定程度上保证Service应答的数据是没有经过修改的。
using System; using System.Web; using System.Security.Cryptography; using System.Text; namespace Amethysture.SSO.Shop { public class Page : System.Web.UI.Page { private void CustomerValidate() { bool Pass = (bool) this.Session["Pass"]; if (!Pass) { string Security = ""; Random Seed = new Random(); Security = Seed.Next(1, int.MaxValue).ToString(); byte[] Value; UnicodeEncoding Code = new UnicodeEncoding(); byte[] Message = Code.GetBytes(Security); SHA512Managed Arithmetic = new SHA512Managed(); Value = Arithmetic.ComputeHash(Message); Security = ""; foreach(byte o in Value) { Security += (int) o + "O"; } this.Session["Security"] = Security; this.Session["Url"] = this.Request.RawUrl; this.Response.Redirect(Project.Service + "/Validate.aspx?WebSite=" + Project.WebSite + "&Security=" + Security); } } protected virtual void Initialize() { this.Response.Write("＜html＞"); this.Response.Write("＜head＞"); this.Response.Write("＜title＞Amethysture SSO Project＜/title＞"); this.Response.Write("＜link rel=stylesheet type=\"text/css\" href=\"" + project.website + "/Default.css\"＞"); this.Response.Write("＜/head＞"); this.Response.Write("＜body＞"); this.Response.Write("＜iframe width=\"0\" height=\"0\" src=\"" + project.service + "/Customer.aspx\"＞＜/iframe＞"); this.Response.Write("＜div align=\"center\"＞"); this.Response.Write("Amethysture SSO Shop Any Page"); this.Response.Write("＜/div＞"); this.Response.Write("＜/body＞"); this.Response.Write("＜/html＞"); } protected override void OnInit(EventArgs e) { base.OnInit(e); this.CustomerValidate(); this.Initialize(); this.Response.End(); } } }
5、Service的Global.cs
现在我们页面转到了Service的Validate页面，我们转过来看Service的代码。在Global中我们同样定义了四个Session变量，都和Shop的Session用处类似。WebSite是保存请求用户即时状态的站点信息。以便能在登录后返回正确的请求站点。
6、Service的Validate.cs 首先，将Shop传递过来的参数保存到Session中。如果用户没有登录，则转到Customer页面进行登录。如果用户已经登录了。则将用户即时状态传回给Shop站点。如上所述，这里将Security重新Hash了一次传回给Shop，以保证数据不被纂改。
protected void Session_Start(Object sender, EventArgs e) { this.Session.Add("UserID", 0); this.Session.Add("Pass", false); this.Session.Add("WebSite", ""); this.Session.Add("Security", ""); }
7、Service的Customer.cs和Login.cs Customer主要的是一个用于登录的表单，这里就不贴出代码了。这里分析一下Login的一段代码，这段代码是当登录是直接在Service完成的（WebSite为空值），则页面不会转到Shop或Office站点。所以应该暂停在Service站点。系统如果比较完美，这里应该显示一组字系统的转向链接。下面我们看到，当Pass为真时，页面转回到Validate页面，通过上面的分析，我们知道，页面会转向Shop的Synchronous页面，进行用户状态的同步。
private void CustomerValidate() { bool Pass = (bool) this.Session["Pass"]; if ((this.Request.QueryString["WebSite"] != null) && (this.Request.QueryString["WebSite"] != "")) { this.Session["WebSite"] = this.Request.QueryString["WebSite"]; } if ((this.Request.QueryString["Security"] != null) && (this.Request.QueryString["Security"] != "")) { this.Session["Security"] = this.Request.QueryString["Security"]; } if (Pass) { string UserID = this.Session["UserID"].ToString(); string WebSite = this.Session["WebSite"].ToString(); string Security = this.Session["Security"].ToString(); byte[] Value; UnicodeEncoding Code = new UnicodeEncoding(); byte[] Message = Code.GetBytes(Security); SHA512Managed Arithmetic = new SHA512Managed(); Value = Arithmetic.ComputeHash(Message); Security = ""; foreach(byte o in Value) { Security += (int) o + "O"; } this.Response.Redirect(WebSite + "/Synchronous.aspx?UserID=" + UserID + "&Pass=True&Security=" + Security); } else { this.Response.Redirect("Customer.aspx"); } }
8、Shop的Synchronous.cs 好了，我们在Service中完成了登录，并把用户状态传递回Shop站点。我们接着看用户状态是怎么同步的。首先，如果Session里的Security是空字符串，则表示Shop站点没有向Service发送过请求，而Service向Shop发回了请求，这显然是错误的。这次访问是由客户端伪造进行的访问，于是访问被拒绝了。同样Security和InSecurity不相同，则表示请求和应答是不匹配的。可能应答被纂改过了，所以应答同样被拒绝了。当检验Security通过后，我们保证Serive完成了应答，并且返回了确切的参数，下面就是读出参数同步Shop站点和Service站点的用户即时状态。
if (Pass) { if ((this.Session["WebSite"].ToString() != "") && (this.Session["Security"].ToString() != "")) { this.Response.Redirect("Validate.aspx"); } else { this.Response.Write(""); this.Response.Write(""); this.Response.Write(""); this.Response.Write(""); this.Response.Write(""); this.Response.Write(""); this.Response.Write(""); this.Response.Write("Pass"); this.Response.Write(""); this.Response.Write(""); this.Response.Write(""); } } else { this.Response.Redirect("Customer.aspx"); }
9、Shop的Page.cs 我们知道，页面在一段时间不刷新后，Session会超时失效，在我们一直访问Shop的时候怎么才能保证Service的Session不会失效呢？很简单，我们返回来看Shop的Page.cs。通过在所有Shop的页面内都用＜iframe＞嵌套Service的某个页面，就能保证Service能和Shop的页面同时刷新。需要注意的一点是Service的Session必须保证不小于所有Shop和Office的Session超时时间。这个在Web.config里可以进行配置。
string InUserID = this.Request.QueryString["UserID"]; string InPass = this.Request.QueryString["Pass"]; string InSecurity = this.Request.QueryString["Security"]; string Security = this.Session["Security"].ToString(); if (Security != "") { byte[] Value; UnicodeEncoding Code = new UnicodeEncoding(); byte[] Message = Code.GetBytes(Security); SHA512Managed Arithmetic = new SHA512Managed(); Value = Arithmetic.ComputeHash(Message); Security = ""; foreach(byte o in Value) { Security += (int) o + "O"; } if (Security == InSecurity) { if (InPass == "True") { this.Session["UserID"] = int.Parse(InUserID); this.Session["Pass"] = true; this.Response.Redirect(this.Session["Url"].ToString()); } } else { this.Response.Write(""); this.Response.Write(""); this.Response.Write(""); this.Response.Write(""); this.Response.Write(""); this.Response.Write(""); this.Response.Write(""); this.Response.Write("数据错误"); this.Response.Write(""); this.Response.Write(""); this.Response.Write(""); } } else { this.Response.Write(""); this.Response.Write(""); this.Response.Write(""); this.Response.Write(""); this.Response.Write(""); this.Response.Write(""); this.Response.Write(""); this.Response.Write("访问错误"); this.Response.Write(""); this.Response.Write(""); this.Response.Write(""); }
总结 一次完整的登录完成了。我们接着假设一下现在要跳到Office的Any页面，系统会进行怎样的操作呢？Any（用户没有登录）-＞Validate（用户已经登录）-＞Synchronous（同步）-＞Any。也就是说这次，用户没有进行登录的过程。我们通过一次登录，使得Service的用户状态为登录，并且不管有多少个网站应用，只要这些网站都保证符合Shop的特性，这些网站就都能保持Service的用户状态，同时能通过Service获得用户的状态。也就是说我们实现了SSO。
this.Response.Write("＜iframe width=\"0\" height=\"0\" src=\"" + project.service + "/Customer.aspx\"＞＜/iframe＞");