IIS 與 ASP.NET 程式開發伺服器間的核心差異 (VB)

作者 :Scott Mitchell

下載 PDF

在本機測試 ASP.NET 應用程式時,您可能會使用 ASP.NET Development Web Server。 不過,生產網站最有可能支援 IIS。 這些網頁伺服器處理要求的方式有一些差異,而這些差異可能會產生重要的結果。 本教學課程會探索一些更常見的差異。

簡介

每當使用者造訪 ASP.NET 應用程式時,瀏覽器就會將要求傳送至網站。 Web 服務器軟體會挑選該要求,其會與 ASP.NET 執行時間協調,以產生並傳回所要求資源的內容。 I nternet I nformation S ervices (IIS) 是一套服務,可為 Windows 伺服器提供常見的網際網路型功能。 IIS 是生產環境中 ASP.NET 應用程式最常使用的 Web 服務器;Web 主機提供者最常使用 Web 服務器軟體來提供 ASP.NET 應用程式。 IIS 也可以當做開發環境中的網頁伺服器軟體使用,雖然這需要安裝 IIS 並正確設定它。

ASP.NET 開發伺服器是開發環境的替代 Web 服務器選項;它隨附于 Visual Studio 中,並已整合到 Visual Studio 中。 除非 Web 應用程式已設定為使用 IIS,否則 ASP.NET 開發伺服器會在您第一次從 Visual Studio 內流覽網頁時,自動啟動並當做網頁伺服器使用。 我們在 判斷需要部署哪些檔案 教學課程中建立的示範 Web 應用程式,都是未設定為使用 IIS 的檔案系統型 Web 應用程式。 因此,從 Visual Studio 中流覽其中一個網站時,會使用 ASP.NET Development Server。

在完美的世界中,開發和生產環境會完全相同。 不過,如上一個教學課程中所討論,環境有不同的組態設定並不常見。 在環境中使用不同的 Web 服務器軟體,會在部署應用程式時新增另一個必須納入考慮的變數。 本教學課程涵蓋 IIS 與 ASP.NET 開發伺服器之間的主要差異。 由於這些差異,在某些情況下,在開發環境中執行不完美的程式碼會擲回例外狀況,或在生產環境中執行時的行為不同。

安全性內容差異

每當 Web 服務器軟體處理傳入要求時,就會將該要求與特定安全性內容產生關聯。 作業系統會使用此安全性內容資訊來判斷要求允許的動作。 例如,ASP.NET 網頁可能包含將一些訊息記錄到磁片上檔案的程式碼。 為了讓這個 ASP.NET 網頁在沒有錯誤的情況下執行,安全性內容必須具有適當的檔案系統層級許可權,也就是該檔案的寫入權限。

ASP.NET Development Server 會將連入要求與目前登入使用者的安全性內容產生關聯。 如果您是以系統管理員身分登入桌面,則 ASP.NET 開發伺服器所提供的 ASP.NET 網頁會擁有與系統管理員相同的存取權限。 不過,ASP.NET IIS 處理的要求會與特定電腦帳戶相關聯。 根據預設,雖然您的 Web 主機提供者可能已為每個客戶設定唯一帳戶,但 IIS 第 6 版和 7 版會使用網路服務電腦帳戶。 此外,您的 Web 主機提供者可能授與此電腦帳戶的有限許可權。 最終結果是您可能有網頁在開發環境中執行時沒有錯誤,但在生產環境中裝載時會產生與授權相關的例外狀況。

為了在動作中顯示這種類型的錯誤,我已在書籍評論網站中建立一個頁面,以在磁片上建立一個檔案,以儲存最近一次的日期和時間,在 24 小時內檢閱「教導 自己」ASP.NET 3.5 。 若要跟著做,請開啟頁面, ~/Tech/TYASP35.aspx 並將下列程式碼新增至 Page_Load 事件處理常式:

Protected Sub Page_Load(ByVal sender As Object, ByVal e As  System.EventArgs) Handles Me.Load

    Dim filePath As  String = Server.MapPath("~/LastTYASP35Access.txt")

    Dim contents As  String = String.Format("Last accessed on {0} by {1}", _

                                 DateTime.Now.ToString(), Request.UserHostAddress)

     System.IO.File.WriteAllText(filePath, contents)

End Sub

注意

如果新檔案不存在,則File.WriteAllText 方法會建立新的檔案,然後將指定的內容寫入其中。 如果檔案已經存在,則會覆寫現有的內容。

接下來,使用 ASP.NET Development Server,流覽開發環境中的 24 小時教學 ASP.NET 3.5 書籍檢閱頁面。 假設您已使用具有適當許可權來建立和修改 Web 應用程式根目錄中文字檔的帳戶登入電腦,則書籍檢閱看起來會與之前一樣,但每次流覽頁面的日期和時間和使用者的 IP 位址都會儲存在檔案中 LastTYASP35Access.txt 。 將您的瀏覽器指向此檔案;您應該會看到類似圖 1 所示的訊息。

文字檔包含上次流覽書籍檢閱的日期和時間<

圖 1:文字檔包含上次流覽書籍檢閱的日期和時間, (按一下即可檢視完整大小的影像)

將 Web 應用程式部署到生產環境,然後在 24 小時書籍檢閱頁面中流覽託管的 教導您自己 ASP.NET 3.5 。 此時,您應該會看到書籍評論頁面正常,或圖 2 中顯示的錯誤訊息。 某些 Web 主機提供者會將寫入權限授與匿名 ASP.NET 電腦帳戶,在此情況下,頁面會運作而不會發生錯誤。 不過,如果您的 Web 主機提供者禁止匿名帳戶的寫入權限,當UnauthorizedAccessException頁面嘗試將目前的日期和時間 LastTYASP35Access.txt 寫入檔案時 TYASP35.aspx ,就會引發例外狀況。

IIS 所使用的預設電腦帳戶沒有寫入檔案系統的許可權

圖 2:IIS 所使用的預設電腦帳戶沒有寫入檔案系統的許可權 (按一下即可檢視完整大小的映射)

好消息是,大部分的 Web 主機提供者都有某種許可權工具,可讓您在網站中指定檔案系統許可權。 授與匿名 ASP.NET 帳戶對根目錄的寫入權限,然後重新流覽書籍檢閱頁面。 (如有需要,請連絡 Web 主機提供者,以取得如何將寫入權限授與預設 ASP.NET 帳戶。) 這次頁面應該載入而不會發生錯誤,而且 LastTYASP35Access.txt 應該成功建立檔案。

此處的取捨在於,因為 ASP.NET 開發伺服器在與 IIS 不同的安全性內容下運作,所以您的 ASP.NET 網頁可能會讀取或寫入檔案系統、讀取或寫入 Windows 事件記錄檔,或讀取或寫入 Windows 登錄在開發時如預期般運作,但在生產環境中產生例外狀況。 建置將部署到共用 Web 主控環境的 Web 應用程式時,請勿讀取或寫入事件記錄檔或 Windows 登錄。 也請記下讀取或寫入檔案系統的任何 ASP.NET 網頁,因為您可能需要授與生產環境中適當資料夾的讀取和寫入權限。

提供靜態內容的差異

IIS 與 ASP.NET 開發伺服器之間的另一個核心差異是如何處理靜態內容的要求。 ASP.NET 開發伺服器中的每個要求,無論是針對 ASP.NET 網頁、影像或 JavaScript 檔案,都會由 ASP.NET 執行時間處理。 根據預設,IIS 只會在要求 ASP.NET 資源時叫用 ASP.NET 執行時間,例如 ASP.NET 網頁、Web 服務等。 IIS 會擷取靜態內容 - 影像、CSS 檔案、JavaScript 檔案、PDF 檔案、ZIP 檔案等要求,而不需要 ASP.NET 執行時間介入。 (It is possible to instruct IIS to work with the ASP.NET runtime when serving static content; consult the "Performing Forms-Based Authentication and URL Authentication on Static Files with IIS 7" section in this tutorial for more information.)

ASP.NET 執行時間會執行一些步驟來產生要求的內容,包括驗證 (識別要求者) 和授權 (判斷要求者是否有權檢視要求的內容) 。 常見的驗證形式是 表單型驗證,使用者藉由輸入其認證來識別,通常是使用者名稱和密碼,並輸入網頁上的文字方塊。 驗證其認證時,網站會在使用者的瀏覽器中儲存 驗證票證 Cookie,該 Cookie 會隨著每個後續要求傳送至網站,以及用來驗證使用者的內容。 此外,您可以指定 URL 授權 規則,以指定使用者可以或無法存取特定資料夾的內容。 許多 ASP.NET 網站會使用表單型驗證和 URL 授權來支援使用者帳戶,以及定義只有已驗證使用者或屬於特定角色的使用者才能存取的網站部分。

注意

若要徹底檢查 ASP。NET 的表單型驗證、URL 授權和其他使用者帳戶相關功能,請務必查看我的 網站安全性教學課程

請考慮支援使用表單型授權之使用者帳戶的網站,並具有使用 URL 授權的資料夾,設定為只允許已驗證的使用者。 假設此資料夾包含 ASP.NET 網頁和 PDF 檔案,而意圖是只有已驗證的使用者才能檢視這些 PDF 檔案。

如果訪客嘗試直接在瀏覽器的網址列中輸入 URL 來檢視其中一個 PDF 檔案,會發生什麼事? 若要瞭解,讓我們在書籍評論網站中建立新的資料夾、新增一些 PDF 檔案,並將網站設定為使用 URL 授權來禁止匿名使用者流覽此資料夾。 如果您下載示範應用程式,您會看到我已建立名為 PrivateDocs 的資料夾,並從我的 網站安全性教學課程 新增 PDF, (如何調整!) 。 資料夾 PrivateDocs 也包含檔案 Web.config ,指定拒絕匿名使用者的 URL 授權規則:

<?xml version="1.0"?>

<configuration>

    <system.web>

         <authorization>

            <deny  users="?" />

         </authorization>

     </system.web>

</configuration>

最後,我已將 Web 應用程式設定為使用表單型驗證,方法是更新根目錄中的Web.config檔案,並取代:

<authentication mode="Windows" />

替換為:

<authentication mode="Forms" />

使用 ASP.NET 開發伺服器,流覽網站,然後在瀏覽器網址列中輸入其中一個 PDF 檔案的直接 URL。 如果您已下載與此教學課程相關聯的網站,URL 看起來應該會像這樣: http://localhost:portNumber/PrivateDocs/aspnet_tutorial01_Basics_vb.pdf

在網址列中輸入此 URL 會導致瀏覽器將要求傳送至檔案 ASP.NET 開發伺服器。 ASP.NET 開發伺服器會將要求交給 ASP.NET 執行時間進行處理。 因為我們尚未登入,而且因為資料夾中的 Web.configPrivateDocs 設定為拒絕匿名存取,所以 ASP.NET 執行時間會自動將我們重新導向至登入頁面, Login.aspx (請參閱圖 3) 。 將使用者重新導向至登入頁面時,ASP.NET 包含 ReturnUrl querystring 參數,指出使用者嘗試檢視的頁面。 成功登入使用者之後,可以返回此頁面。

未經授權的使用者會自動重新導向至登入頁面

圖 3:未經授權的使用者會自動重新導向至登入頁面, (按一下即可檢視完整大小的影像)

現在讓我們看看這在生產環境上的行為。 部署您的應用程式,並在生產環境中輸入其中一個 PDF 的 PrivateDocs 直接 URL。 這會提示您的瀏覽器傳送檔案的要求 IIS。 因為要求靜態檔案,所以 IIS 會擷取並傳回檔案,而不叫用 ASP.NET 執行時間。 因此,沒有執行 URL 授權檢查;任何知道檔案直接 URL 的人都可以存取應該私人 PDF 的內容。

匿名使用者可以輸入檔案的直接 URL 來下載私人 PDF 檔案

圖 4:匿名使用者可以輸入檔案的直接 URL 以下載私人 PDF 檔案 (按一下即可檢視完整大小的影像)

使用 IIS 7 在靜態檔案上執行Forms-Based驗證和 URL 驗證

有幾種技術可用來保護靜態內容免于未經授權的使用者。 IIS 7 引進 了整合式管線,將 IIS 的工作流程與 ASP.NET 執行時間的工作流程結合。 簡單地說,您可以指示 IIS 叫用 ASP.NET 執行時間的驗證和授權模組,包括靜態內容 (,例如 PDF 檔案) 等靜態內容。 請連絡您的 Web 主機提供者,瞭解如何設定您的網站以使用整合式管線。

一旦 IIS 設定為使用整合式管線,請將下列標記新增至 Web.config 根目錄中的檔案:

<system.webServer>

      <modules>

          <add  name="FormsAuthenticationModule"  type="System.Web.Security.FormsAuthenticationModule" />

          <remove  name="UrlAuthorization" />

          <add  name="UrlAuthorization"  type="System.Web.Security.UrlAuthorizationModule" />

          <remove  name="DefaultAuthentication" />

          <add  name="DefaultAuthentication"  type="System.Web.Security.DefaultAuthenticationModule" />

      </modules>

</system.webServer>

此標記會指示 IIS 7 使用以 ASP.NET 為基礎的驗證和授權模組。 重新部署您的應用程式,然後重新流覽 PDF 檔案。 這次,當 IIS 處理要求時,它會提供 ASP.NET 執行時間的驗證和授權邏輯來檢查要求的機會。 因為只有已驗證的使用者有權檢視資料夾中的內容 PrivateDocs ,所以匿名訪客會自動重新導向至登入頁面, (回到圖 3) 。

注意

如果您的 Web 主機提供者仍在使用 IIS 6,則您無法使用整合式管線功能。 其中一個因應措施是將私人檔放在禁止 HTTP 存取 (的資料夾中,例如 App_Data) ,然後建立頁面來提供這些檔。 此頁面可能稱為 GetPDF.aspx ,而且會透過 querystring 參數傳遞 PDF 的名稱。 頁面 GetPDF.aspx 會先確認使用者有權檢視檔案,如果是,則會使用 Response.WriteFile(filePath) 方法來將要求之 PDF 檔案的內容傳回要求用戶端。 如果您不想啟用整合式管線,這項技術也適用于 IIS 7。

摘要

生產環境中的 Web 應用程式是使用 Microsoft 的 IIS Web 服務器軟體裝載的。 不過,在開發環境中,應用程式可以使用 IIS 或 ASP.NET 開發伺服器來裝載。 在理想情況下,應該在這兩個環境中使用相同的網頁伺服器軟體,因為使用不同的軟體會在混合中新增另一個變數。 不過,使用 ASP.NET 開發伺服器的便利性可讓您在開發環境中成為吸引人的選擇。 好消息是 IIS 與 ASP.NET 開發伺服器之間只有一些基本差異,而且如果您知道這些差異,您可以採取步驟來協助確保無論環境為何,應用程式的運作和運作方式都相同。

快樂的程式設計!

深入閱讀

如需本教學課程中討論之主題的詳細資訊,請參閱下列資源: