当前位置: 首页 > 图文教程 > 网络编程 > ASP.NET > asp.net 2.0 下的表单验证Cookieless属性

ASP.NET
使用C# 开发掩码输入文本框
点击DataGrid的列标头在DataGrid最后一行显示该列的和
ASP.NET之Web打印-终极解决篇
SQL Server 2000 Reporting Services: 怎样根据用户的语言偏好显示本地化的信息
利用底层键盘钩子拦载任意按键(回调版)
如何禁止调整自定义控件的尺寸?
用VB6.0编写磁盘格式化程序
Aspx中导Excel
ASP.NET组件设计Step by Step(3)
下面真正开始讲事件的内容
如何有效的使用C#读取文件
如何在C#中加载自己编写的动态链接库(DLL)
Managed DirectX 相关(DirectX.Capture Class Library && DirectShow.NET)
XQuery Reference-from w3schools.com
[译]Visual Basic 2005在语言上的增强(十三)显式的数组范围及小结
lucene的首次应用
[VBA]在后台删除工作表后出现的怪问题
VB.NET 数据库查询 [SQL字符串的生成]
JavaScript调用服务器事件
在Window2003上执行System.Diagnostics.Process.GetProcessesByName等方法失败的原因

ASP.NET 中的 asp.net 2.0 下的表单验证Cookieless属性


出处:互联网   整理: 软晨网(RuanChen.com)   发布: 2009-11-03   浏览: 145 ::
收藏到网摘: n/a

 

刚刚在洗衣服的时候突然想到今天在做WAP程序的表单验证的时候遇到一个问题,在不支持Cookies的移动设备模拟器中无法正常进行表单验证,联想到昨天使用web.config设置cookieless属性时会在访问时会出现"Cannot use a leading .. to exit above the top directory"的异常,自然而然的我就想到了前一段时间困扰我很久的一个站点异常无法使用前导 .. 在顶级目录上退出(Cannot use a leading .. to exit above the top directory)。综合一下,终于理解了为什么会出现这样的异常,也理解了为什么在asp.net 2.0 中,将原来cookieless属性只能设置true|false,改成了可以设置枚举HttpCookieMode的值,分别为:AutoDetect,UseCookies,UseDeviceProfile,UseUri 。

如果对表单验证很有经验的朋友可能会很清楚,可以有两种方式来保存当前的SessionID和用户的验证票信息,分别是使用Cookie和在URL地址加上一串编码过的字符串来标识当前的SessionID和用户的验证票信息。第一种方式非常普遍,对于使用URI来标识当前SessionID和验证票,我相信如果不是特殊需要的话,相信很多人都会跟我一样还无法很好理解。我做了两个简单的页面,来模拟用户的验证过程。当我在web.config中设置cookieless="AutoDetect"时,就跟我们平常一样,登录的URL是:

http://localhost:1115/FormsAuthentication/Security/Default.aspx

而当我设置cookieless="UseUri"时,这时URL地址就变成了:

http://localhost:1115/FormsAuthentication/(F(V0-gEZNEzXUqevbOqKwNoBcMf6vBWnyNbdpa2UhZzrfOUkGPvyB91-9nFlnBDmCAgdpz4gJ6kq-QOVjbNsvKig2))/Security/Default.aspx

在站点目录多了一级目录,这里的值就是当前会用户的验证票信息和SessionID信息。在某些场合,这样做是非常有意义的(或者是必须的),因为在不支持cookie环境下,你要去标识一个是否属于同一个会话,当前用户是否已验证过,等等与会话相关信息的时候就会变得异常的困难。

了解了这两个保存会话信息的方式后,我们再来讨论一下,asp.net team为什么把原来只能设置true | false的属性改成可以设置不同的枚举值.首先我们来看看这4个值的含意(在Windows Live Writer 不能画表格 :< ):

AutoDetect:自动检测客户端实际是否支持cookie再来决定使用两种方式中的哪一种(最佳适应)。

UseCookies:不管客户端是否支持cookie,反正都使用cookie来标识(第一种方式)。

UseDeviceProfile:根据设备文件来判断是否支持cookie,进而决定使用哪种方式。相信很多人都对这个概念很模糊,由于最近在研究WAP,所以对它有一些简单的认识。在<%windir%>Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers目录下有很多的.browser文件,这些文件就是用来标识对应的设备(浏览器)的浏览能力(描述不是很清楚,就是一些技术参数,是否支持cookie and so on),在asp.net中,会根据这些.browser文件,动态生成从HttpBrowserCapabilities继承下来的设备参数类型,标识对应的设备的一些参数值,编程中可以通过Request.Browser得到这个设备参数对象,并使用。

UseUri :与UseCookies类似的,不管客户端是否支持cookie,反正都使用第二种方式。

特别说明:为什么特别强调“实际”,和详细描述UseDeviceProfile呢?主要是因为,我发现由于可能是设备文件中标识的参数与对应的设备的实际并不完全匹配,(比如,有可能设备文件中标识这种设备支持cookie,但实际的设备却不支持)。所以如果要根据设备的实际来选择是否使用cookie,那就要使用AutoDetect值了。设备文件只能是做为参考,当然如果你对设备文件有充分控制条件的话那就另当别论了。而且还有一点要特别注意,AutoDetect并不是默认值,UseDeviceProfile才是。

回到正题,为什么要改cookieless属性的可选值呢?毫无疑问,是为了增加程序的可操控性。原来的值有点太过单一化了,二选一,没有商量的余地。现在我们可以根据各种不同的情况来让程序动态或程序员手动选择。结合这一段时间的WAP开发经验,我想这样做的一个目的就是为了能更好的兼容移动设备,兼容WAP的应用。目前还有很多的设备还并不支持cookie。

有了上面的介绍后,我还想来解开为什么会出现“Cannot use a leading .. to exit above the top directory”异常的迷团。前几天也有收到一个朋友的来信,也是在使用CommunityServer 2.0遇到这个问题,(相信目前遇到最多的就是asp.net 2.0版的CommunityServer了)。目前使用了Url Rewrite,所以我们程序的很多URL都是假的,所以如果在页面中使用了相对路径(~/)的话,那我们就有可能遇