在ASP.NET中实现Url Rewriting

　　实现网址重写的一个较为安全的场合就是把它放在在BeginRequest事件中执行，这意味着如果要执行网址重写的话，在众多内嵌HttpModule运行的时候他已经完成了。这种途径的最终用途淋漓尽致地体现在表单验证上。当用户访问受限资源的时候， 如果之前使用了表单验证，他会自动被重定向到指定的登录页面，在成功登录之后，用户被重定向回先前试图访问的受限制页面。

　　如果把网址重写放在BeginRequest事件或者AuthenticateRequest事件中，在登录页面上执行提交后，该页面会将用户重定向到网址重写指定的页面。假定当用户在浏览器上敲入/people/ScottMitchell.aspx地址，该地址是要被重定向到/info/employee.aspx?EmpID=1001的， 如果该Web应用程序设定使用表单验证，当用户开始访问/people/ScottMitchell.aspx的时候，该网址将重写指向/info/employee.aspx?EmpID=1001，接着ForumAuthenticationModule启动，如果需要的话将用户重定向到登录页面，用户登录后重定向到的页面将是/info/employee.aspx?EmpID=1001，这也是自从FormAuthenticationModule启动运行时所发出请求的页面。
同上类似，当把网址重写放在BeginRequest事件或者AuthenticateRequest事件中运行的时候，UrlAuthenticationModule也发现了网址重写指向的网址，这意味着如果在该应用程序的web.config文件中＜location＞节为特定的网址配置特定的授权地址的话，你得引用重写所指向的网址。

　　为了解决这个微妙的问题，一个可能就是把网址重写放在AuthorizeRequest事件中运行，但是在使用这种方法解决URL授权和表单授权的异常时又引入了一个新的缺陷：文件授权会失效。当使用Windows验证的时候，FileAuthorizationModule检查并验证已通过验证的用户是否拥有足够的权限访问特定的ASP.NET页面。

　　假定有一群用户并没有Windows级别的访问权限访问C:\inetpub\wwwroot\info\employee.aspx，当这些用户试图访问/info/employee.aspx?EmpID=1001的时候，他们会得到未授权的错误，如果我们把网址重写放到AuthenticateRequest事件中运行，当FileAuthorizationModule验证该安全性设置的时候，他仍任人为被请求的文件是/people/ScottMitchell.aspx，而这时该网址已经被重写了，因此FileAuthorizationModule会直接放行，让用户看到了网址重写指向的内容：/info/employee.aspx?Empid=1001。

　　那么什么时候在HttpModule调用网址重写合适呢？他决定于所使用的验证方式，当然如果不使用验证方式的话，那么无论是在BeginRequest事件、AuthenticateRequest事件还是AuthorizeRequest事件中调用网址重写没有多大区别，如果使用表单验证方式并且不使用Windows验证方式的话，把网址重写放入AuthorizeRequest事件委托中调用既可，如果使用Windows验证方式的话，把这项功能放入BeginRequest事件或者AuthenticateRequest事件调用就行了。

　　使用HttpHandler来调用网址重写

　　除了上面所述方法外，网址重写也可以放入HttpHandler或者HttpHandlerFactory中调用。HttpHandler是一个负责针对特定请求生成相应内容的类，而HttpHandlerFactory返回一个HTTP的实例，该实例针对特定请求生成相应内容。

　　本节将着眼于为这些ASP.NET页面创建一个网址重写的HttpHandlerFactory。创建HttpHandlerFactory必须实现IHTTPHandlerFactory接口，它包括一个GetHandler()方法。ASP.NET引擎在初始化这些HttpModule后做出决定针对该请求调用相应的HttpHandler或者HttpHandlerFactory，在调用HttpHandlerFactory的时候，针对该Web请求以及随同的其他信息的HttpContext中经过的的HttpHandlerFactory的GetHandler()方法将被ASP.NET引擎调用，HttpHandlerFactory必须返回一个能委托该请求的对象，并且该对象要能实现IHttpHandler接口。

　　要通过一个HttpHandler来调用网址重写，可以先创建一个HttpHandlerFactory，它的GetHandler()方法检查所请求的网址并决定是否需要调用网址重写。如果要调用网址重写的话则调用前文所述的已通过检查的HttpContext对象的RewritePath()方法。最后该HttpHandlerFactory返回一个由类System.Web.UI.PageParser的GetCompiledInstance()方法返回的HttpHandler。（这与内嵌于ASP.NET页面的HttpHandlerFactory（PageHandlerFactory）的工作原理相同。）

　　在所有HttpModule被初始化后，HttpHandlerFactory就开始被实例化。把网址重写放在这些事件场所的最后一个里头调用的时候，也会碰到相同的问题：文件授权将会失效。如果非要依赖于Windows验证和文件验证的时候，你可能得使用HttpModule来调用网址重写了。
下一章我们着眼于如何构建一个可重用的网址重写引擎，使用下文所提的这些示例均以真实案例作为参照，在作者主页上提供下载。先用用一个简单的网址重写的例子来探讨如何实现网址重写，紧接着将利用网址重写引擎中正则表达式的强大处理能力来展示真正“隐蔽”的网址重写技术！

　　使用网址重写引擎实现简单的网址重写

　　为了便于在Web应用程序中实现网址重写，我构建了一个网址重写引擎，该引擎提供下列功能：

　　·可以在web.config文件中为页面开发者定义其所使用的网址重写引擎的规则；

　　·通过使用正则表达式来使所制定的网址重写规则具有更加强大的重写能力；

　　·能够通过简单配置即可在HttpModule和HttpHandler中使用网址重写。

　　本节只探讨通过HttpModule来实现网址重写，要了解如何通过HttpHandler来实现网址重写请下载本文提供的代码。

　　1. 设置网址重写引擎的配置信息

　　我们来探讨一下在web.config中网址重写规则的配置节。首先必须在web.config文件中指出是否需要在HttpHandler或者HttpModule中调用网址重写，在web.config中，下文已经包含了两个已经被注释掉的配置节：

＜!--
＜HttpModules＞
＜add type="URLRewriter.ModuleRewriter,URLRewriter" name="ModuleRewriter"/＞
＜/HttpModules＞
--＞

＜!--
＜httpHandlers＞
＜add verb="*" path="*.aspx" type="URLRewriter.RewriterFactoryHandler,URLRewriter" /＞
＜/httpHandlers＞
--＞

　　被注释掉的＜HttpModules＞为配置使用HttpModule调用网址重写；注释掉的＜httpHandler＞为配置使用HttpHandler调用网址重写。
不论配置使用＜HttpModules＞还是＜httpHandlers＞调用网址重写，除此之外还须配置网址重写规则，一条重写规则包括两项字符串：请求URL中的查找模式和针对该模式的匹配成功后的替换字符串。该信息在web.config文件中用下列标签描述：

＜RewriterConfig＞
＜Rules＞
＜RewriterRule＞
＜LookFor＞pattern to look for＜/LookFor＞
＜SendTo＞String to replace pattern with ＜/SendTo＞
＜/RewriterRule＞
＜RewriterRule＞
＜LookFor＞pattern to look for＜/LookFor＞
＜SendTo＞String to replace pattern with ＜/SendTo＞
＜/RewriterRule＞

＜/Rules＞
＜/RewriterConfig＞

上一页  [1] [2] [3] [4] [5] [6] [7] [8] [9] 下一页

【责编:Peng】