Asp.net 中的web.config文件

　　在學習Asp.net的時候，發現web.config這個文件很有用，就找了些資料，彙集在這裏，以供有需要的人蔘考。
　　所有.NET的應用程序都將其信息保存在一個基於XML的配置文件裏。Web應用程序會使用位於應用程序根目錄下的web.config文件，用於ASP.NET應用程序的web.config包含的信息和其應用程序大多數的操作都相關。通過Web.config，你可爲網站定義諸如自定義的404報錯頁、(身份)驗證和授權等設置；如果允許跟蹤，還可爲ASP.NET的網頁設置編譯選項。
　　Web.config在根層是 <configuration> 的標記。在這個標記內，可以添加許多其他的標記，在要定義的大部分的網站配置參數的地方，最常用，也是最有用的一個是 system.web 標記。另外，爲定義 application-wide 的設置，要使用<appSettings> 標記。在這個標記中，可用 <add ... /> 標記定義0到多個設置。例如：如果我們希望增加一個數據庫連接串參數，我們可以用如下的 Web.config 文件：

<configuration>

<!-- application specific settings -->

<appSettings>

<add key="connString" value="connection string" />

</appSettings>

<system.web>

...

</system.web>

</configuration>

　　如上的代碼添加了一個名爲connString 的 application-wide 設置，由connection string提供數據連接串的值。現在，你可以在這個
網站的大部分ASP.NET網頁中，用下面的語句讀取 connString 這個參數的值：

　　string connstr=ConfigurationSettings.AppSettings("connString")

　　如果正在創建一個大型ASP.NET應用，比較明智的決定是將大量的網站全局管理、調整屬性定義爲 application-wide 參數。到目
前爲止，可以象剛纔我們所作的那樣使用 appSettings 標記。這裏存在一個問題，別人想整合你的程序的時候，要是已經存在名稱一
樣的配置，他將不得進行不修改大範圍修改，使不產生衝突。這種情況要不要發生，就看你自己想把網站往哪方面做了。

　　若要避免這種混亂，可在Web.config 文件中，把應用程序的設置“分組”爲一個唯一的標記。也就是說可以在Web.config 文件
中創建一個名爲 <MyAppSettings> 的標記，然後再象我們前面所述那樣簡單地添加application-wide 的設置。爲了在 Web.config 中
自定義一個標記，必須先通過 <configSections> 標記，在Web.config 中明確的定義一個新的標記名稱，例如：

<configuration>

<configSections>

<section name="MyAppSettings"

type="System.Configuration.NameValueFileSectionHandler,

System, Version=1.0.3300.0, Culture=neutral,

PublicKeyToken=b77a5c561934e089" />

</configSections>

...

</configuration>

注意：

在 <section ... /> 標記中的type屬性值都必須寫在同一行中，在這裏換行是爲了看起來更清晰。

這個 <section ... /> 標記指明將添加一個自定義的名爲 MyAppSettings 的標記。從現在開始，爲了添加application-wide 參數，我們
能在Web.config 文件中添加一個 <MyAppSettings> 標記和 <add ... /> 標記，如下所示：

<configuration>

<configSections>

<section name="MyAppSettings"

type="System.Configuration.NameValueFileSectionHandler,

System, Version=1.0.3300.0, Culture=neutral,

PublicKeyToken=b77a5c561934e089" />

</configSections>

<MyAppSettings>

<add key="connString" value="connection string" />

</MyAppSettings>

...

</configuration>

　　最後，爲了在ASP.NET 的網頁中，讀取這個自定義的值，我們用如下的語法：

　　ConfigurationSettings.GetConfig("MyAppSettings")("connString")

　　更一般的做法是：把 MyAppSettings 替換爲你選擇用來存放自定義設置標記的名稱；同時把 connString 替換爲在自定義設置
標記中，你希望讀取的參數名稱。通過這種方法，可以有效地解決上面提到的衝突，當然，特殊情況例外。

　　在web.config文件中，<authentication>這一區段定義了服務器進行用戶驗證這一過程的細節。所支持的三種不同模式是
Windows、Forms和Passport。現在我們來仔細看看每種模式：

• Windows驗證通過Windows的系統帳號來驗證用戶，例如活動目錄（Active Directory）。Windows驗證是最安全的驗證形
  
  式，對於程序員來說這種模式是很簡單的，因爲整個過程都是由操作系統來處理的。但是，網站的每個用戶都需要一個系
   
  統帳號，所以這種模式會被限制在企業內部網（intranet）的應用程序裏。
• Passport驗證使用護照來驗證用戶，它是第二安全的驗證方式。其最好的用武之地是大型的、活動的Internet電子商務應用程

              序，這些程序會驗證用戶的服務使用費。這種模式是.NET所選擇的驗證方法。

• Forms驗證是安全性最低的驗證方法，因爲必須要由你的應用程序自己來處理驗證過程。但是，這是最有可能在你Internet應
  
  用程序上使用的模式，因爲它所需要的管理和維護是最少的。

　　應用Forms驗證的一個例子如下：


　文件目錄爲:

 +BIN
 +Admin
    -index.aspx
    - test.aspx
    - *.aspx
    - web.config //Admin文件夾下的web.config
 login.aspx
 web.config //根目錄的web.config
 index.aspx 

 

(-)FormsAuthentication的重要方法以及屬性
FormsCookieName
 返回用於當前應用程序的已配置 Cookie 名稱。
GetAuthCookie
 爲給定的用戶名創建身份驗證 Cookie。這不會將 Cookie 設置爲傳出響應的一部分，因此應用程序對如何發出該 Cookie 有更多的
控制權限。
Authenticate
 給定所提供的憑據，嘗試根據包含在已配置憑據存儲區中的憑據對憑據進行驗證。
GetRedirectUrl
 返回導致重定向到登錄頁的原始請求的重定向 URL。
HashPasswordForStoringInConfigFile
 給定標識哈希類型的密碼和字符串，該例程產生一個適合存儲在配置文件中的哈希密碼。
RedirectFromLoginPage
 將已驗證身份的用戶重定向回最初請求的 URL。
{=========
備註
RedirectFromLoginPage 方法重定向到在查詢字符串中指定的返回 URL 鍵。例如，在 URL http://www.contoso.com/login.aspx?
ReturnUrl=caller.aspx 中，caller.aspx 是 RedirectFromLoginPage 所重定向到的返回 URL。如果返回鍵不存在，則
 RedirectFromLoginPage 將重定向到 Default.aspx。
    =========}
SetAuthCookie
 創建身份驗證票並將其附加到 Cookie 的傳出響應的集合。它不執行重定向。
SignOut
 移除身份驗證票.

(二)讓我們一步一步徹底明白頁面是怎樣驗證的

再次說明我們驗證的目的:
 Admin文件夾是管理員進行後臺管理的"專區",只有通過login.aspx登陸驗證後才能進入Admin文件夾裏面訪問裏面的所有頁面,我們
必須通過填寫login.aspx的表單來驗證用戶是否是管理員.

(1) 假設我們在根目錄的index.aspx設置一個連接<a href=login.aspx>管理員登陸</a>,管理員可以通過這個連接,訪問login.aspx進行填寫
表單.這裏出現了一個奇妙的思維定勢的問題,我們習慣這個"管理員登陸"連接來連接到login.aspx,其實在這裏,我們錯了,應該"直接"連
接到Admin文件夾(或者裏面的任何頁面),有人問:"這豈不是普通訪問者也可以通過這個連接直接連接到了Admin的頁面了嗎?",對!,這
就是基於表單驗證的美妙之處,不用擔心這個問題,看看我們的2個web.config就明白了!

看看Admin文件夾裏面的web.config

<configuration>
 <system.web>
  <authorization>
   <deny users="?" />
  </authorization>
 </system.web>
</configuration>

有一個<deny users="?"/>,就是說沒有通過驗證的匿名用戶絕對禁止訪問這個文件夾-Admin.
那麼,如果匿名用戶真的這樣做了(試圖連接Admin文件夾裏面的頁面)會怎樣呢?哈哈,會定向到login.aspx頁面的,看看根目錄的
web.config

<configuration>
 <system.web>
  <authentication mode="Forms">
   <forms name="mycookiename" loginUrl="login.aspx" protection="All" timeout="30">
   </forms>
  </authentication>
  <authorization>
   <allow users="*"/>
  </authorization>
 </system.web>
</configuration>

根目錄的web.config設置了驗證方式,以及相應的處理情況.
<authentication mode="Forms">來設置了驗證方式mode="Forms";
<forms name="mycookiename" loginUrl="login.aspx" protection="All" timeout="30"/>
看到了loginurl="login.aspx"了嗎?就是說,如果匿名用戶試圖連接受保護的頁面(Admin文件夾),則定向到login.aspx,來讓這個匿名用戶
登陸!

(2)我們點擊了那個"管理員登陸"鏈接,來到了login.aspx.此時你會發現,URL地址其實是:login.asxp?ReturnUrl=admin/index.asp(其實就是
我們所請求的頁面),如果我們在login.asxp通過了驗證,那麼,頁面會自動跳轉到那個ReturnUrl.

看看login.axp:

<asp:textbox id=textname runat=server/>帳號
<asp:textpassword id=textpassword runat=server>密碼
<asp:checkbox id=mycheckbox runat=server/>是否記住密碼,永久登陸
<asp:button runat=server onclick=btnloginclick text=登陸/>

處理事件1(當用戶點擊登陸按鈕時候)

void btnloginclick(Object sender,EventArgs e)
{
 if(用戶通過驗證)//這一點可以在bin目錄放置自己的dll文件來驗證用戶,返回一個bool.
 {
 FormsAuthentication.RedirectFromLoginPage(UserName.Text, mycheckbox.Checked);
 }
}

1,FormsAuthentication.RedirectFromLoginPage(UserName.Text, mycheckbox.Checked);的作用:
->設置一個驗證Cookie,說明用戶已經通過驗證.
->返回剛纔您所請求的頁面(Admin/index.aspx);
2,這句話相當於這兩句:
FormsAuthentication.SetAuthCookie(UserName.Text,mycheckbox.Checked);
Response.Redirect(FormsAuthentication.GetRedirectUrl(UserName.Text,mycheckbox.Checked);
3,如果mycheckboxt控件已經選擇,則,寫入cookie,保存50年,當然,我們可以更改這個時間:
處理事件1(當用戶點擊登陸按鈕時候)

void btnloginclick(Object sender,EventArgs e)
{
 if(用戶通過驗證)//這一點可以在bin目錄放置自己的dll文件來驗證用戶,返回一個bool.
 {
 HttpCookie authenticationCookie=FormsAuthentication.GetAuthcookie(UserName.Text,mycheckbox.Checked);
 authenticationCookie.Expires=DateTime.Now.AddDays(3);//3天
 Response.Cookies.Add(authenticationCookie);
 
 Response.Redirect(FormsAuthentication.GetRedirectUrl(UserName.Text,mycheckbox.Checked);
}

4,這裏有個bug,我不知道爲什麼會這樣,我們這樣:
處理事件1(當用戶點擊登陸按鈕時候)

void btnloginclick(Object sender,EventArgs e)
{
 if(用戶通過驗證)//這一點可以在bin目錄放置自己的dll文件來驗證用戶,返回一個bool.
 {
 FormsAuthentication.RedirectFromLoginPage(UserName.Text, mycheckbox.Checked);
 Response.Redirect("http://www.QuickResponser.com");
 }
}

會怎樣呢?按理說應該執行FormsAuthentication.RedirectFromLoginPage(UserName.Text, mycheckbox.Checked);
然後跳轉到請求的頁面admin/index.aspx.
可是,在實際試驗過程中,發現頁面執行了Response.Redirect("http://www.QuickResponser.com");
5,我們的鏈接不要涉及到直接連接到login.aspx,爲什麼?假設我們直接登陸login.asxp,那麼這個URL就沒有參數ReturnUrl,但是,默認是
Default.aspx(或者index.axp....),當管理員通過驗證時候,頁面不是直接跳轉到根目錄的默認頁面index.aspx.
(如果直接連接的話,也是可以的,利用上面的bug解決)

註銷驗證:
用FormsAuthentication.SignOut();

其實,上述方案並不是很安全的解決方案.只是很實用,簡單,又比較安全的驗證解決方案.