程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> .NET網頁編程 >> ASP.NET >> 關於ASP.NET >> ASP.NET安全問題--Forms驗證的具體介紹(上篇)

ASP.NET安全問題--Forms驗證的具體介紹(上篇)

編輯:關於ASP.NET

前言:在ASP.NET中,常用的就是Forms驗證,最重要的原因就是靈活。因為Forms驗證細細的談起來也確實不少,而且我也不想草草的說完了事,那對大家和自己都不負責任的。

本篇的話題如下:

Forms驗證的工作原理

Forms驗證中的API

Forms驗證的工作原理

我們知道,Forms驗證主要是基於cookie的,說白一點就是:把用戶信息保存在cookie中,然後發送到客戶端;再就是解析客戶端的發送了的cookie信息,進行解析,然後進行驗證。關於cookieless的工作原理和方法,我這裡不贅述,大家可以參看我的另外的一片文章:淺談ASP.NET內部機制(一)。

當匿名用戶請求一個需要驗證後才能訪問的資源和頁面的時候,那麼如果采用了Forms驗證,那麼URL授權模塊就會把用戶重定向到登錄頁面。而之前請求的URL就會被保存起來,等到用戶正確的登錄後,就再次轉向之前要請求的頁面。我想這點,大家應該都用過。

下面我們就看看登錄的時候發生了什麼,看看登錄的具體的流程?也請大家注意我使用的一些術語,因為這些術語再Forms中都有特定的對象,大家之後就可以看到的,很重要。

1.再浏覽器中有個登錄窗體,要輸入用戶名和密碼等憑證,通過提交給服務器的ASP.NET網站來審核,檢查憑證是否正確。

2.如果憑證正確,那麼就會再服務器端就會創建一個"身份驗證票據"。身份驗證票據中含有了經過加密的用戶信息。

3.這個票據再服務器端被寫入cookie中,然後發送到客戶端。

4.然後用戶就被重定向到他們最初請求的URL中。

注:大家可能會有疑問:最初請求的URL到底保存在哪裡?不要擔心,現在只要明白上面的流程就OK。

5.上面第4步就是要轉向最初請求的URL,假設最初的請求頁面是Default.aspx,那麼現在就是從登錄的頁面Login.aspx轉向到Default.aspx 頁面,此時因為身份驗證的票據cookie已經存在於客戶端的浏覽器中了,此時的轉向Default.aspx頁面時,實際是再次向服務器端發起了請求,所以正如我們之前所談到的:每個請求都要從ASP.NET管道中一級級的向後傳,要經歷ASP.NET的的生命周期:Application_BeginRequest,Application_AuthenticateRequest.....。(希望大家明白)

但是這次的請求就和第一次我們發起的請求步同了,為什麼?

第一次我們請求Default.aspx頁面的時候,我們根本就沒有提供任何的表明我們身份的票據,但是這次我們已經登錄了,而且我們的浏覽器中已經有了我們的身份驗證的票據的cookie,此時在Application_AuthenticateRequest事件中,Forms驗證模塊就獲取表明我們身份cookie,然後就利用cookie中信息填充Context.User。

驗證模塊處理完之後就是授權模塊起作用了。其實URL授權模塊就會利用我們之前填充在Context.User中的信息來驗證用戶是否被批准訪問所請求的資源或者頁面。

Forms驗證中的API

實現Forms身份驗證之前,我們看看組成Forms驗證的API以及相關的類:

FormsAuthenticationModule:對每個請求進行驗證的HTTP模塊

FormsAuthentication:包含在Forms驗證中我們常用的方法和屬性(很重要的)

FormsIdentity:Forms驗證標識。

FormsAuthenticationTicket:身份驗證的票據,對用戶的信息進行加密後的產物,我們一般把它寫如cookie中,之前我們談過了的。

上面的類在System.Web.Security下。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved