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

ASP.NET
FreeTextBox(版本3.1.6)在ASP.Net 2.0中使用方法
.NET 常用功能和代码小结
在 .NET Framework 2.0 中未处理的异常导致基于 ASP.NET 的应用程序意外退出
asp.net IList查询数据后格式化数据再绑定控件
asp.net sql存储过程
asp.net 简单实现禁用或启用页面中的某一类型的控件
asp.net(c#)获取内容第一张图片地址的函数
The remote procedure call failed and did not execute的解决办法
ASP.NET 在线文件管理
asp.net 读取并修改config文件实现代码
ASP.NET Cookie 操作实现
asp.net Silverlight中的模式窗体
Silverlight中动态获取Web Service地址
asp.net Silverlight应用程序中获取载体aspx页面参数
asp.net 水晶报表隔行换色实现方法
asp.net 获取Gridview隐藏列的值
手动把asp.net的类生成dll文件的方法
asp.net 使用ObjectDataSource控件在ASP.NET中实现Ajax真分页
动态指定任意类型的ObjectDataSource对象的查询参数
asp.net Md5的用法小结

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


出处:互联网   整理: 软晨网(RuanChen.com)   发布: 2009-11-03   浏览: 88 ::
收藏到网摘: 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都是假的,所以如果在页面中使用了相对路径(~/)的话,那我们就有可能遇