推薦：淺談使用ASP.NET Global.asax 文件Global.asax文件，有時候叫做ASP.NET應用程序文件，提供了一種在一個中心位置響應應用程序級或模塊級事件的方法。你可以使用這個文件實現應用程序安全性以及其它一些任務。下面讓我們詳細看一下如何在應用程序開發工作中使用這個文件。 概述 Global.asax位于
華能集團下某發電廠的企業網站（基于Asp.Net2.0實現，不允許修改源程序）要求實現“廠內用戶可直接訪問整個站點的所有頁面，廠外用戶只能訪問指定的頁面”的功能，本文將按照需求分析、方案設計、編碼實現、部署應用的順序逐步闡述整個解決方案的形成過程。
1. 需求分析
通過深入的交流和溝通，確認了該發電廠在企業網站用戶訪問控制方面的改進要求，大致情況如下：
a） 網站基于Asp.Net2.0實現，不允許修改源程序
b） 廠內用戶可直接訪問整個站點的所有頁面，員工不需要身份驗證
c） 廠外用戶只能訪問指定的頁面
顯而易見，他們就是針對企業網站增加一項IP過濾功能，在廠外用戶訪問某些敏感頁面時將其拒之門外。首先我們需要設置一個IP列表和一個Url列表，前者包含所有廠內IP，后者包含廠外用戶可訪問的全部Url，并且這兩個列表都是可維護的；另外一個核心問題是，我們需要選擇一個合理的方式將開發好的功能模塊集成到企業網站中，HttpModules義不容辭。
在Asp.Net時代，IIS 接收到請求并將其調度給 aspnet_isapi.dll之后，ASP.NET 引擎開始逐個對已配置的HTTP模塊（HttpModules）進行初始化，然后再調用正確的HTTP處理程序并呈現被請求的資源，最后將所生成的標記返回給 IIS 和請求客戶端（如下圖所示）。
IIS 和 ASP.NET 正在處理請求
如果你想了解更多關于HttpModules的資料，請自行查閱。
2. 方案設計
2.1. 開發環境
編程語言：C#2.0
開發工具：Visual Studio.NET2008
操作系統：windows2003 R2
2.2. 概要設計
使用HttpModules實現IP過濾功能的核心思想是：自定義一個HttpModule捕獲每一個用戶請求，然后獲取相關的用戶IP和被請求的Url進行邏輯判斷，將未授權的請求重定向到一個錯誤提示頁。Http請求授權與否的判斷邏輯為：
1） 判斷請求是否來自本地計算機，是則自動忽略，否則繼續；
2） 判斷用戶IP是否屬于內網（IP列表），是則忽略，否則繼續；
3） 判斷被請求Url是否授權所有用戶訪問，是則忽略，否則繼續；
4） 將請求重定向到錯誤提示頁。
在HttpApplication的BeginRequest事件中附加自定義的處理程序即可完成Http請求的捕獲。此外，為了便于維護我們應將程序運行需要的各項參數（IP列表、Url列表、錯誤提示頁路徑等等）存儲于特定的XML配置文件中，為了提高效率，我們還需要將配置文件執行內存級的緩存處理并對IP、Url匹配算法進行適當的優化。
2.3. 配置緩存算法
配置文件的緩存參照微軟CommonServer項目中的實現邏輯，將配置信息持久化為實體類存儲于HttpContext.Current.Cache中，配置文件發生后緩存信息將自動清空，下次訪問時再次執行持久化操作，不需重啟站點。本文對CommonServer的緩存邏輯不做深入探討，感興趣者可自行搜索相關資料。
2.4. IP列表算法
通過上文可知，當前項目用到的IP列表包含的數據量非常有限，就是電廠web服務器可有效識別的內網IP的窮舉。
因而我們將整個IP列表緩存，使用時直接檢索當前用戶IP是否存在于列表之中即可。在具體IP的存儲方面，我們可將其視作256進制，將IP字符串轉換為數字格式（例如：192.168.10.3可視作192*256*256*256+168*256*256+10*256+3=3232238083，不考慮IPV6）；在參數配置的格式方面，我們應同時支持單個IP或IP段的方式增刪IP列表。
2.5. Url列表算法
就具體需求而言，Url列表是一個授權外網用戶訪問的白名單，換個說法，“對外網用戶而言除了在列表之中的其他都不可訪問”，一旦數據的安全級別降低，會不會出現“對外網用戶而言除了列表之中的其他都可以訪問”的情況出現呢？為了兼容這種后續場景，我們需要為Url列表定義一個“是否黑名單”（IsBlacklist）的附加參數；另外，對于動態網站窮舉Url顯然是不現實的，不管是維護黑名單還是白名單，所以我們可以轉變一下思路，更改最終Url為正則表達式，即：維護一個可匹配目標Url的正則表達式列表，針對用戶請求的具體Url逐個正則表達式執行匹配操作，只要有一個匹配成功則認為當前Url存在于Url列表之中。
3. 編碼實現
由于本文提供全部的c#源碼下載，所以本節僅對源碼壓縮包中的主要文件進行簡要說明：
| 以下為引用的內容： DotCommon.WebsiteFilter │ DotCommonWebsiteFilter.cfg.xml │ WebsiteFilterConfiguration.cs │ WebsiteFilterHttpModule.cs ├─Util │ GlobesCache.cs │ XmlAttributeReader.cs └─WebsiteFilter IPMatchEngine.cs UrlMatchCondition.cs UrlMatchEngine.cs |
DotCommonWebsiteFilter.cfg.xml
運行參數配置文件
WebsiteFilterConfiguration.cs
配置文件實體類
WebsiteFilterHttpModule.cs
實現了System.Web.IHttpModule接口的自定義Http模塊
GlobesCache.cs
全局緩存操控類
XmlAttributeReader.cs
xml節點屬性讀取器
IPMatchEngine.cs
IP匹配引擎
UrlMatchCondition.cs
Url匹配條件（與正則表達式匹配）
UrlMatchEngine.cs
Url匹配引擎
WebsiteFilterHttpModule.cs中BeginRequest自定義處理程序的核心代碼如下：
| 以下為引用的內容： void context_BeginRequest(object sender, EventArgs e) { if (HttpContext.Current.Request.IsLocal)//忽略本地計算機請求 return; string ip = HttpContext.Current.Request.UserHostAddress; if (!WebsiteFilterConfiguration.GetConfig().PickedIPs.IsMatch(ip)) { //若在IP列表中找不到訪客ip string rawUrl = HttpContext.Current.Request.RawUrl; UrlMatchEngine pu = WebsiteFilterConfiguration.GetConfig().PickedUrls; //列表包含當前url且列表為黑名單、列表不包含當前url且列表不為黑名單 時需轉向 //換而言之，“配備結果”與“是否黑名單”取值一致時需轉向 if (pu.IsMatch(rawUrl) == pu.IsBlacklist) { //非公開url自動重定向 HttpContext.Current.Response.Redirect(pu.ErrorPage); } } } |
4. 部署應用
4.1. DotCommonWebsiteFilter.cfg.xml配置文件
配置文件的根節點為DotCommon，所有配置信息均為WebsiteFilter節點的子項。PickedUrl節點對應Url列表，IsBlacklist（1是0否）指示是否為黑名單，ErrorPage指定錯誤提示頁路徑，其子節點add可重復出現，通過pattern屬性指定正則表達式文本，上圖所示配置表示僅網站首頁（default.aspx）允許外網用戶訪問。
PickedIP節點對應IP列表，有效子節點包括add、remove、clear三項。以上圖為例，第一個add指示內網ip為192.168.10.1、192.168.10.2、192.168.10.3、192.168.10.4、192.168.10.5五個；到第二行刪除掉192.168.10.2、192.168.10.3、192.168.10.4還剩192.168.10.1、192.168.10.5兩個；到第三行再添加上192.168.10.3，最終的內網IP列表為192.168.10.1、192.168.10.3、192.168.10.5三個。
4.2. 在企業網站中集成
配置好DotCommonWebsiteFilter.cfg.xml中的各項參數并拷貝到網站根目錄。
拷貝DotCommon.WebsiteFilter.dll文件到網站bin目錄。
在網站根目錄下建立與配置文件中相對應的錯誤提示頁（例如sorry.htm）。
修改Web.config在《httpModules》節點下注冊WebsiteFilter模塊，代碼如下：
| 以下為引用的內容： <httpModules> <add name="WebsiteFilter" type="DotCommon.WebsiteFilterHttpModule, DotCommon.WebsiteFilter"/> </httpModules> |
分別從內網、外網訪問企業網站查看運行效果。
結束語
本文僅針對具體需求闡述解決方案的構思過程，希望對讀者能有所幫助，歡迎提出改進意見。
分享：解讀Java與.NET間進行Web Service交互的選擇談到.NET和Java之間的Web服務交互性時，通常的選擇只有SOAP over HTTP，而根據.NET 3.0的相關規范，這僅有的一個選擇也將會受到更多限制，.NET中提供的BasicHTTP將是唯一能直接與Java Web Servcies進行交互的方式。 最近，有兩個新的選擇出現了
新聞熱點
疑難解答
圖片精選
