淺談登錄

在這裏插入圖片描述

1. 登錄

會話
在計算機科學領域來說,尤其是在網絡領域,會話(session,Microsoft Windows 中文版譯作工作階段)是一種持久網絡協議,在用戶(或用戶代理)端和服務器端之間創建關聯,從而起到交換數據包的作用機制,session在網絡協議(例如telnet或FTP)中是非常重要的部分。
在不包含會話層(例如UDP)或者是無法長時間駐留會話層(例如HTTP)的傳輸協議中,會話的維持需要依靠在傳輸數據中的高級別程序。例如,在瀏覽器和遠程主機之間的HTTP傳輸中,HTTP cookie就會被用來包含一些相關的信息,例如session ID,參數和權限信息等。

上述會話的解釋來自維基百科,我來談談我對會話的理解,首先,是網站證明用戶屬於自己網站的註冊用戶,並且已經完成驗證的證明,這個證明包括:

  1. 用戶信息
  2. 有效時間

在以前我自己寫網站代碼的時候,我其實不是很理解登錄之後會有什麼變化,就是我在網站輸入了我的賬號密碼後,這個網站會有什麼變化,在以前的文章上,我實現過登錄註冊的功能,但是一直不是很理解,現在我理解了,其實就是爲了讓網站統一認識你,認識已經登錄過的你。
舉個例子,現在的瀏覽器都支持標籤頁,也就是同一個瀏覽器可以打開不同的網址,那麼當我打開同屬於一個網站的兩個網頁的時候:
在這裏插入圖片描述
在這裏插入圖片描述
應該是登陸的,也就是意味着,這裏倆頁面要共享一個參數。

  • 假設只使用數據庫

假設只使用數據庫來保存登陸的信息,有這樣一個表,如果有人登陸了賬號,就向這個數據庫插入一條數據,另一個頁面在訪問後端的時候,查到了這個表的這一條數據,就發現登陸了,就返回登錄的信息,這樣說來,貌似沒有什麼不妥。
但是承擔登錄信息的壓力就全都靠服務器數據庫來保持,壓力會有點不均衡。
那有沒有一種方式,證明你登錄過,可以在兩個頁面之間共享就可以了。這就是Session的出現。

  • 如何驗證登錄

我還記得以前用Java寫代碼的時候,直接用

select * from user where account='accountStr' AND password='passwordStr'

但是這樣寫的問題是,如果有人使用

1 OR 1

惡意的登錄,是可以登錄的,不相信的親們可以試試。
所以驗證密碼的時候,先查詢出密碼,再判斷密碼是否一致,這樣那個"1 OR 1"就無效了,當然這是針對以前的爛代碼說的。

2. 會話 session

其實沒那麼神祕,就好像我們平時要組織一場會議,總要有會議的時間、地點、內容、主持人這幾個因素。

  • Session保存在服務端
    也就是不在我們每個人使用的瀏覽器那兒,而是你訪問的網站公司的服務器那裏。

這也就是我們很平常的記錄登錄的方式,當服務器驗證完之後,我們給客戶端返回登錄的用戶名,用戶ID,於是我們的網站上就會顯示我的登錄名,當我點擊個人中心時,通過用戶ID訪問數據庫,返回個人信息,就會顯示我們的個人信息具體內容。
服務器會給這個session加上一個時間,到期後服務器會銷燬這個session,當我們再次點擊個人中心的時候,或者刷新頁面的時候,發現這個session不存在了,於是就返回登錄過期的信息,需要用戶重新登錄。

3. Cookie

其實就是爲了區分session,並方便session的一種方式,比如你前一天登錄過了,第二天想登錄的時候,我不想再次輸入賬號密碼了,於是瀏覽器可以查找cookie順便幫你填了。

  • Cookie存在客戶端

4. Token

就是令牌,主要是爲了登錄之後的事情服務,就好像參加一場會議,你會攜帶你的工作牌一樣,當門衛檢查工作牌的時候,需要檢測
a)你是不是參加這次會議的人(登錄名密碼是否匹配在數據庫)
b)是否在規定時間內參加(令牌是否過期)
如果你隨便拿了一張紙,那麼上述兩條就都不用檢測,直接拒你在門外就好了。

  • JWT
    JSON Web Tokens 又稱 JWT。其實只是加密後的,已經被驗證過的令牌(一串字符串)
    可以通過引入JAR包來使用(以下爲maven管理)
<dependency>
    <groupId>com.auth0</groupId>
    <artifactId>java-jwt</artifactId>
    <version>3.4.0</version>
</dependency>

使用這種技術確實可以方便登錄,而且可以用於驗證權限,用於控制會話,但是也存在風險,例如:

  1. 無法單方面銷燬,因爲我們的代碼通常都是講token存在 Local Storage 當中。
  2. 安全泄漏,雖然token會過期,但是過期的了token仍然存在,而且這個token可能是admin權限

token自身存在一個時效,到期後會自動過期,你在訪問都端的時候,會自動出現過期,過期後,客戶端的代碼就會判斷這個token無效,這時客戶端的前端代碼就可以將過期的token清除

getAuthList() {
      axios.get('/apiUrl/').then(this.handleAPISucc)
        .catch(function() {
          window.sessionStorage.clear()
        })

上述代碼就是通過axios的異常來判斷是否過期,或者無效的情況,直接清除session即可。

總結

我以前只會使用session,現在嘗試了token以後,發現token的使用感覺上很高大上,所以正在嘗試,目前還沒有特別深刻的業務需要,還需要後續完成各類開發,總結經驗。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章