2. 程式人生 > >session-cookie 和token登入驗證

session-cookie 和token登入驗證

阿新 • • 發佈：2018-12-03

最近研究了下基於token的身份驗證，並將這種機制整合在個人專案中。現在很多網站的認證方式都從傳統的seesion+cookie轉向token校驗。對比傳統的校驗方式，token確實有更好的擴充套件性與安全性。

傳統的session+cookie身份驗證

由於HTTP是無狀態的，它並不記錄使用者的身份。使用者將賬號與密碼傳送給伺服器後，後臺通過校驗，但是並沒有記錄狀態，於是下一次使用者的請求仍然需要校驗身份。為了解決這一問題，需要在服務端生成一條包含使用者身份的記錄，也就是session，再將這條記錄傳送給使用者並存儲在使用者本地，即cookie。接下來使用者的請求都會帶上這條cookie，若客戶端的cookie與服務端的session能對應上，則說明使用者身份驗證通過。

token身份校驗

流程大致如下：

  1. 第一次請求時，使用者傳送賬號與密碼
  2. 後臺校驗通過，則會生成一個有時效性的token,再將此token傳送給使用者
  3. 使用者獲得token後，將此token儲存在本地，一般儲存在localstorage或cookie
  4. 之後的每次請求都會將此token新增在請求頭裡，所有需要校驗身份的介面都會被校驗token，若token解析後的資料包含使用者身份資訊，則身份驗證通過。

對比傳統的校驗方式，token校驗有如下優勢：

  1. 在基於token的認證，token通過請求頭傳輸，而不是把認證資訊儲存在session或者cookie中。這意味著無狀態。你可以從任意一種可以傳送HTTP請求的終端向伺服器傳送請求。
  2. 可以避免CSRF攻擊
  3. 當在應用中進行 session的讀，寫或者刪除操作時，會有一個檔案操作發生在作業系統的temp 資料夾下，至少在第一次時。假設有多臺伺服器並且 session 在第一臺服務上建立。當你再次傳送請求並且這個請求落在另一臺伺服器上，session 資訊並不存在並且會獲得一個“未認證”的響應。我知道，你可以通過一個粘性 session 解決這個問題。然而，在基於 token 的認證中，這個問題很自然就被解決了。沒有粘性 session 的問題，因為在每個傳送到伺服器的請求中這個請求的 token 都會被攔截。

下面介紹一下利用node+jwt(jwt教程)搭建簡易的token身份校驗

示例

當用戶第一次登入時，提交賬號與密碼至伺服器，伺服器校驗通過，則生成對應的token，程式碼如下：

const fs = require('fs');

const path = require('path');

const jwt = require('jsonwebtoken');

//生成token的方法

function generateToken(data){

  let created = Math.floor(Date.now() / 1000);

  let cert = fs.readFileSync(path.join(__dirname, '../config/pri.pem'));//私鑰

  let token = jwt.sign({

    data,

    exp: created + 3600 * 24

  }, cert, {algorithm: 'RS256'});

  return token;

}

 

//登入介面

router.post('/oa/login', async (ctx, next) => {

  let data = ctx.request.body；

  let {name, password} = data;

  let sql = 'SELECT uid FROM t_user WHERE name=? and password=? and is_delete=0', value = [name, md5(password)];

  await db.query(sql, value).then(res => {

    if (res && res.length > 0) {

      let val = res[0];

      let uid = val['uid'];

      let token = generateToken({uid});

      ctx.body = {

        ...Tips[0], data: {token}

      }

    } else {

      ctx.body = Tips[1006];

    }

  }).catch(e => {

    ctx.body = Tips[1002];

  });

 

});

使用者通過校驗將獲取到的token存放在本地：

?

1

store.set('loginedtoken',token);//store為外掛

之後客戶端請求需要驗證身份的介面，都會將token放在請求頭裡傳遞給服務端：

?

1

2

3

4

5

6

7

8

9

10

11

12

service.interceptors.request.use(config => {

  let params = config.params || {};

  let loginedtoken = store.get('loginedtoken');

  let time = Date.now();

  let {headers} = config;

  headers = {...headers,loginedtoken};

  params = {...params,_:time};

  config = {...config,params,headers};

  return config;

}, error => {

  Promise.reject(error);

})

服務端對所有需要登入的介面均攔截token並校驗合法性。

?

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

function verifyToken(token){

  let cert = fs.readFileSync(path.join(__dirname, '../config/pub.pem'));//公鑰

  try{

    let result = jwt.verify(token, cert, {algorithms: ['RS256']}) || {};

    let {exp = 0} = result,current = Math.floor(Date.now()/1000);

    if(current <= exp){

      res = result.data || {};

    }

  }catch(e){

 

  }

  return res;

 

}

 

app.use(async(ctx, next) => {

  let {url = ''} = ctx;

  if(url.indexOf('/user/') > -1){//需要校驗登入態

    let header = ctx.request.header;

    let {loginedtoken} = header;

    if (loginedtoken) {

      let result = verifyToken(loginedtoken);

      let {uid} = result;

      if(uid){

        ctx.state = {uid};

        await next();

      }else{

        return ctx.body = Tips[1005];

      }

    } else {

      return ctx.body = Tips[1005];

    }

  }else{

    await next();

  }

});

本示例使用的公鑰與私鑰可自己生成，操作如下：

  1. 開啟命令列工具，輸入openssl，開啟openssl;
  2. 生成私鑰：genrsa -out rsa_private_key.pem 2048
  3. 生成公鑰： rsa -in rsa_private_key.pem -pubout -out rsa_public_key.pem

點此檢視node後臺程式碼 
點此檢視前端程式碼

以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支援指令碼之家。

 

文章出處：https://www.jb51.net/article/137981.htm

 

 

相關推薦

session-cookie 和token登入驗證

最近研究了下基於token的身份驗證，並將這種機制整合在個人專案中。現在很多網站的認證方式都從傳統的seesion+cookie轉向token校驗。對比傳統的校驗方式，token確實有更好的擴充套件性與安全性。 傳統的session+cookie身份驗證 由於HTTP是無狀態的，它並不記錄使

Asp.net MVC訪問母版頁中巢狀的iframe頁面時，如果session或cookie過期，登入驗證超時怎樣自動跳轉到登入頁

一般登入驗證的過濾器中，使用驗證過濾器的Redirect方法，將請求重定向到指定的URL。但是如果我們要訪問的頁面是一個巢狀在母版頁中的iframe頁面時，這種重定向只會對iframe頁面湊效，也就是會將iframe也重定向到登入頁，這樣就有違我們的目的了。所以我就嘗試了很多方法來實現讓整個頁面重定向到登入頁

【筆記】vue+springboot前後端分離實現token登入驗證和狀態儲存的簡單實現方案

簡單實現 token可用於登入驗證和許可權管理。 大致步驟分為： 前端登入，post使用者名稱和密碼到後端。 後端驗證使用者名稱和密碼，若通過，生成一個token返回給前端。 前端拿到token用vuex和localStorage管理，登入成功進入首頁。 之後前端每一次許可權操作如跳轉路由，都需要判斷是否存

學習筆記 Selenium3+java+Eclipse 通過Cookie跳過登入驗證碼

參考文章：https://blog.csdn.net/ab_2016/article/details/78427084 環境： fidder java + selenium  Cookie的處理分為： 伺服器向客戶端傳送cookie 瀏覽器將cookie儲存 之

通過Cookie跳過登入驗證碼

準備工具：   fiddler Python+selenium ------------------ 以百度登入為例。 驗證碼是漢字的，我想通過程式識別起來有點難度，也會比較麻煩。   接下來開始動手。 1、開啟Fiddler 工具，像這樣！ &nbs

token登入驗證機制圖解 （摘抄別人的）

2017年06月01日 15:04:12 @往後餘生 閱讀數：4076 個人分類： token

javaEE開發中使用session同步和token機制來防止併發重複提交

    通常在普通的操作當中，我們不需要處理重複提交的，而且有很多方法來防止重複提交。比如在登陸過程中，通過使用redirect，可以讓使用者登陸之上重定向到後臺首頁介面，當用戶重新整理介面時就不會觸發重複提交了。或者使用token，隱藏在表單中，當提交時進行token驗證，

JWT與cookie和token的區別，django中使用

一. cookie A） cookie如何認證 1. 使用者輸入使用者名稱與密碼，傳送給伺服器。 2. 伺服器驗證使用者名稱和密碼，正確的就建立一個會話（session），同時會把這個會話的ID儲存到客戶端瀏覽器中，因為儲存的地方是瀏覽器的cookie，所以這種認證方式叫做基於cookie

自動化測試 -- 通過Cookie跳過登入驗證碼

準備工具： ------------------ fiddler Python+selenium ------------------ 以百度登入為例。 驗證碼是漢字的，我想通過程式識別起來有點難度，也會比較麻煩。 接下來開始動手。 1、開啟Fidd

selenium通過cookie跳過登入驗證

java code WebDriver driver = new FirefoxDriver(); driver.manage().window().maxim

Token登入驗證

首先，引入crypto-js  或者測試直接使用下面的（用瀏覽器開啟下面連結，複製到JS檔案裡，用script src的方式引到HTML中，避免連結失效）   <script src="https://yiyouqi.oss-cn-shanghai.aliyuncs

Cookie和Token

前言 本文將首先概述基於cookie的身份驗證方式和基於token的身份驗證方式，在此基礎上對兩種驗證進行比較。 最後將介紹JWT（主要是翻譯官網介紹）。 概述 HTTP是一個“無狀態”協議，這意味著Web應用程式伺服器在響應客戶端請求時不會將多個請求連結到任何一個客戶端。然而，許多Web應用程式的安全和正

WEB後臺--基於Token的WEB後臺登入認證機制（並講解其他認證機制以及cookie和session機制）

繼續這一個系列，基於Token的WEB後臺登入認證機制（並講解cookie和session機制）。每個後端不得不解決的認證問題。 本系列： 文章結構：（1）JWT（一種基於 token 的認證方案）介紹並介紹其他幾大認證機

基於Token的WEB後臺登入認證機制（並講解其他認證機制以及cookie和session機制）

幾種常用的認證機制 HTTP Basic Auth HTTP Basic Auth簡單點說明就是每次請求API時都提供使用者的username和password，簡言之，Basic Auth是配合RESTful API 使用的最簡單的認證方式，只需提供使用者

cookie session 和登入驗證

cookie、session 簡單理解 cookie 和 session 的目的是追蹤使用者會話,標識使用者,讓伺服器知道是誰在訪問網站. cookie 是儲存在客戶端的使用者資訊,在瀏覽器首次訪問伺服器時由伺服器建立併發給客戶端。瀏覽器收到cookie後會

session和cookie的使用方法、區別，和分別實現驗證登入狀態

使用方法：1、建立cookie，setcookie(string name, string value, int expire , string path,  string domain, bool secure);

Token ，Cookie和Session的區別

最簡 對稱 請求 應用 一次 會有 程序 隨機 uid 服務器端不存token，而存設備ID、登錄時時間戳、userID等。 服務器端使用存儲信息生成token，與會話token比較完成鑒權。 在做接口測試時，經常會碰到請求參數為token的類型，但是可能大部分測試人員

cookie和session 創建和驗證 原始的servlet

原始的 nag abc mar ima col ado blog cookie 1.cookie2sessioncookie和session 創建和驗證 原始的servlet

cookie、session和token

aio 一個用戶 核心 選擇 uil img 做的 它的 blank https://zhuanlan.zhihu.com/p/25495290?utm_source=wechat_session&utm_medium=social 一、cookie 　　眾所周

基於session和cookie的登錄驗證（CBV模式）

doc app cookie ret bject project objects onf meta 基於session和cookie的登錄驗證（CBV模式） urls.py """cookie_session URL Configuration The `urlpatt