1. 程式人生 > >ASP.net的身份驗證方式有哪些?分別是什麼原理?

ASP.net的身份驗證方式有哪些?分別是什麼原理?

Asp.net的身份驗證有有三種,分別是"Windows | Forms | Passport",其中又以Forms驗證用的最多,也最靈活。
Forms 驗證方式對基於使用者的驗證授權提供了很好的支援,可以通過一個登入頁面驗證使用者的身份,將此使用者的身份發回到客戶端的Cookie,之後此使用者再訪問這個 web應用就會連同這個身份Cookie一起傳送到服務端。服務端上的授權設定就可以根據不同目錄對不同使用者的訪問授權進行控制了。

問題來了,在實際是用中我們往往需要的是基於角色,或者說基於使用者組的驗證和授權。對一個網站來說,一般的驗證授權的模式應該是這樣的:根據實際需求把使用者分成不同的身份,就是角色,或者說是使用者組,驗證過程不但要驗證這個使用者本身的身份,還要驗證它是屬於哪個角色的。而訪問授權是根據角色來設定的,某些角色可以訪問哪些資源,不可以訪問哪些資源等等。要是基於使用者來授權訪問將會是個很不實際的做法,使用者有很多,還可能隨時的增減,不可能在配置檔案中隨時的為不斷增加的新使用者去增加訪問授權的。

下面大概的看一下Forms的過程。

Forms身份驗證基本原理:

一 身份驗證

要採用Forms身份驗證,先要在應用程式根目錄中的Web.config中做相應的設定:

<authentication mode="forms"> 
    <forms name=".ASPXAUTH " slidingExpiration="true" loginUrl="/login.aspx" timeout="30" path= "/" domain=".abc.com">
    </forms> 
</authentication>

 其中<authentication mode= "forms"> 表示本應用程式採用Forms驗證方式。
1. <forms>標籤中的name表示指定要用於身份驗證的 HTTP Cookie。預設情況下,name 的值是 .ASPXAUTH。採用此種方式驗證使用者後,以此使用者的資訊建立一個FormsAuthenticationTicket型別的身份驗證票,再加密序列化為一個字串,最後將這個字串寫到客戶端的name指定名字的Cookie中.一旦這個Cookie寫到客戶端後,此使用者再次訪問這個web應用時會將連同Cookie一起傳送到服務端,服務端將會知道此使用者是已經驗證過的.

再看一下身份驗證票都包含哪些資訊呢,我們看一下FormsAuthenticationTicket類:
CookiePath: 返回發出 Cookie 的路徑。注意,窗體的路徑設定為 /。由於窗體區分大小寫,這是為了防止站點中的 URL 的大小寫不一致而採取的一種保護措施。這在重新整理 Cookie 時使用
Expiration: 獲取 Cookie 過期的日期/時間。
IsPersistent: 如果已發出持久的 Cookie,則返回 true。否則,身份驗證 Cookie 將限制在瀏覽器生命週期範圍內。
IssueDate: 獲取最初發出 Cookie 的日期/時間。
Name: 獲取與身份驗證 Cookie 關聯的使用者名稱。
UserData

 :獲取儲存在 Cookie 中的應用程式定義字串。
Version: 返回位元組版本號供將來使用。

2. <forms>標籤中的loginUrl指定如果沒有找到任何有效的身份驗證 Cookie,為登入將請求重定向到的 URL。預設值為 default.aspx。loginUrl指定的頁面就是用來驗證使用者身份的,一般此頁面提供使用者輸入使用者名稱和密碼,使用者提交後由程式來根據自己的需要來驗證使用者的合法性(大多情況是將使用者輸入資訊同資料庫中的使用者表進行比較),如果驗證使用者有效,則生成同此使用者對應的身份驗證票,寫到客戶端的 Cookie,最後將瀏覽器重定向到使用者初試請求的頁面.一般是用FormsAuthentication.RedirectFromLoginPage 方法來完成生成身份驗證票,寫回客戶端,瀏覽器重定向等一系列的動作.

public static void RedirectFromLoginPage( string userName, bool createPersistentCookie, string strCookiePath );

其中:
userName: 就是此使用者的標示,用來標誌此使用者的唯一標示,不一定要對映到使用者賬戶名稱.
createPersistentCookie: 標示是否發出持久的 Cookie。
若不是持久Cookie,Cookie的有效期Expiration屬性有當前時間加上web.config中timeout的時間,每次請求頁面時,在驗證身份過程中,會判斷是否過了有效期的一半,要是的話更新一次cookie的有效期;若是持久cookie,Expiration屬性無意義,這時身份驗證票的有效期有cookie的Expires決定,RedirectFromLoginPage方法給Expires屬性設定的是50年有效期。
strCookiePath: 標示將生成的Cookie的寫到客戶端的路徑,身份驗證票中儲存這個路徑是在重新整理身份驗證票Cookie時使用(這也是生成Cookie的Path),若沒有strCookiePath 引數,則使用web.config中 path屬性的設定。

這裡可以看到,此方法引數只有三個,而身份驗證票的屬性有七個,不足的四個引數是這麼來的:
IssueDate: Cookie發出時間由當前時間得出,
Expiration:過期時間由當前時間和下面要說的<forms>標籤中timeout引數算出。此引數對非永續性cookie有意義。
UserData: 這個屬性可以用應用程式寫入一些使用者定義的資料,此方法沒有用到這個屬性,只是簡單的將此屬性置為空字串,請注意此屬性,在後面我們將要使用到這個屬性。
Version: 版本號由系統自動提供.

RedirectFromLoginPage 方法生成生成身份驗證票後,會呼叫FormsAuthentication.Encrypt 方法,將身份驗證票加密為字串,這個字串將會是以.ASPXAUTH為名字的一個Cookie的值。這個Cookie的其它屬性的生成:Domain,Path屬性為確省值,Expires視createPersistentCookie引數而定,若是持久 cookie,Expires設為50年以後過期;若是非持久cookie,Expires屬性不設定。
生成身份驗證Cookie後,將此Cookie加入到Response.Cookies中,等待發送到客戶端。
最後RedirectFromLoginPage方法呼叫FormsAuthentication.GetRedirectUrl 方法獲取到使用者原先請求的頁面,重定向到這個頁面。

3. <forms>標籤中的timeout和path,是提供了身份驗證票寫入到Cookie過期時間和預設路徑。

以上就是基於Forms身份驗證的過程,它完成了對使用者身份的確認。下面介紹基於Forms身份驗證的訪問授權。

二 訪問授權

驗證了身份,是要使用這個身份,根據不同的身份我們可以進行不同的操作,處理,最常見的就是對不同的身份進行不同的授權,Forms驗證就提供這樣的功能。Forms授權是基於目錄的,可以針對某個目錄來設定訪問許可權,比如,這些使用者可以訪問這個目錄,那些使用者不能訪問這個目錄。
同樣,授權設定是在你要控制的那個目錄下的web.config檔案中來設定:

<authorization>
    <allow users="comma-separated list of users"
        roles="comma-separated list of roles"
        verbs="comma-separated list of verbs" />
     <deny users="comma-separated list of users"
        roles="comma-separated list of roles"
        verbs="comma-separated list of verbs" />
</authorization>

<allow>標籤表示允許訪問,其中的屬性
1. users:一個逗號分隔的使用者名稱列表,這些使用者名稱已被授予對資源的訪問許可權。問號 (?) 允許匿名使用者;星號 (*) 允許所有使用者。
2. roles:一個逗號分隔的角色列表,這些角色已被授予對資源的訪問許可權。
3. verbs:一個逗號分隔的 HTTP 傳輸方法列表,這些 HTTP 傳輸方法已被授予對資源的訪問許可權。註冊到 ASP.NET 的謂詞為 GET、HEAD、POST 和 DEBUG。

<deny>標籤表示不允許訪問。其中的屬性同上面的。

在執行時,授權模組迭代通過 <allow> 和 <deny> 標記,直到它找到適合特定使用者的第一個訪問規則。然後,它根據找到的第一項訪問規則是 <allow> 還是 <deny> 規則來允許或拒絕對 URL 資源的訪問。Machine.config 檔案中的預設身份驗證規則是 <allow users="*"/>,因此除非另行配置,否則在預設情況下會允許訪問。

那麼這些user 和roles又是如何得到的呢?下面看一下授權的詳細過程:

1. 一旦一個使用者訪問這個網站,就行登入確認了身份,身份驗證票的cookie也寫到了客戶端。之後,這個使用者再次申請這個web的頁面,身份驗證票的 cookie就會發送到服務端。在服務端,asp.net為每一個http請求都分配一個HttpApplication物件來處理這個請求,在 HttpApplication.AuthenticateRequest事件後,安全模組已建立使用者標識,就是此使用者的身份在web端已經建立起來,這個身份完全是由客戶端傳送回來的身份驗證票的cookie建立的。
2. 使用者身份在HttpContext.User 屬性中,在頁面中可以通過Page.Context 來獲取同這個頁面相關的HttpContext物件。對於Forms驗證,HttpContext.User屬性是一個GenericPrincipal 型別的物件,GenericPrincipal只有一個公開的屬性Identity,有個私有的m_role屬性,是string[]型別,存放此使用者是屬於哪些role的陣列,還有一個公開的方法IsInRole(string role),來判斷此使用者是否屬於某個角色。
由於身份驗證票的cookie中根本沒有提供role這個屬性,就是說Forms身份驗證票沒有提供此使用者的role資訊,所以,對於Forms驗證,在服務端得到的GenericPrincipal 使用者物件的m_role屬性永遠是空的。
3. GenericPrincipal. Identity 屬性是一個FormsIdentity型別的物件,這個物件有個Name屬性,就是此使用者的標示,訪問授權就是將此屬性做為user來進行授權驗證的。 FormsIdentity還有一個屬性,就是Ticket屬性,此屬性是身份驗證票FormsAuthenticationTicket型別,就是之前伺服器寫到客戶端的身份驗證票。
伺服器在獲取到身份驗證票FormsAuthenticationTicket物件後,檢視這個身份驗證票是不是非持久的身份驗證,是的話要根據web.config中timeout屬性設定的有效期來更新這個身份驗證票的cookie(為避免危及效能,在經過了超過一半的指定時間後更新該 Cookie。這可能導致精確性上的損失。永續性 Cookie 不超時。)
4. 在HttpApplication.ResolveRequestCache事件之前,asp.net開始取得使用者請求的頁面,建立 HttpHandler控制點。這就意味著,在HttpApplication.ResolveRequestCache事件要對使用者訪問許可權就行驗證,看此使用者或角色是否有許可權訪問這個頁面,之後在這個請求的生命週期內再改變此使用者的身份或角色就沒有意義了。

以上是Forms驗證的全過程,可以看出,這個Forms驗證是基於使用者的,沒有為角色的驗證提供直接支援。身份驗證票 FormsAuthenticationTicket 中的Name屬性是使用者標示,其實還有一個屬性UserData,這個屬性可以由應用程式來寫入自定義的一些資料,我們可以利用這個欄位來存放role的資訊,從而達到基於角色驗證的目的。

一 身份驗證

在web.config的<authentication>的設定還是一樣:/login.aspx 驗證使用者合法性頁面中,在驗證了使用者的合法性後,還要有個取得此使用者屬於哪些role的過程,這個看各個應用的本身如何設計的了,一般是在資料庫中會有個 use_role表,可以從資料庫中獲得此使用者屬於哪些role,在此不深究如何去獲取使用者對應的role,最後肯定能夠獲得的此使用者對應的所有的 role用逗號分割的一個字串。
在上面的非基於角色的方法中,我們用了 FormsAuthentication.RedirectFromLoginPage 方法來完成生成身份驗證票,寫回客戶端,瀏覽器重定向等一系列的動作。這個方法會用一些確省的設定來完成一系列的動作,在基於角色的驗證中我們不能用這一個方法來實現,要分步的做,以便將一些定製的設定加進來:

<authentication mode="forms"> 
    <forms name=".ASPXAUTH "domain=".abc.com" loginUrl="/login.aspx" timeout="30" path= "/">
    </forms> 
</authentication>

 1. 首先要根據使用者標示,和使用者屬於的角色的字串來建立身份驗證票

public FormsAuthenticationTicket(
int version, //設為1
string name, //使用者標示
DateTime issueDate, //Cookie 的發出時間, 設定為 DateTime.Now 
DateTime expiration, //過期時間
bool isPersistent, //是否永續性(根據需要設定,若是設定為永續性,(在發出cookie時,cookie的Expires設定一定要設定)
string userData, //這裡用上面準備好的用逗號分割的role字串
string cookiePath // 設為"/",這要同發出cookie的路徑一致,因為重新整理cookie要用這個路徑
);

FormsAuthenticationTicket Ticket = new FormsAuthenticationTicket (1,"kent",DateTime.Now, DateTime.Now.AddMinutes(30), false,UserRoles,"/") ;

2. 生成身份驗證票的Cookie
2.1 將身份驗證票加密序列化成一個字串

string HashTicket = FormsAuthentication.Encrypt (Ticket) ;

2.2 生成cookie

HttpCookie UserCookie = new HttpCookie(FormsAuthentication.FormsCookieName, HashTicket) ;

FormsAuthentication.FormsCookieName 是用來獲取web.config中設定的身份驗證cookie的名字,預設為" .ASPXAUTH".
若身份驗證票中的isPersistent屬性設定為持久類,則這個cookie的Expires屬性一定要設定,這樣這個cookie才會被做為持久cookie儲存到客戶端的cookie檔案中.
3. 將身份驗證票Cookie輸出到客戶端

Response.Cookies.Add(UserCookie) 

通過Response.Cookies.Add(UserCookie) 將身份驗證票Cookie附加到輸出的cookie集合中,傳送到客戶端.
4. 重定向到使用者申請的初試頁面.

驗證部分程式碼(這部分程式碼是在login.aspx頁面上點選了登入按鈕事件處理程式碼):

二 基於角色訪問授權

private void Buttonlogin_Click(object sender, System.EventArgs e)
{
     string user = TextBoxUser.Text; //讀取使用者名稱
     string password = TextBoxPassword.Text; //讀取密碼
     if(Confirm(user,password) == true) //confirm方法用來驗證使用者合法性的
    {
         string userRoles = UserToRole(user); //呼叫UserToRole方法來獲取role字串
         FormsAuthenticationTicket Ticket = new FormsAuthenticationTicket (1,user,DateTime.Now,          DateTime.Now.AddMinutes(30), false,userRoles,"/") ; //建立身份驗證票物件
         string HashTicket = FormsAuthentication.Encrypt (Ticket) ; //加密序列化驗證票為字串
         HttpCookie UserCookie = new HttpCookie(FormsAuthentication.FormsCookieName, HashTicket) ; 
//生成Cookie
          FormsAuthentication.SetAuthCookie(user, false);   //輸出Cookie
         Response.Redirect(FormsAuthentication.GetRedirectUrl(user, false));  // 重定向到使用者申請的初始頁面
     }
    else
    {
        // 使用者身份未被確認時的程式碼
    }
}
//此方法用來驗證使用者合法性的
private bool Confirm(string user,string password)
{
    //相應的程式碼
}
//此方法用來獲得的使用者對應的所有的role用逗號分割的一個字串
private string UserToRole(string user)
{
    //相應的程式碼
}

 這裡我們要做的是,將客戶端儲存的身份驗證票中UserData中儲存的表示角色的資訊恢復到在服務端表示使用者身份的GenericPrincipal物件中(記住,原來的驗證過程中, GenericPrincipal物件只包含了使用者資訊,沒有包含role資訊)
一個Http請求的過程中,HttpApplication.AuthenticateRequest事件表示安全模組已建立使用者標識,就是此使用者的身份在web端已經建立起來, 在這個事件之後我們就可以獲取使用者身份資訊了.
在 HttpApplication.ResolveRequestCache事件之前,asp.net開始取得使用者請求的頁面,建立HttpHandler 控制點,這時就已經要驗證使用者的許可權了,所以恢復使用者角色的工作只能在HttpApplication.AuthenticateRequest事件和 HttpApplication.ResolveRequestCache事件之間的過程中做.
我們選擇Application_AuthorizeRequest事件中做這個工作,可以在global.asax檔案中處理HttpApplication的所有的事件,程式碼如下:

protected void Application_AuthorizeRequest(object sender, System.EventArgs e)
{
    HttpApplication App = (HttpApplication) sender;
     HttpContext Ctx = App.Context ; //獲取本次Http請求相關的HttpContext物件
    if (Ctx.Request.IsAuthenticated == true) //驗證過的使用者才進行role的處理
    {
        FormsIdentity Id = (FormsIdentity)Ctx.User.Identity ;
        FormsAuthenticationTicket Ticket = Id.Ticket ; //取得身份驗證票
        string[] Roles = Ticket.UserData.Split (',') ; //將身份驗證票中的role資料轉成字串陣列
        Ctx.User = new GenericPrincipal (Id, Roles) ; //將原有的Identity加上角色資訊新建一個GenericPrincipal表示當前使用者,這樣當前使用者就擁有了role資訊
    }
}

訪問者同時具有了user和role資訊,就可以據此在web.config中用role來控制使用者的訪問許可權了.

1、基於Windows的身份驗證將<system.web>元素下的<authentication> 設定為 Windows;基於Forms的身份驗證將<system.web>元素下的<authentication> 設定為 Forms。

2、基於Forms的身份驗證時,設定<system.web>元素下的<authentication> 元素的 <forms> 子元素,示例如下,僅為說明

    <authentication mode="Forms">

      <forms name=".VS2005_Form" loginUrl="~/Security/Login.aspx" defaultUrl="~/Default.aspx"
          protection="All" timeout="30" path="/" requireSSL="false"
          slidingExpiration="true" enableCrossAppRedirects="false"
          cookieless="UseDeviceProfile">
      </forms>

    </authentication>


<forms>元素的屬性說明如下
1) cookieless - 身份驗證可以將 Forms 身份驗證票儲存在 Cookie 中也可以以無 Cookie 的表示形式儲存在 URL 上。有效值如下:
  ·UseDeviceProfile - 預設值表示 ASP.NET 根據預先計算得到的瀏覽器配置檔案來確定儲存票證的位置。
  ·AutoDetect - 選項使 ASP.NET 動態確定瀏覽器是否支援 Cookie。
  ·UseUri - 強制實施無 Cookie 票證 
  ·UseCookies - 強制實施有 Cookie 票證。
2) defaultUrl - 指定在成功登入後,請求將重定向到的預設 URL。
3) domain - 指定包含 Forms 身份驗證票的 HttpCookie 的 Domain 屬性的值。顯式設定此屬性可使應用程式共享同一個 Cookie,前提是這些應用程式共享某個 DNS 名稱空間的一個公共部分(例如,如果 domain 屬性設定為“cnblogs.com”,則 webabcd.cnblogs.com 和 dudu.cnblogs.com可以共享一個 Cookie)。
4) enableCrossAppRedirects - Forms 身份驗證允許以查詢字串變數或窗體 POST 變數的形式在應用程式之間傳遞 Forms身份驗證票。將此屬性設定為 true 可使 FormsAuthenticationModule 能夠從查詢字串或窗體 POST 變數提取票證。
5) loginUrl - 指定未經身份驗證的使用者的請求將被重定向到的 URL。該 URL 可以在同一臺計算機上或在遠端計算機上。如果是在遠端計算機上,則兩臺計算機上 machineKey 配置元素中的 decryptionkey 和 validationKey 屬性都需要使用相同的值。
6) name - 用於身份驗證的 HTTP Cookie 的名稱。注意,如果多個應用程式需要在一臺計算機上使用基於窗體的身份驗證服務,並且每個應用程式都希望由應用程式隔離 Forms 身份驗證 Cookie,則每個應用程式都應配置一個唯一的 Cookie 值。為避免在 URL 中產生依賴項,在設定身份驗證 Cookie 時,ASP.NET 還使用“/”作為 Path 值,以便將這些 Cookie 傳送回站點上的每個應用程式。
7) path - 用於發出的 Cookie 的路徑。預設值為“/”,以避免路徑中大小寫不匹配的造成的困難,因為在返回 Cookie 時,瀏覽器是嚴格區分大小寫的。共享伺服器環境中的應用程式應使用此指令來維護專用 Cookie。(它們還可以使用 API 在執行時指定路徑來發出 Cookie。) 
8) protection - 用於保護 Cookie 資料的方法。有效值如下: 
  ·All - 同時使用資料驗證和加密來保護 Cookie。所配置的資料驗證演算法是基於 <machinekey> 元素的。如果金鑰足夠長(48 個字元),預設情況下將使用 AES 進行加密。All 是預設(和建議)值。 
  ·None - 用於僅將 Cookie 用於個性化設定並且安全性要求不高的站點。加密和驗證都可以被禁用。儘管以此方式使用 Cookie 需謹慎,但對於使用 .NET Framework 實現個性化設定的任何方法,此設定提供了最佳效能。 
  ·Encryption - 使用 AES、TripleDES 或 DES 加密 Cookie,但不對 Cookie 進行資料驗證。這類 Cookie 容易受到精心選擇的純文字的攻擊。
  ·Validation - 不加密 Cookie 的內容,但驗證 Cookie 資料在傳輸過程中是否未被更改。若要建立 Cookie,驗證金鑰在緩衝區中與 Cookie 資料連線,並且計算出 MAC 並將其追加到輸出的 Cookie。 
9) requireSSL - 如果設定為 true,則 Forms 身份驗證會設定 Forms 身份驗證 Cookie 的安全位。相容的瀏覽器只將 Cookie 通過 SSL 連線傳送回 ASP.NET。注意,如果使用無 Cookie Forms 身份驗證,則此設定無效。 
10) slidingExpiration - 如果設定為 true,則 Forms 身份驗證將定期更新 Forms 身份驗證票的生存期。無論票證是包含在 Cookie 中,還是以無 Cookie 的格式包含在 URL 中,都會進行此操作。 
11) timeout - 時間量(以整數分鐘為單位),經過該時間量之後,Cookie 則會過期。預設值是 30。超時屬性是一個可調值,從收到上次請求的時間開始計算,它將在 n 分鐘後過期。為了避免對效能產生負面影響,也為了避免那些打開了 Cookie 警告的應用程式產生多個瀏覽器警告,Cookie 在超時時間過半時更新。(這意味著在某些情況下可能會出現精度損失。)(注意:createPersistentCookie為true的話,則該屬性失效,過期時間將為50年)

3、授權使用者和角色設定<system.web>元素下的<authorization>元素,示例如下,僅為說明

<authorization>
    <allow VERB="POST" users="[email protected]" />
    <allow roles="admin" />
    <deny users="*" />
    <allow VERB="GET" users="abc,xyz" />
    <deny users="?" />
</authorization>


注:可以把授權使用者和角色設定的配置寫在某個資料夾內,則所做的配置只作用於該資料夾內,自動繼承外面的配置。
allow - 允許
deny - 拒絕
users - 使用者(多使用者用逗號隔開)
roles - 角色(多角色用逗號隔開)
verb - 指定http方法,post或get
* - 所有使用者
? - 匿名(未經過身份驗證的)使用者

4、分路徑設定授權使用者和角色設定,示例如下,僅為說明

    <location path="folder">
        <system.web>
            <authorization>
                <deny users="?"/>
                <allow users="*"/>
            </authorization>
        </system.web>
    </location>
    
    <location path="abc.aspx">
        <system.web>
            <authorization>
                <allow roles="Administrators" />
                <deny users="*"/>
            </authorization>
        </system.web>
    </location>


<location>元素的path屬性可以是資料夾也可以是某一檔案

5、<membership>元素設定,示例如下,僅為說明

    <membership defaultProvider="SqlMembershipProvider">
      <providers>
        <clear/>
        <add name="SqlMembershipProvider"
             type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
             connectionStringName="SqlConnectionString"
             enablePasswordRetrieval="false"
             enablePasswordReset="true"
             requiresQuestionAndAnswer="false"
             applicationName="/"
             requiresUniqueEmail="false"
             passwordFormat="Hashed"
             maxInvalidPasswordAttempts="3"
             minRequiredPasswordLength="3"
             minRequiredNonalphanumericCharacters="0"
             passwordAttemptWindow="10"
             passwordStrengthRegularExpression="" />
      </providers>
    </membership>


enablePasswordRetrieval - 是否可以檢索使用者密碼(總是false)
enablePasswordReset - 是否允許使用者重置其密碼
requiresQuestionAndAnswer - 是否要求在建立使用者時提供密碼提示問題和答案
applicationName - 自定義成員資格提供程式的應用程式的名稱
requiresUniqueEmail - 電子郵件地址是否必須是唯一的
passwordFormat - 儲存的密碼的格式
maxInvalidPasswordAttempts - 指定允許的無效密碼或無效密碼提示問題答案嘗試的次數。當無效嘗試的次數達到配置的值時,將鎖定該成員資格使用者
minRequiredPasswordLength - 密碼所要求的最小長度
minRequiredNonalphanumericCharacters - 有效密碼中必須包含的最少特殊字元數
passwordAttemptWindow - 跟蹤失敗的嘗試所用的時間(以分鐘為單位)。每當發生另一次失敗時都將重置視窗。如果達到了允許的無效密碼或密碼提示問題答案的最大嘗試次數,將鎖定成員資格使用者
passwordStrengthRegularExpression - 用於驗證密碼的正則表示式

6、<roleManager>元素設定,示例如下,僅為說明

    <roleManager defaultProvider="SqlRoleProvider"
      enabled="true"
      cacheRolesInCookie="true"
      cookieName=".VS2005_Role"
      cookieTimeout="30"
      cookiePath="/"
      cookieRequireSSL="false"
      cookieSlidingExpiration="true"
      cookieProtection="All">
      <providers>
        <add
          name="SqlRoleProvider"
          type="System.Web.Security.SqlRoleProvider"
          connectionStringName="SqlConnectionString"
          applicationName="/" />
      </providers>
    </roleManager>


各屬性詳細說明參看MSDN,索引處查詢“roleManager 元素”

7、使用加密密碼

<authentication>
    <credentials passwordFormat="SHA1" >
        <user name="Mary" password="94F85995C7492EEC546C321821AA4BECA9A3E2B1"/>
        <user name="John" password="5753A498F025464D72E088A9D5D6E872592D5F91"/>
    </credentials>
</authentication>


使用FormsAuthentication.HashPasswordForStoringInConfigFile(String password, String passwordFormat)生成密碼
Clear - 密碼以明文形式儲存 
SHA1 - 密碼儲存為 SHA1 摘要 
MD5 - 密碼儲存為 MD5 摘要 

8、使用使用者帳戶模擬,在<system.web>元素下加如下元素

<identity impersonate="true" username="" password="" />

相關推薦

.net 身份驗證方式哪些原理

Asp.net的身份驗證有有三種,分別是"Windows | Forms | Passport",其中又以Forms驗證用的最多,也最靈活。 Windows: 使用IIS驗證方式 Forms: 使用

ASP.net身份驗證方式哪些?分別是什麼原理

Asp.net的身份驗證有有三種,分別是"Windows | Forms | Passport",其中又以Forms驗證用的最多,也最靈活。 Forms 驗證方式對基於使用者的驗證授權提供了很好的支援,可以通過一個登入頁面驗證使用者的身份,將此使用者的身份發回到客戶端的C

ASP.NET身份驗證方式

Windows:使用Windows作業系統和NTFS檔案系統驗證,適合公司內部站點使用,不適合大眾商業站點 Forms:利用網頁向客戶端傳送憑證,客戶端再把憑證提交給應用程式進行身份驗證(使用最普遍) passport:一種單點登入標準(微軟提供使用付費國內應用較少) Fe

[本週] 就來說說Asp.net 身份驗證、授權

[本週]如約而至;時間是爭取來的,這回的[本週]是把若干零碎的時間利用起來成文的,完成對Asp.net身份驗證、訪問授權等內容的梳理,可能漏掉的東西會比較多,漏掉的還是希望大家來補充。順便說一下上次[本週]Ajax 那點事 題目我認為很平實很低調了,沒料到還是被批評

ASP.NET身份驗證機制membership入門——配置篇(2)

在所有的基本配置都完畢後,我們還需要配置哪些目錄允許被匿名訪問,哪些是需要使用者登入後允許訪問的頁面。     首先:我們在專案中建立一個admin資料夾,在admin資料夾中新增一個web.config檔案,然後在其中的<system.web>節點下面新增如下程

ASP.NET 身份驗證機制

ASP.NET提供了3種認證方式:windows身份驗證、Forms驗證和Passport驗證。windows身份驗證: IIS根據應用程式的設定執行身份驗證。要使用這種驗證方式,在IIS中必須禁用匿名訪問。Forms驗證:用Cookie來儲存使用者憑證,並將 未經身份驗證的使用者重定向到自定義的登入頁。P

關於ASP.NET MVC 5 的一種簡單的身份驗證方式:FormsAuthentication.Authenticate

在ASP.NET MVC 5中,身份驗證分別有三種方式。分別為使用FormsAuthentication、MemberShip和Identity進行驗證。   (PS:本系列的邏輯程式碼請勿直接用於生產,請自己多加一層抽象後再投入使用)   為了展示這三種方式,我們先新建一個MVC

asp.net中常用的幾種身份驗證方式

前言 在B/S系統開發中,經常需要使用“身份驗證”。因為web應用程式非常特殊,和傳統的C/S程式不同,預設情況下(不採用任何身份驗證方式和許可權控制手段),當你的程式在網際網路/區域網上公開後,任何人都能夠訪問你的web應用程式的資源,這樣很難保障應用程式安全性。通俗

asp.net身份驗證方式

  asp.net提供了3種認證方式:  windows身份驗證, Forms驗證和Passport驗證.windows身份驗證: IIS根據應用程式的設定執行身份驗證.要使用這種驗證方式,在IIS中必須禁用匿名訪問.Forms驗證:用Cookie來儲存使用者憑證,並將未經

註冊驗證流程哪些方式

[TOC] 去年對註冊驗證的流程做了挺多處理,年初聊一聊關於驗證的流程吧,順帶記錄下 ## 簡訊下發 就是傳送簡訊,專業點應該叫做`簡訊下行` 這種驗證方式在國內算是使用最多且最有效的了 ![](https://img2020.cnblogs.com/blog/1158451/202101/115845

對象在類中的存儲方式哪些

執行文件 結構 交換 文件中 用戶 lan 邏輯 長度 由於 對象類型和整型、字符串等類型一樣,也是PHP中的一種數據類型。都是在程序中用於存儲不同類型數據使用的,在程序運行時它的每部分內容都要先加載到內存中再被使用。那麽對象類型的數據在內存中是如何分配的呢?先來了解一下內

PHP網站的主要攻擊方式哪些

bmi 目錄 clu alua http inject fixation insert miss 1. 命令註入(Command Injection) 2. eval 註入(Eval Injection) 3. 客戶端腳本攻擊(Script Insertion)

創建共享文件夾的方式哪些

共享文件夾創建共享文件夾步驟 環境:papapa(192.168.1.1)、hahaha(192.168.1.2)兩臺主機 papapa關閉防火墻 第一步: papapa 開啟共享——網絡-高級共享-勾選上-保存更改 (開啟了功能,並不代表你的文件夾是共享文件夾) 第二步: 創建文件夾

CSS引入的方式哪些? link和@import的區別是?

可維護性 需要 -c 所有 scrip 頁面 sheet 代碼 是個 1.內聯方式 內聯方式指的是直接在 HTML 標簽中的 style 屬性中添加 CSS。 示例: <div style="background: red"></div> 這通常是

EXCHANGE客戶端訪問服務器(CAS)中的身份驗證方式

傳輸 郵箱服務器角色 找到 輸入 驗證 管理器 orm 虛擬 code 在部署完畢exchange後系統會自動建立IIS服務來響應相應的請求。客戶端訪問服務器(以下簡稱CAS)實質上是一臺IIS服務器,在服務器中部署一套名為“Default web site”的站點來完成O

asp.net core驗證碼(非原創,整合網上例子)

返回 cati view 例子 ica ace mem 一個 span 轉載原創)驗證碼參考網址: https://blog.csdn.net/ChaITSimpleLove/article/details/80531791 首先通過Nuget: Install-P

自定義 Asp.Net SessionID 獲取方式

manager esp manage 自定義 virtual col var == quest 新建類 CustomSessionIDManager public class CustomSessionIDManager : SessionIDManager,

電壓可調電源原理是什麼,電壓調節方式哪些

什麼是電壓可調電源?電壓可調電源的原理是什麼?電壓可調電源是在穩壓開關電源的基礎上將電壓展寬,實現輸出電壓大範圍可調(一般可0V~額定值連續調節)的一種電源。主要由電壓基準源、調整管、誤差放大、電壓取樣以及電流取樣組成,電壓可調電源一般是採用改變取樣電路的分壓比例來實現輸出電壓的調節。 電壓可調電源輸出電壓

電壓可調電源原理是什麽,電壓調節方式哪些

藍色 方向 是什麽 技術 ges ron 信號控制 操作 分享圖片 什麽是電壓可調電源?電壓可調電源的原理是什麽?電壓可調電源是在穩壓開關電源的基礎上將電壓展寬,實現輸出電壓大範圍可調(一般可0V~額定值連續調節)的一種電源。主要由電壓基準源、調整管、誤差放大、電壓取樣以及

spark怎麼建立RDD,一個建立RDD的方式哪些它們的區別是什麼!!(Unit2)

spark的程式設計介面包括 1.分割槽資訊,資料集的最小分片     (1)Patitions()用法:   scala> val part=sc.textFile("/user/README.md",6) part: org.apache