ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 使用 HTTP 模块执行 URL 重写

使用 HTTP 模块执行 URL 重写

原创 Linux操作系统 作者:ForTechnology 时间:2011-08-17 17:05:10 0 删除 编辑
例如,假设我们的网站中包含每个员工通过 /info/employee.aspx?empID=employeeID 均可访问的信息。为了使 URL 可以更多地被“删节”,我们可以决定通过以下地址来访问员工页面:/people/EmployeeName.aspx。这就是我们要使用 URL 重写的一个例子。也就是说,在请求 /people/ScottMitchell.aspx 页面时,我们要重写该 URL,以便使用 /info/employee.aspx?empID=1001 页面。

使用 HTTP 模块执行 URL 重写
在 ASP.NET 级别执行 URL 重写时,可以使用 HTTP 模块或 HTTP 处理程序来执行重写。使用 HTTP 模块时,必须决定在请求有效期内的哪个时间点上来检查 URL 是否需要重写。乍一看,这似乎可以任意选择,但决定会以一种明显而微妙的方式对应用程序产生影响。由于内置 ASP.NET HTTP 模块使用 Request 对象的属性执行任务,因此选择在何处执行重写非常重要。(如上所述,重写路径将改变 Request 对象的属性值。)下面列出了这些密切相关的内置 HTTP 模块及其捆绑到的事件:

HTTP 模块 事件 说明
FormsAuthenticationModule
AuthenticateRequest
确定用户是否通过了窗体身份验证。如果没有,用户将被自动复位向到指定的登录页面。

FileAuthorizationMoudle
AuthorizeRequest
使用 Windows 身份验证时,此 HTTP 模块将检查以确保 Microsoft® Windows® 帐户对被请求的资源具有足够的权限。

UrlAuthorizationModule
AuthorizeRequest
检查以确保请求者可以访问指定的 URL。通过 Web.config 文件中的 元素来指定 URL 授权。


如上所述,BeginRequest 事件在 AuthenticateRequest 之前触发,后者在 AuthenticateRequest 之前触发。

可以执行 URL 重写的一个安全位置是在 BeginRequest 事件中。也就是说,如果 URL 需要重写,该操作将在任何一个内置 HTTP 模块运行后执行。使用窗体身份验证时,这种方法存在一定的缺陷。如果您以前使用过窗体身份验证,您会了解当用户访问受限资源时,他们将被自动复位向到指定的登录页面。成功登录后,用户将被返回到他们第一次尝试访问的页面。

如果在 BeginRequest 或 AuthenticateRequest 事件中执行 URL 重写,登录页面(提交后)将把用户复位向到重写后的页面上。也就是说,假设用户在其浏览窗口中键入了 /people/ScottMitchell.aspx,此地址将被重写为 /info/employee.aspx?empID=1001。如果将 Web 应用程序配置为使用窗体身份验证,当用户第一次访问 /people/ScottMitchell.aspx 时,首先,URL 将被重写为 /info/employee.aspx?empID=1001;接下来,FormsAuthenticationModule 将运行,并将用户复位向到登录页面(如果需要)。但是,用户在成功登录后将被发送到 /info/employee.aspx?empID=1001,因为当 FormsAuthenticationModule 运行后,此 URL 即是请求的 URL。

同样,在 BeginRequest 或 AuthenticateRequest 事件中执行重写时,UrlAuthorizationModule 看到的将是重写后的 URL。也就是说,如果您在 Web.config 文件中使用 元素来为特定的 URL 指定授权,则必须引用重写后的 URL。

要解决这些细微问题,您可以决定在 AuthorizeRequest 事件中执行 URL 重写。此方法解决了 URL 授权和窗体身份验证的一些问题,但同时也产生了新的问题:文件授权无法工作。使用 Windows 身份验证时,FileAuthorizationModule 将检查以确保通过身份验证的用户具有访问特定 ASP.NET 页面的相应权限。

假设一组用户对 C:\Inetput\wwwroot\info\employee.aspx 没有 Windows 级别的文件访问权限,并要尝试访问 /info/employee.aspx?empID=1001,他们将会收到授权错误消息。但是,如果我们将 URL 重写移到 AuthenticateRequest 事件中,当 FileAuthorizationModule 检查安全设置时,仍然认为被请求的文件是 people/ScottMitchell.aspx,因为该 URL 必须被重写。因此,文件授权检查将通过,允许此用户查看重写后的 URL /info/employee.aspx?empID=1001 的内容。

那么,应该何时在 HTTP 模块中执行 URL 重写?这取决于要使用的身份验证类型。如果不想使用任何身份验证,则无论 URL 重写发生在 BeginRequest、AuthenticateRequest 还是 AuthorizeRequest 中都没有什么关系。如果要使用窗体身份验证而不使用 Windows 身份验证,请将 URL 重写放在 AuthorizeRequest 事件处理程序中执行。最后,如果要使用 Windows 身份验证,请在 BeginRequest 或 AuthenticateRequest 事件进行过程中安排 URL 重写。

在 HTTP 处理程序中执行 URL 重写
也可以由 HTTP 处理程序或 HTTP 处理程序工厂执行 URL 重写。如上所述,HTTP 处理程序是负责生成特定类型请求的内容的类;HTTP 处理程序工厂是负责返回 HTTP 处理程序实例的类,该实例可以生成特定类型请求的内容。

在本文中,我们将对如何为 ASP.NET 网页创建 URL 重写 HTTP 处理程序工厂进行讨论。HTTP 处理程序工厂必须实现 IHttpHandlerFactory 接口,此接口包括 GetHandler() 方法。初始化相应的 HTTP 模块后,ASP.NET 引擎将确定为给定的请求调用哪个 HTTP 处理程序或 HTTP 处理程序工厂。如果要调用 HTTP 处理程序工厂,ASP.NET 引擎将为 Web 请求调用传入 HttpContext 的 HTTP 处理程序工厂的 GetHandler() 方法,以及一些其他信息。然后,HTTP 处理程序工厂必须返回一个对象,该对象将实现可以处理请求的 IHttpHandler。

要通过 HTTP 程序程序执行 URL 重写,我们可以创建一个 HTTP 处理程序工厂,该处理程序工厂的 GetHandler() 方法将检查被请求的路径,以确定是否需要重写 URL。如果需要,它可以调用传入的 HttpContext 对象的 RewritePath() 方法,如前面所讨论的。最后,HTTP 处理程序工厂可以返回由 System.Web.UI.PageParser 类的 GetCompiledPageInstance() 方法返回的 HTTP 处理程序。(此技术与内置 ASP.NET 网页 HTTP 处理程序工厂 PageHandlerFactory 工作时所应用的技术相同。)

由于所有 HTTP 模块都将在实例化自定义 HTTP 处理程序工厂之前进行初始化,因此,在将 URL 重写放在事件的后半段时,使用 HTTP 处理程序工厂就会带来相同的风险,即文件授权无法工作。因此,如果您依赖于 Windows 身份验证和文件授权,您可能希望为 URL 重写使用 HTTP 模块方法。

在下一部分中,我们将对构建可重用的 URL 重写引擎进行讨论。在介绍了 URL 重写引擎(可通过下载本文的代码获得)之后,我们将在剩下的两个部分中对 URL 重写的实际使用情况进行介绍。首先,我们将讨论如何使用 URL 重写引擎,并介绍一个简单的 URL 重写示例。接下来,我们将利用重写引擎的正则表达式功能来提供真正“可删节”的 URL。

返回页首
构建 URL 重写引擎
为了有助于描述如何在 ASP.NET Web 应用程序中实现 URL 重写,我创建了 URL 重写引擎。此重写引擎将提供以下功能:

• 使用 URL 重写引擎的 ASP.NET 页面开发人员可以在 Web.config 文件中指定重写规则。

• 重写规则可以使用正则表达式来实现功能强大的重写规则。

• 可以轻松地将 URL 重写配置为使用 HTTP 模块或 HTTP 处理程序。


在本文中,我们将介绍仅使用 HTTP 模块的 URL 重写。要查看如何使用 HTTP 处理程序来执行 URL 重写,请参考可随本文下载的代码。

为 URL 重写引擎指定配置信息
让我们先介绍一下 Web.config 文件中重写规则的结构。首先,您需要在 Web.config 文件中指明要使用 HTTP 模块还是 HTTP 处理程序来执行 URL 重写。在下载代码中,Web.config 文件包含两个已注释掉的条目:

<!--

name="ModuleRewriter" />

-->

<!--

type="URLRewriter.RewriterFactoryHandler, URLRewriter" />

-->

注释掉 条目,以使用 HTTP 模块执行重写;注释掉 条目,以使用 HTTP 处理程序执行重写。

除了指定使用 HTTP 模块还是 HTTP 处理程序执行重写外,Web.config 文件还包含重写规则:重写规则由两个字符串组成:要在被请求的 URL 中查找的模式;要替换此模式的字符串(如果找到)。在 Web.config 文件中,此信息是使用以下语法表达的:




要查找的模式
要用来替换模式的字符串


要查找的模式
要用来替换模式的字符串

...



每个重写规则均由 元素表达。要搜索的模式由 元素指定,而要替换所找到的模式的字符串将在 元素中输入。这些重写规则将从头到尾进行计算。如果发现与某个规则匹配,URL 将被重写,并且对重写规则的搜索将会终止。

元素中指定模式时,请注意,要使用正则表达式来执行匹配和字符串替换。(稍后,我们将介绍一个真实的示例,说明如何使用正则表达式来搜索模式。)由于模式是正则表达式,应确保转义正则表达式中的任何保留字符。(一些正则表达式保留字符包括:.、?、^、$ 及其他。可以通过在前面加反斜杠(如 \.)对这些字符进行转义,以匹配文字句点。)

使用 HTTP 模块执行 URL 重写
创建 HTTP 模块与创建可以实现 IHttpModule 接口的类一样简单。IHttpModule 接口定义了两种方法:

• Init(HttpApplication)。此方法在初始化 HTTP 模块后触发。在此方法中,您将把事件处理程序绑定到相应的 HttpApplication 事件。

• Dispose()。当请求已完成并已发送回 IIS 时调用此方法。您应当在此处执行所有最终的清除操作。


为了便于为 URL 重写创建 HTTP 模块,我将从创建抽象基类 BaseModuleRewriter 开始介绍。此类将实现 IHttpModule。在 Init() 事件中,它将 HttpApplication 的 AuthorizeRequest 事件绑定到 BaseModuleRewriter_AuthorizeRequest 方法。BaseModuleRewriter_AuthorizeRequest 方法将调用该类传入被请求的 Path 的 Rewrite() 方法,以及传入 Init() 方法的 HttpApplication 对象。Rewrite() 方法是抽象的,也就是说,在 BaseModuleRewriter 类中,Rewrite() 方法没有方法主体;从 BaseModuleRewriter 派生而来的类必须覆盖此方法并提供方法主体。

具有此基类后,只需创建由 BaseModuleRewriter 派生的类即可,该类可以覆盖 Rewrite() 并在那里执行 URL 重写逻辑。下面显示了 BaseModuleRewriter 的代码。

public abstract class BaseModuleRewriter : IHttpModule
{
public virtual void Init(HttpApplication app)
{
// 警告!此代码不适用于 Windows 身份验证!
// 如果使用 Windows 身份验证,
// 请改为 app.BeginRequest
app.AuthorizeRequest += new
EventHandler(this.BaseModuleRewriter_AuthorizeRequest);
}

public virtual void Dispose() {}

protected virtual void BaseModuleRewriter_AuthorizeRequest(
object sender, EventArgs e)
{
HttpApplication app = (HttpApplication) sender;
Rewrite(app.Request.Path, app);
}

protected abstract void Rewrite(string requestedPath,
HttpApplication app);
}

请注意,BaseModuleRewriter 类将在 AuthorizeRequest 事件中执行 URL 重写。如上所述,如果将 Windows 身份验证与文件授权结合使用,您需要对此做出更改,以便可以在 BeginRequest 或 AuthenticateRequest 事件中执行 URL 重写。

ModuleRewriter 类扩展了 BaseModuleRewriter 类,并负责执行实际的 URL 重写。ModuleRewriter 包含单一覆盖方法(Rewrite()),如下所示:

protected override void Rewrite(string requestedPath,
System.Web.HttpApplication app)
{
// 获得配置规则
RewriterRuleCollection rules =
RewriterConfiguration.GetConfig().Rules;

// 遍历每个规则...
for(int i = 0; i < rules.Count; i++)
{
// 获得要查找的模式,并且
// 解析 Url(转换为相应的目录)
string lookFor = "^" +
RewriterUtils.ResolveUrl(app.Context.Request.ApplicationPath,
rules[i].LookFor) + "$";

// 创建 regex(请注意,已设置 IgnoreCase...)
Regex re = new Regex(lookFor, RegexOptions.IgnoreCase);

// 查看是否找到了匹配的规则
if (re.IsMatch(requestedPath))
{
// 找到了匹配的规则 -- 进行必要的替换
string sendToUrl =
RewriterUtils.ResolveUrl(app.Context.Request.ApplicationPath,
re.Replace(requestedPath, rules[i].SendTo));

// 重写 URL
RewriterUtils.RewriteUrl(app.Context, sendToUrl);
break; // 退出 For 循环
}
}
}

Rewrite() 方法从获取 Web.config 文件中的一组重写规则开始。然后,它将遍历重写规则,每次遍历一个,对于每个规则,它将获取规则的 LookFor 属性,并使用正则表达式来确定是否在被请求的 URL 中找到了匹配的规则。

如果找到了匹配的规则,将在具有 SendTo 属性值的被请求路径上执行正则表达式替换。然后,替换后的 URL 将被传递到 RewriterUtils.RewriteUrl() 方法中。RewriterUtils 是一个 helper 类,此类将提供一对由 URL 重写 HTTP 模块和 HTTP 处理程序使用的静态方法。RewriterUrl() 方法仅调用 HttpContext 对象的 RewriteUrl() 方法。

注意:您可能已注意到,执行正则表达式匹配和替换时,将调用 RewriterUtils.ResolveUrl()。此 helper 方法只替换具有应用程序路径值的字符串中的所有 ~ 实例。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/25897606/viewspace-705171/,如需转载,请注明出处,否则将追究法律责任。

上一篇: .NET处理HTTP请求
下一篇: 虚拟目录定位
请登录后发表评论 登录
全部评论

注册时间:2011-07-21

  • 博文量
    220
  • 访问量
    662328