收集的几篇关于Asp.Net处理原理和URL重写的几篇文章

简介:

工作原理: http://www.microsoft.com/china/technet/security/guidance/secmod37.mspx  
URL Rewriting in asp.net: http://msdn2.microsoft.com/en-us/library/ms972974.aspx
在Asp.net中执行URL重写: http://www.microsoft.com/china/msdn/library/webservices/asp.net/URLRewriting.mspx?mfr=true
技巧/诀窍:在asp.net中重写URL: http://blog.joycode.com/scottgu/archive/2007/03/01/94004.aspx
慎用URL重写: http://www.cnblogs.com/csky/archive/2006/08/09/urlrewrite.html





Asp.net管道处理和HttpApplication中的事件处理顺序(From工作原理):
secmod37_02.jpg

HttpApplication 类的实例是在 ASP.NET 基础结构中创建的,而不是由用户直接创建的。HttpApplication 类的一个实例在其生存期内被用于处理多个请求,但它一次只能处理一个请求。这样,成员变量才可用于存储针对每个请求的数据。

应用程序按照以下顺序执行由 global.asax 文件中定义的模块或用户代码处理的事件:

  1. BeginRequest 
  2. AuthenticateRequest 
  3. PostAuthenticateRequest 
  4. AuthorizeRequest 
  5. PostAuthorizeRequest 
  6. ResolveRequestCache 
  7. PostResolveRequestCache 
    在 PostResolveRequestCache 事件之后、PostMapRequestHandler 事件之前创建一个事件处理程序(对应于请求 URL 的页)。
  8. PostMapRequestHandler 
  9. AcquireRequestState 
  10. PostAcquireRequestState 
  11. PreRequestHandlerExecute 
    执行事件处理程序。

     

  12. PostRequestHandlerExecute 
  13. ReleaseRequestState 
  14. PostReleaseRequestState 
    在 PostReleaseRequestState 事件之后,响应筛选器(如果有)将对输出进行筛选。
  15. UpdateRequestCache 
  16. PostUpdateRequestCache 
  17. EndRequest 







我们应该在哪个事件中重写URL(From《在Asp.net中执行URL重写》):

可以执行 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 文件中使用 <location> 元素来为特定的 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 必须被重写(感觉这句话有问题,这句话的英文原文:However, if we move the URL rewriting to the AuthenticateRequest event, when the FileAuthorizationModule checks the security settings, it still thinks the file being requested is /people/ScottMitchell.aspx, since the URL has yet to be rewritten。其中的"has yet to be rewriten"语义是指将要被重写但还没有被重写,显然这里就有逻辑错误了,参照上面的HttpApplication事件的触发顺序,我们将 URL 重写移到AuthenticateRequest 事件中,那么先执行验证请求AuthenticateRequest事件时,就已经把用户请求的url重写成/info/employee.aspx?empID=1001了,所以再下一步授权请求FileAuthorizationModule中,asp.net是对重写后的url:/info/employee.aspx进行文件授权,所以当用户没有Windows级别的文件访问权限时,是不能被检查通过的,也就不存在其中描述的能查看该页面的情况。所以我觉得这句话的英文版本中叙述有误,中文版就错得更离谱了....)。因此,文件授权检查将通过,允许此用户查看重写后的 URL /info/employee.aspx?empID=1001 的内容。

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


本文转自Silent Void博客园博客,原文链接:http://www.cnblogs.com/happyhippy/archive/2007/08/06/845236.html,如需转载请自行联系原作者

相关文章
|
5月前
|
iOS开发
解决alert在ios版微信中显示url的问题(重写alert)
解决alert在ios版微信中显示url的问题(重写alert)
43 0
|
缓存 网络协议 前端开发
浏览器原理 04 # 导航流程:从输入URL到页面展示,这中间发生了什么?
浏览器原理 04 # 导航流程:从输入URL到页面展示,这中间发生了什么?
122 0
浏览器原理 04 # 导航流程:从输入URL到页面展示,这中间发生了什么?
|
缓存 应用服务中间件 Shell
Nginx实战(二) URL重写
Nginx实战(二) URL重写
129 0
|
移动开发
详解IIS中的重写工具下关于操作重定向URL中的{R:N}与{C:N}
详解IIS中的重写工具下关于操作重定向URL中的{R:N}与{C:N}
148 0
详解IIS中的重写工具下关于操作重定向URL中的{R:N}与{C:N}
|
应用服务中间件 nginx 开发者
Nginx反向代理/location/URL重写功能实战| 学习笔记
快速学习Nginx反向代理/location/URL重写功能实战。
154 0
Nginx反向代理/location/URL重写功能实战| 学习笔记
|
开发框架 .NET
ASP.NET Core获取请求完整的Url
ASP.NET Core获取请求完整的Url
411 0
ASP.NET Core获取请求完整的Url
|
应用服务中间件 nginx
Nginx反向代理/location/URL重写功能实战
一、Nginx反向代理常用实战 二、location 应用实例
Nginx反向代理/location/URL重写功能实战
|
SQL 开发框架 前端开发
Asp.net core项目实战 新闻网站+后台 源码、设计原理、视频教程
Asp.net core项目实战 新闻网站+后台 源码、设计原理、视频教程
285 0
Asp.net core项目实战 新闻网站+后台 源码、设计原理、视频教程
|
开发框架 前端开发 中间件
ASP.NET Core端点路由 作用原理
端点路由(Endpoint Routing)最早出现在ASP.NET Core2.2,在ASP.NET Core3.0提升为一等公民。
ASP.NET Core端点路由 作用原理
|
搜索推荐 安全 Java
UrlRewrite:重写url,实现伪静态、缩短URL、高安全性
UrlRewrite:重写url,实现伪静态、缩短URL、高安全性
325 0

相关产品

  • 云迁移中心
  • 相关实验场景

    更多