Asp.net 中的web.config檔案[網上收集]

來源:互聯網
上載者:User

  2004.10.17發表於blog.csdn.net/zxub

  在學習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();

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

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.