HttpApplication 類(lèi)的實(shí)例是在 ASP.NET 基礎(chǔ)結(jié)構(gòu)中創(chuàng)建的，而不是由用戶(hù)直接創(chuàng)建的。HttpApplication 類(lèi)的一個(gè)實(shí)例在其生存期內(nèi)被用于處理多個(gè)請(qǐng)求，但它一次只能處理一個(gè)請(qǐng)求。這樣，成員變量才可用于存儲(chǔ)針對(duì)每個(gè)請(qǐng)求的數(shù)據(jù)。 應(yīng)用程序按照以下順序執(zhí)行由 global.asax 文件中定義的模塊或用戶(hù)代碼處理的事件： BeginRequest AuthenticateRequest PostAuthenticateRequest AuthorizeRequest PostAuthorizeRequest ResolveRequestCache PostResolveRequestCache 在 PostResolveRequestCache 事件之后、PostMapRequestHandler 事件之前創(chuàng)建一個(gè)事件處理程序（對(duì)應(yīng)于請(qǐng)求 URL 的頁(yè)）。 PostMapRequestHandler AcquireRequestState PostAc

工作原理：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中執(zhí)行URL重寫(xiě)：http://www.microsoft.com/china/msdn/library/webservices/asp.net/URLRewriting.mspx?mfr=true
技巧/訣竅：在asp.net中重寫(xiě)URL：http://blog.joycode.com/scottgu/archive/2007/03/01/94004.aspx
慎用URL重寫(xiě)：http://www.rzrgm.cn/csky/archive/2006/08/09/urlrewrite.html

Asp.net管道處理和HttpApplication中的事件處理順序(From《工作原理》)：

HttpApplication 類(lèi)的實(shí)例是在 ASP.NET 基礎(chǔ)結(jié)構(gòu)中創(chuàng)建的，而不是由用戶(hù)直接創(chuàng)建的。HttpApplication 類(lèi)的一個(gè)實(shí)例在其生存期內(nèi)被用于處理多個(gè)請(qǐng)求，但它一次只能處理一個(gè)請(qǐng)求。這樣，成員變量才可用于存儲(chǔ)針對(duì)每個(gè)請(qǐng)求的數(shù)據(jù)。

應(yīng)用程序按照以下順序執(zhí)行由 global.asax 文件中定義的模塊或用戶(hù)代碼處理的事件：

1. BeginRequest
   
2. AuthenticateRequest
   
3. PostAuthenticateRequest
   
4. AuthorizeRequest
   
5. PostAuthorizeRequest
   
6. ResolveRequestCache
   
7. PostResolveRequestCache
   在 PostResolveRequestCache 事件之后、PostMapRequestHandler 事件之前創(chuàng)建一個(gè)事件處理程序（對(duì)應(yīng)于請(qǐng)求 URL 的頁(yè)）。
   
8. PostMapRequestHandler
   
9. AcquireRequestState
   
10. PostAcquireRequestState
    
11. PreRequestHandlerExecute
    執(zhí)行事件處理程序。

     

12. PostRequestHandlerExecute
    
13. ReleaseRequestState
    
14. PostReleaseRequestState
    在 PostReleaseRequestState 事件之后，響應(yīng)篩選器（如果有）將對(duì)輸出進(jìn)行篩選。
    
15. UpdateRequestCache
    
16. PostUpdateRequestCache
    
17. EndRequest
    

我們應(yīng)該在哪個(gè)事件中重寫(xiě)URL(From《在Asp.net中執(zhí)行URL重寫(xiě)》)：

可以執(zhí)行 URL 重寫(xiě)的一個(gè)安全位置是在 BeginRequest 事件中。也就是說(shuō)，如果 URL 需要重寫(xiě)，該操作將在任何一個(gè)內(nèi)置 HTTP 模塊運(yùn)行后執(zhí)行。使用窗體身份驗(yàn)證時(shí)，這種方法存在一定的缺陷。如果您以前使用過(guò)窗體身份驗(yàn)證，您會(huì)了解當(dāng)用戶(hù)訪問(wèn)受限資源時(shí)，他們將被自動(dòng)重定向到指定的登錄頁(yè)面。成功登錄后，用戶(hù)將被返回到他們第一次嘗試訪問(wèn)的頁(yè)面。

如果在 BeginRequest 或 AuthenticateRequest 事件中執(zhí)行 URL 重寫(xiě)，登錄頁(yè)面（提交后）將把用戶(hù)重定向到重寫(xiě)后的頁(yè)面上。也就是說(shuō)，假設(shè)用戶(hù)在其瀏覽窗口中鍵入了 /people/ScottMitchell.aspx，此地址將被重寫(xiě)為 /info/employee.aspx?empID=1001。如果將 Web 應(yīng)用程序配置為使用窗體身份驗(yàn)證，當(dāng)用戶(hù)第一次訪問(wèn) /people/ScottMitchell.aspx 時(shí)，首先，URL 將被重寫(xiě)為 /info/employee.aspx?empID=1001；接下來(lái)，FormsAuthenticationModule 將運(yùn)行，并將用戶(hù)重定向到登錄頁(yè)面（如果需要）。但是，用戶(hù)在成功登錄后將被發(fā)送到 /info/employee.aspx?empID=1001，因?yàn)楫?dāng) FormsAuthenticationModule 運(yùn)行后，此 URL 即是請(qǐng)求的 URL。

同樣，在 BeginRequest 或 AuthenticateRequest 事件中執(zhí)行重寫(xiě)時(shí)，UrlAuthorizationModule 看到的將是重寫(xiě)后的 URL。也就是說(shuō)，如果您在 Web.config 文件中使用 <location> 元素來(lái)為特定的 URL 指定授權(quán)，則必須引用重寫(xiě)后的 URL。

要解決這些細(xì)微問(wèn)題，您可以決定在 AuthorizeRequest 事件中執(zhí)行 URL 重寫(xiě)。此方法解決了 URL 授權(quán)和窗體身份驗(yàn)證的一些問(wèn)題，但同時(shí)也產(chǎn)生了新的問(wèn)題：文件授權(quán)無(wú)法工作。使用 Windows 身份驗(yàn)證時(shí)，FileAuthorizationModule 將檢查以確保通過(guò)身份驗(yàn)證的用戶(hù)具有訪問(wèn)特定 ASP.NET 頁(yè)面的相應(yīng)權(quán)限。

假設(shè)一組用戶(hù)對(duì) C:\Inetput\wwwroot\info\employee.aspx 沒(méi)有 Windows 級(jí)別的文件訪問(wèn)權(quán)限，并要嘗試訪問(wèn) /info/employee.aspx?empID=1001，他們將會(huì)收到授權(quán)錯(cuò)誤消息。但是，如果我們將 URL 重寫(xiě)移到 AuthenticateRequest 事件中，當(dāng) FileAuthorizationModule 檢查安全設(shè)置時(shí)，仍然認(rèn)為被請(qǐng)求的文件是 people/ScottMitchell.aspx，因?yàn)樵?URL 必須被重寫(xiě)(感覺(jué)這句話有問(wèn)題，這句話的英文原文：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"語(yǔ)義是指將要被重寫(xiě)但還沒(méi)有被重寫(xiě)，顯然這里就有邏輯錯(cuò)誤了，參照上面的HttpApplication事件的觸發(fā)順序，我們將 URL 重寫(xiě)移到 AuthenticateRequest 事件中，那么先執(zhí)行驗(yàn)證請(qǐng)求AuthenticateRequest事件時(shí)，就已經(jīng)把用戶(hù)請(qǐng)求的url重寫(xiě)成/info/employee.aspx?empID=1001了，所以再下一步授權(quán)請(qǐng)求FileAuthorizationModule中，asp.net是對(duì)重寫(xiě)后的url：/info/employee.aspx進(jìn)行文件授權(quán)，所以當(dāng)用戶(hù)沒(méi)有Windows級(jí)別的文件訪問(wèn)權(quán)限時(shí)，是不能被檢查通過(guò)的，也就不存在其中描述的能查看該頁(yè)面的情況。所以我覺(jué)得這句話的英文版本中敘述有誤，中文版就錯(cuò)得更離譜了....)。因此，文件授權(quán)檢查將通過(guò)，允許此用戶(hù)查看重寫(xiě)后的 URL /info/employee.aspx?empID=1001 的內(nèi)容。

那么，應(yīng)該何時(shí)在 HTTP 模塊中執(zhí)行 URL 重寫(xiě)？這取決于要使用的身份驗(yàn)證類(lèi)型。
如果不想使用任何身份驗(yàn)證，則無(wú)論 URL 重寫(xiě)發(fā)生在 BeginRequest、AuthenticateRequest 還是 AuthorizeRequest 中都沒(méi)有什么關(guān)系。
如果要使用窗體身份驗(yàn)證而不使用 Windows 身份驗(yàn)證，請(qǐng)將 URL 重寫(xiě)放在 AuthorizeRequest 事件處理程序中執(zhí)行。
最后，如果要使用 Windows 身份驗(yàn)證，請(qǐng)?jiān)?BeginRequest 或 AuthenticateRequest 事件進(jìn)行過(guò)程中安排 URL 重寫(xiě).