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

ASP.NET
.Net中使用com组件后发生System.ArithmeticException异常的解决办法
SQL Server.net 和 OLE DB.net连接数据库的比较
后台更新DataTable行内容的方法
敏捷软件开发(原则,模式与实践)笔记1
确保文本框输入值为数值的代码
XML和数据库之间相互的映射
让你的.NET程序兼容不同版本的Dll文件。
.NET 的数据访问应用程序块(Data Access Application Block)
用控件仅一条指令实现界面换肤和多语言版本(YFSkins)
Microsoft User Interface Process Application Block 研究(3)
分享:处理Excel方法小结
基于ASP.NET实现全球化
.net 里面 protected private 的变量也可以访问(新发现)。
关于C#中{0}和{1}的问题初次在此发贴,问题对你易对我难,求救了
使用C#代码实现增加用户帐号
全世界都在关注-微软重大产品发布
教你做Rational Rose(UML Design)
OLE DB取得数据库的架构信息
VB 从零开始编外挂(三)
XPath序列之四

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


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