在ASP.NET中实现Url Rewriting3

实现网址重写

  　　网址重写技术不但可以在IIS Web服务器一级通过ISAPI过滤器实现，而且还可以在ASP.net一级通过HttpModule或者HttpHandler实现。本文主要关注在ASP.NET一级实现网址重写技术，所以此时不必关注在ISAPI应用程序中实现网址重写的技术细节，而且有很多第三方厂商提供的ISAPI过滤器。

  　　构建网址重写引擎

  　　在ASP.NET中实现网址重写很简单， 只需调用System.Web.HttpContext类的RewritePath()方法即可。HttpContext类中包含有关于特定HTTP请求的HTTP规范信息。ASP.NET引擎每接收到一个特定请求后便针对该请求创建一个特定的实例，这个类包含一些属性诸如： Request和Response属性，分别提供对请求和响应的访问；Application和Session属性提供对Application变量和Session变量的访问；User属性提供对已授权用户信息的访问。

  　　在微软.NET Framework 1.0版本中，RewritePath()方法接收一个新路径的简单字符串，在其内部HttpContext类的RewritePath(string)方法内在地更新Request对象的路径和查询参数。除了RewritePath(string)方法之外，.NET Framework 1.1版还提供了另外一些重载版本，其中一个重载版本接收三个输入字符串参数，这种交替的重载形式不仅仅只是设置Request对象的路径和查询参数这些属性，而是设置更深层的成员变量，这些成员变量用于为 PhysicalPath、PathInfo、FilePath属性计算Request对象值。

  　　为了实现ASP.NET中的网址重写，我们需要创建一个HttpHandler和HttpModule用于：

  　　·根据请求的路径决定所需要重写的路径；

  　　·重写路径，如果需要的话可以调用RewritePath方法；

  　　以前文所构建的那个站点为例，可以通过/info/employee.aspx?empID=EmployeeID来访问每一个雇员的信息。为了使这个网址更加地具有“隐蔽性”，我们可能会使用更加容易理解的访问方式如：/people/雇员名.aspx。这里就有了一个网址重写的案例：当接收到对/people/ScottMitchell.aspx的请求的时候，我们就得使用网址重写使得对该页面的请求被重写指向到先前使用的/info/employee?EmpID=1001地址。

  　　使用HttpModule来调用网址重写

  　　在ASP.NET一级来执行网址重写，既可以使用HttpHandler，也可以使用HttpModule。当使用HttpModule的时候，必须决定如果该网址需要被重写的话，究竟应该在整个请求的生命周期期间的那一个点来使用。乍一看着有些武断，但是这个决定以重大而且微妙的方式影响到你的应用程序。之所以作出对网址重写点的选择是因为内嵌的ASP.NET HttpModule使用Request对象的属性值来完成自己的工作（回忆一下重写路径对Request对象的属性值的改变），这些内嵌HttpModule和相应事件的密切关系列举如下：

  HttpModule 事件 简介

  FormsAuthenticationModule AuthenticateRequest 判断用户是否已通过表单授权方式获取授权，如果没有的话则将用户重定向到指定的登录页面

  FileAuthorizationModule AuthorizeRequest 当使用Windows授权方式的时候，该HttpModule判断并确定该Microsoft Windows帐户是否对其请求的资源拥有足够的权限

  UrlAuthorizationModule AuthorizeRequest 检查并确认请求者是否对所访问的网址拥有权限。该Url授权可以在web.config文件的＜authorization＞和＜location＞元素中配置

  　　回想一下BeginRequest事件在AuthenticateRequest事件之前引发，而AuthenticateRequest事件又在AuthorizeRequest事件之前引发。

  　　实现网址重写的一个较为安全的场合就是把它放在在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事件调用就行了。

查看原文