xml地图|网站地图|网站标签 [设为首页] [加入收藏]

20.3 IIS 7.0和表单验证(1)

20.3  IIS 7.0和表单验证1)

20.3  IIS 7.0和表单验证2)

你可能会奇怪我们为什么单独讨论结合IIS 7.0的表单验证。首先,第18章学过,IIS 7.0的新的管理控制台允许你直接在管理控制台内配置绝大多数的ASP.NET选项。其次,IIS 7.0提供了一个新的ASP.NET整合模式--对ASP.NET HTTP处理管道和IIS HTTP处理管道进行整合。它能够通过你现有的ASP.NET知识发挥新的能力。例如,其中一个能力是能够为IIS 7.0里配置的其他Web应用程序使用ASP.NET表单验证,而这些应用程序不一定是通过ASP.NET构建的。

不过,仅仅把ASP内容和基于ASP.NET的登录页面放到一起并配置表单验证还不足够。试图访问传统ASP页面时,表单验证还不能工作。根据验证和授权规则的不同,你可能得到一个"未授权"响应或不经登录提醒就直接访问到了传统ASP页面将在第23章学习授权规则及其行为的更多内容)。

了解ASP.NET底层架构

此外,IIS 7.0把Web服务器中对Web应用程序进行的大部分配置保持到web.config文件里。也就是说,Web应用程序的很多选项可以通过IIS 7.0管理控制台或直接修改web.config文件进行配置。由于ASP.NET配置特性和IIS 7.0的紧密整合,任何针对web.config文件的直接修改都会立即反映到管理控制台上,反之亦然。

产生这种行为的原因是默认情况下托管的HTTP模块如表单验证模块)被配置为仅为针对基于ASP.NET的代码的请求执行。因此,为了让表单验证能够工作,必须在选中Web应用程序后,在IIS 7.0管理控制台中选择HTTP模块配置特性来修改这一行为。然后,在模块列表里打开FormsAuthentication模块配置的细节,如图20-7和图20-8所示。

 

让我们首先来看看是否可能在IIS 7.0管理控制台里配置表单验证。从图20-4看到,可以通过IIS 7.0管理控制台的验证配置特性配置表单验证。

打开HTTP模块配置特性后,需要找到FormsAuthentication项并双击它,或者单击管理控制台右边任务栏里的"编辑"链接。在打开的设置对话框里,需要禁用"Invoke Only for Requests to ASP.NET Applications or Managed Handlers"选项,如图20-8所示。

进入底层

以这种方式启用表单验证后,还必须配置希望的验证规则。其中最重要的一点是通过IIS 7.0管理控制台的验证配置特性为所有匿名用户添加一个"拒绝"规则,如图20-5所示。

完成这项配置后,再访问Web应用程序目录里的传统ASP页面时,请求就会使用ASP.NET表单验证来进行验证。Web应用程序的web.config的内容大致如下:

这篇文章以非常底层的视角讲述了Web请求(request)在ASP.NET框架中是如何流转的,从Web服务器,通过ISAPI直到请求处理器(handler)和你的代码.看看在幕后都发生了些什么,不要再把ASP.NET看成一个黑盒了.

 
点击查看大图)图20-4  在IIS 7.0管理控制台里配置表单验证
 

 

这两个配置都会影响web.config文件,而Web服务器从web.config文件获取这些信息并据此产生适当的行为,可以从如下的代码段看到这一点:

 
点击查看大图)图20-7  在Web应用程序里选择HTTP模块配置特性

ASP.NET是一个非常强大的构建Web应用的平台,它提供了极大的灵活性和能力以致于可以用它来构建所有类型的Web应用.绝大多数的人只熟悉高层的框架如WebForms和WebServices-这些都在ASP.NET层次结构在最高层.在这篇文章中我将会讨论ASP.NET的底层机制并解释请求(request)是怎么从Web服务器传送到ASP.NET运行时然后如何通过ASP.NET管道来处理请求.

 
 
点击查看大图)图20-8  FormsAuthentication模块的配置细节

 

你可能注意到IIS正如预期的那样在<system.web>节配置表单验证。不过默认情况下并且还没有手工添加过)找不到任何验证规则。如在第18章所言,并非所有配置项都是默认直接保存到web.config配置文件的。URL验证就是这样的配置选项之一。我们将在第23章学习关于URL验证的一般细节以及IIS 7.0特定的内容。

对FormsAuthentication模块的配置非常重要。按图20-8配置的复选标记在配置里显示为pre- Condition = "",而它的默认值是managedHandler。

对我而言了解平台的内幕通常会带来满足感和舒适感,深入了解也能帮助我写出更好的应用.知道可以使用哪些工具以及他们是怎样作为整个复杂框架的一部分来互相配合的可以更容易地找出最好的解决方案,更重要的是可以在出现问题时更好的解决它们.这篇文章的目标是从系统级别了解ASP.NET并帮助理解请求(request)是如何在ASP.NET的处理管道中流转的.同样,我们会了解核心引擎和Web请求如何在那里结束.这些信息大部分并不是你在日常工作时必须了解的,但是它对于理解ASP.NET架构如何把请求路由到你的代码(通常是非常高层的)中是非常有益的.

无论哪种情况下,统一的管理控制台非常整洁,你不必通过不同的工具配置IIS安全和ASP.NET安全,很多配置都默认直接保存到web.config文件。如在第18章和第19章已知以及第23章将要知道的,可以对IIS进行配置,这样几乎所有的选项都直接保存到web.config里。然而,之前还提过,当把IIS 7.0运行于ASP.NET整合模式时,可以为我们提供更多的可能第18章和第19章有更多的细节)。

整体而言,可以通过这样的方式对基于IIS 7.0 Web服务器配置的Web应用程序最大化应用ASP.NET特性的能力,如表单验证甚至第21章介绍的成员资格API。和前面版本的IIS相比,这是一个巨大的优势,同时它使得很多事情变得更加简单。

 

当IIS 7.0运行于整合模式时它是默认值),IIS使用一个HTTP处理管道同时处理基于ASP.NET的HTTP模块以及IIS 7.0的原生HTTP模块。因为表单验证被实现为一个ASP.NET HTTP模块,所以当运行于整合模式时你可以把它用于任意的Web应用程序或IIS 7.0配置的虚拟目录。也就是说,甚至可以把表单验证用于其他类型的应用程序,如静态HTML站点、传统的ASP应用程序,或者甚至PHP应用程序。你所要做的只是把应用程序配置为一个虚拟目录,然后通过IIS 7.0管理控制台配置表单验证。这自动为应用程序增加一个web.config配置。这里有一个细节需要留心,为此这一节我们要浏览一下如何为一个非ASP.NET应用程序配置表单验证。假设有如下的传统ASP应用程序运行于Web服务器上:

回书目   上一节   下一节

不管怎么样,ASP.NET从更低的层次上提供了更多的灵活性.HTTP运行时和请求管道在构建WebForms和WebServices上提供了同样的能力-它们事实上都是建立在.NET托管代码上的.而且所有这些同样的功能对你也是可用的,你可用决定你是否需要建立一个比WebForms稍低一点层次的定制的平台.

 

IIS 7.0和表单验证2) 不过,仅仅把ASP内容和基于ASP.NET的登录页面放到一起并配置表单验证还不足够。试图访问传统ASP页面时,表单验证...

 

现在在IIS里把保存这个传统的ASP页面文件例如,TestClassic.asp)的文件夹共享为一个虚拟目录或Web应用程序。然后,可以像之前介绍的那样配置表单验证和授权设置。因为IIS 7.0通过整合ASP.NET发布的HTTP表单验证模块原生支持表单验证,因此它能够像ASP.NET应用程序自身那样工作。你所要做的只是确保有一个必需的登录页面,而它自身是一个ASP.NET页面。你还要让该ASP.NET页面所需的部分可以从Web应用程序里获得或者如果使用跨应用程序表单验证cookie,就从其他虚拟目录获得)。图20-6显示虚拟目录里的传统ASP页面以及ASP.NET登录页面。表单验证直接按前面介绍的通过IIS 7.0管理控制台配置。

WebForms显然是最简单的构建绝大多数Web接口的方法,不过如果你是在建立自定义的内容处理器(handler),或者有在处理输入输出内容上有特殊的要求,或者你需要为另外的应用建立一个定制的应用程序服务接口,使用这些更低级的处理器(handler)或者模块(module)能提供更好的性能并能对实际请求处理提供更多的控制.在WebForms和WebServices这些高层实现提供它们那些能力的同时,它们也对请求增加了一些额外负担,这些都是在更底层可以避免的.

  
点击查看大图)图20-6  和传统ASP混合的ASP.NET内容

 

回书目   上一节   下一节

 

IIS 7.0和表单验证1) 你可能会奇怪我们为什么单独讨论结合IIS 7.0的表单验证。首先,第18章学过,IIS 7.0的新的管理控制台允许你直接在...

**ASP.NET是什么

**

让我们以一个简单的定义开始:什么是ASP.NET?我喜欢这样定义ASP.NET:

          

ASP.NET是一个复杂的使用托管代码来从头到尾处理Web请求的引擎.

**它并不只是WebForms和WebServies…    

**

ASP.NET是一个请求处理引擎.它接收一个发送过来的请求,把它传给内部的管道直到终点,作为一个开发人员的你可以在这里附加一些代码来处理请求.这个引擎是和HTTP/Web服务器完全分隔的.事实上,HTTP运行时是一个组件,使你可以摆脱IIS或者任何其他的服务器程序,将你自己的程序寄宿在内.例如,你可以将ASP.NET运行时寄宿在一个Windows form程序中(查看可以得到更加详细的信息)

 

运行时提供了一个复杂但同时非常优雅的在管道中路由请求的机制.其中有很多相关的对象,大多数都是可扩展的(通过继承或者事件接口),在几乎所有的处理流程上都是如此.所以这个框架具有高度可扩展性.通过这个机制,挂接到非常底层的接口(比如缓存,认证和授权)都变得可能了.你甚至可以在预处理或者处理后过滤内容,也可以简单的将符合特殊标记的请求直接路由你的代码或者另一个URL上.存在着许多不同的方法来完成同一件事,但是所有这些方法都是可以简单直接地实现的,同时还提供了灵活性,可以得到最好的性能和开发的简单性.

 

整个ASP.NET引擎是完全建立在托管代码上的,所有的扩展功能也是通过托管代码扩展来提供的

 

整个ASP.NET引擎是完全建立在托管代码上的,所有的扩展功能也是通过托管代码扩展来提供的.这是对.NET框架具有构建复杂而且高效的框架的能力的最好的证明.ASP.NET最令人印象深刻的地方是深思熟虑的设计,使得框架非常的容易使用,又能提供挂接到请求处理的几乎所有部分的能力.

 

通过ASP.NET你可以从事从前属于ISAPI扩展和IIS过滤器领域的任务-有一些限制,但是比起ASP来说是好多了.ISAPI是一个底层的Win32风格的API,有着非常粗劣的接口而且难以用来开发复杂的程序.因为ISAPI非常底层,所以它非常的快,但是对于应用级的开发者来说是十分难以管理的.所以,ISAPI通常用来提供桥接的接口,来对其他应用或者平台进行转交.但是这并不意味者ISAPI将消亡.事实上,ASP.NET在微软的平台上就是通过ISAPI扩展来和IIS进行交互的,这个扩展寄宿着.NET运行时和ASP.NET运行时.ISAPI提供了核心的接口,ASP.NET使用非托管的ISAPI代码通过这个接口来从Web服务器获取请求,并发送响应回客户端.ISAPI提供的内容可以通过通用对象(例如HttpRequest和HttpResponse)来获取,这些对象通过一个定义良好并有很好访问性的接口来暴露非托管数据.

 

 

永利皇宫463com,从浏览器到ASP.NET

 

让我们从一个典型的ASP.NET Web请求的生命周期的起点开始.当用户输入一个URL,点击了一个超链接或者提交了一个HTML表单(form)(一个POST请求,相对于前两者在一般意义上都是GET请求).或者一个客户端程序可能调用了一个基于ASP.NET的WebService(同样由ASP.NET来处理).在Web服务器端,IIS5或6,获得这个请求.在最底层,ASP.NET和IIS通过ISAPI扩展进行交互.在ASP.NET环境中这个请求通常被路由到一个扩展名为.aspx的页面上,但是这个流程是怎么工作的完全依赖于处理特定扩展名的HTTP Handler是怎么实现的.在IIS中.aspx通过’应用程序扩展’(又称为脚本映射)被映射到ASP.NET的ISAPI扩展DLL-aspnet_isapi.dll.每一个请求都需要通过一个被注册到aspnet_isapi.dll的扩展名来触发ASP.NET(来处理这个请求).

 

依赖于扩展名ASP.NET将请求路由到一个合适的处理器(handler)上,这个处理器负责获取这个请求.例如,WebService的.asmx扩展名不会将请求路由到磁盘上的一个页面,而是一个由特殊属性(Attribute)标记为WebService的类上.许多其他处理器和ASP.NET一起被安装,当然你也可以自定义处理器.所有这些HttpHandler在IIS中被配置为指向ASP.NET ISAPI扩展,并在web.config(译著:ASP.NET中自带的handler是在machine.config中配置的,当然可以在web.config中覆盖配置)被配置来将请求路由到指定的HTTP Handler上.每个handler都是一个处理特殊扩展的.NET类,可以从一个简单的只包含几行代码的Hello World类,到非常复杂的handler如ASP.NET的页面或者WebService的handler.当前,只要了解ASP.NET的映射机制是使用扩展名来从ISAPI接收请求并将其路由到处理这个请求的handler上就可以了.

 

对在IIS中自定义Web请求处理来说,ISAPI是第一个也是最高效的入口

 

ISAPI连接

 

ISAPI是底层的非托管Win32 API.ISAPI定义的接口非常简单并且是为性能做了优化的.它们是非常底层的-处理指针和函数指针表来进行回调-但是它们提供了最底层和面向效率的接口,使开发者和工具提供商可以用它来挂接到IIS上.因为ISAPI非常底层所以它并不适合来开发应用级的代码,而且ISAPI倾向于主要被用于桥接接口,向上层工具提供应用服务器类型的功能.例如,ASP和ASP.NET都是建立在ISAPI上的,Cold Fusion,运行在IIS上的多数Perl,PHP以及JSP实现,很多第三方解决方案(如我的Wisual FoxPro的Web连接框架)都是如此.ISAPI是一个杰出的工具,可以为上层应用提供高效的管道接口,这样上层应用可以抽象出ISAPI提供的信息.在ASP和ASP.NET中,将ISAPI接口提供的信息抽象成了类型Request和Response这样的对象,通过它们来读取ISAPI请求中对应的信息.将ISAPI想像成管道.对ASP.NET来说,ISAPI dll是非常的”瘦”的,只是作为一个路由机制来将原始的请求转发到ASP.NET运行时.所有那些沉重的负担和处理,甚至请求线程的管理都发生在ASP.NET引擎内部和你的代码中.

 

作为协议,ISAPI同时支持ISAPI扩展和ISAPI过滤器(Filter).扩展是一个请求处理接口,提供了处理Web服务器的输入输出的逻辑-它本质上是一个处理(事物?)接口.ASP和ASP.NET都被实现为ISAPI扩展.ISAPI过滤器是挂接接口,提供了查看进入IIS的每一个请求的能力,并能修改请求的内容或者改变功能型的行为,例如认证等.顺便提一下,ASP.NET通过了两种概念映射了类似ISAPI的功能:Http Handler类似扩展,Http Module类似过滤器.我们将在后面详细讨论它们.

 

ISAPI是开始一个ASP.NET请求的最初的入口.ASP.NET映射了好几个扩展名到它的ISAPI扩展,此扩展位于.NET框架的目录下:

 

<.NET FrameworkDir>aspnet_isapi.dll

 

你可以在IIS服务管理界面上看到这些映射,如图1.查看网站根目录的属性中的主目录配置页,然后查看配置|映射. 

永利皇宫463com 1 

图1:IIS映射了多种扩展名如.ASPX到ASP.NET的ISAPI扩展.通过这个机制请求会在Web服务器这一层被路由到ASP.NET的处理管道.

 

由于.NET需要它们中的一部分,你不应该设置手动这些扩展名.使用aspnet_regiis.exe这个工具来确保所有的映射都被正确的设置了:

 

cd <.NetFrameworkDirectory>

aspnet_regiis – i

 

这个命令将为整个Web站点注册特定版本的ASP.NET运行时,包括脚本 (扩展名) 映射和客户端脚本库(包括进行控件验证的代码等).注意它注册的是<.NetFrameworkDirectory>中安装的特定版本的CLR(如1.1,2.0).aspnet_regiis的选项令您可以对不同的虚拟目录进行配置.每个版本的.NET框架都有自己不同版本的aspnet_regiis工具,你需要运行对应版本的aspnet_regiis来为web站点或者虚拟目录来配置指定版本的.NET框架.从ASP.NET2.0开始提供了ASP.NET配置页面,可以通过这个页面在IIS管理控制台来交互的配置.NET版本.

 

IIS6通配符应用程序映射

如果你有一个ASP.NET应用程序需要处理虚拟目录的(或者是整个Web站点,如果配置为根目录的话)每一个请求,IIS6引入了新的称为通配符应用程序映射的概念.一个映射到通配符的ISAPI扩展在每个请求到来时都会被触发,而不管扩增名是什么.这意味着每个页面都会通过这个扩展来处理.这是一个强大的功能,你可以用这个机制来创建虚拟Url和不使用文件名的unix风格的URL.然而,使用这个设置的时候要注意,因为它会把所有的东西都传给你的应用,包括静态htm文件,图片,样式表等等.

 

 

IIS 5 和6以不同的方式工作

 

当一个请求来到时,IIS检查脚本映射(扩展名映射)然后把请求路由到aspnet_isapi.dll.这个DLL的操作和请求如何进入ASP.NET运行时在IIS5和6中是不同的.图2显示了这个流程的一个粗略概览.

永利皇宫463com 2

 

 在IIS5中,aspnet_isapi.dll直接寄宿在inetinfo.exe进程中,如果你设置了Web站点或虚拟目录的隔离度为中或高,则会寄宿在IIS单独的(被隔离的)工作进程中.当第一个ASP.NET请求来到,DLL(aspnet_isapi.dll)会开始另一个新进程aspnet_wp.exe并将请求路由到这个进程中来进行处理.这个进程依次加载并寄宿.NET运行时.每个转发到ISAPI DLL的请求都会通过命名管道调用被路由到这个进程来.

  

图2-从较高层次来看请求从IIS到ASP.NET运行时,并通过请求处理管道的流程.IIS5和IIS6通过不同的方式与ASP.NET交互,但是一旦请求来到ASP.NET管道,整个处理流程就是一样的了.

 

不同于以前版本的服务器,IIS6为ASP.NET做了全面的优化

 

 

IIS6-应用程序池万岁

 

IIS6对处理模型做了意义重大的改变,IIS不再直接寄宿象ISAPI扩展这样的外部可执行代码.IIS总是创建一个独立的工作线程-一个应用程序池-所有的处理都发生在这个进程中,包括ISAPI dll的执行.应用程序池是IIS6的一个很大的改进,因为它允许对指定线程中将会执行什么代码进行非常细粒度的控制.应用程序池可以在每个虚拟路径上或者整个Web站点上进行配置,这样你可以将每个Web应用隔离到它们自己的进程中,这样每个应用都将和其他运行在同一台机器上的Web应用完全隔离.如果一个进程崩溃了,不会影响到其他进程(至少在Web处理的观点上来看是如此).

 

不止如此,应用程序池还是高度可配置的.你可以通过设置池的执行扮演级别(execution impersonation level )来配置它们的运行安全环境,这使你可以定制赋予一个Web应用的权限(同样,粒度非常的细).对于ASP.NET的一个大的改进是,应用程序池覆盖了在machine.config文件中大部分的ProcessModel节的设置.这一节的设置在IIS5中非常的难以管理,因为这些设置是全局的而且不能在应用程序的web.config文件中被覆盖.当运行IIS6是,ProcessModel相关的设置大部分都被忽略了,取而代之的是从应用程序池中读取.注意这里说的是大部分-有些设置,如线程池的大小还有IO线程的设置还是从machine.config中读取,因为它们在线程池的设置中没有对应项.

 

因为应用程序池是外部的可执行程序,这些可执行程序可以很容易的被监控和管理.IIS6提供了一系列的进行系统状况检查,重启和超时的选项,可以很方便的用来检查甚至在许多情况下可以修正程序的问题.最后IIS6的应用程序池并不像IIS5的隔离模式那样依赖于COM+,这样做一来可以提高性能,二来提高了稳定性(特别对某些内部需要调用COM组件的应用来说)

 

尽管IIS6的应用程序池是单独的EXE,但是它们对HTTP操作进行了高度的优化,它们直接和内核模式下的HTTP.SYS驱动程序进行通讯.收到的请求被直接路由给适当的应用程序池.InetInfo基本上只是一个管理程序和一个配置服务程序-大部分的交互实际上是直接在HTTP.SYS和应用程序池之间发生,所有这些使IIS6成为了比IIS5更加的稳定和高效的环境.特别对静态内容和ASP.NET程序来说这是千真万确的.

 

一个IIS6应用程序池对于ASP.NET有着天生的认识,ASP.NET可以在底层的API上和它进行交互,这允许直接访问HTTP缓存API,这样做可以将ASP.NET级别的缓存直接下发到Web服务器.

 

在IIS6中,ISAPI扩展在应用程序池的工作进程中运行. .NET运行时也在同一个进程中运行,所以ISAPI扩展和.NET运行时的通讯是发生在进程内的,这样做相比IIS5使用的命名管道有着天生的性能优势.虽然IIS的寄宿模型有着非常大的区别,进入托管代码的接口却异常的相似-只有路由消息的过程有一点区别.

 

ISAPIRuntime.ProcessRequest()函数是进入ASP.NET的第一站

 

进入.NET运行时

 

进入.NET运行时的真正的入口发生在一些没有被文档记载的类和接口中(译著:当然,你可以用Reflector来查看J).除了微软,很少人知道这些接口,微软的家伙们也并不热衷于谈论这些细节,他们认为这些实现细节对于使用ASP.NET开发应用的开发人员并没有什么用处.

工作进程(IIS5中是ASPNET_WP.EXE,IIS6中是W3WP.EXE)寄宿.NET运行时和ISAPI DLL,它(工作进程)通过调用COM对象的一个小的非托管接口最终将调用发送到ISAPIRuntime类的一个实例上(译注:原文为an instance subclass of the ISAPIRuntime class,但是ISAPIRuntime类是一个sealed类,疑为作者笔误,或者这里的subclass并不是子类的意思).进入运行时的第一个入口就是这个没有被文档记载的类,这个类实现了IISAPIRuntime接口(对于调用者说明来说,这个接口是一个COM接口)这个基于Iunknown的底层COM接口是从ISAPI扩展到ASP.NET的一个预定的接口.图3展示了IISAPIRuntime接口和它的调用签名.(使用了Lutz Roeder出色的.NET Reflector 

工具http://www.aisto.com/roeder/dotnet/).

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

本文由永利澳门平台发布于计算机资讯,转载请注明出处:20.3 IIS 7.0和表单验证(1)

您可能还会对下面的文章感兴趣: