cookie?session?jwt 寫在前面
PS:已經(jīng)有很多文章寫過這些東西了,我寫的目的是為了自己的學(xué)習(xí)。所學(xué)只是為了更好地了解用戶登錄鑒權(quán)問題。
我們都知道HTTP是一個(gè)無狀態(tài)的協(xié)議
什么是無狀態(tài)?
用http協(xié)議進(jìn)行兩臺(tái)計(jì)算機(jī)交互時(shí),無論是服務(wù)器還是瀏覽器端,http協(xié)議只負(fù)責(zé)規(guī)定傳輸格式,你怎么傳輸,我怎么接受怎么返回。它并沒有記錄你上次訪問的內(nèi)容,你上次傳遞的參數(shù)是什么,它不管的。
回到我們要解決的問題,就是用戶登錄到了一個(gè)網(wǎng)站(index.html),然后點(diǎn)擊主頁上的某一個(gè)超鏈接跳轉(zhuǎn)到其他頁面(another.html),這個(gè)時(shí)候你在another.html頁面就沒有了登陸狀態(tài)。這樣意味著我們每次跳轉(zhuǎn)一個(gè)頁面都要進(jìn)行一次登陸操作,這是極其不合理的。
為了保證登錄信息以及狀態(tài)信息能夠傳遞下去,就引入了其他機(jī)制
session和cookie Cookie(1)cookie是實(shí)際存在的,存在于客戶端,用戶可見可修改,不安全。
(2)cookie在一個(gè)域名下是全局的,只要設(shè)置path為/,即可從該域名下的任意頁面讀取cookie中的信息。
(3)為了安全,HttpOnly設(shè)置為true,這樣可以一定程度上的預(yù)防XSS(跨站腳本攻擊)
(4)瀏覽器禁用cookie之后,這種情況下會(huì)使用url重寫的技術(shù)來進(jìn)行會(huì)話跟蹤,即在url后面加上sid=xxx參數(shù)。
大多數(shù)應(yīng)用都是基于cookie來實(shí)現(xiàn)session跟蹤的。
Sessionsession是一種機(jī)制,并不實(shí)際存在,它由服務(wù)器負(fù)責(zé)管理。關(guān)閉瀏覽器之后,session就會(huì)丟失。
具體的過程如下:
(1)客戶端第一次發(fā)送請(qǐng)求到服務(wù)器,服務(wù)器生成一個(gè)唯一的sessionId,一個(gè)sessionId對(duì)應(yīng)一個(gè)用戶,該sessionId可以存放在Redis或者mongodb中,具體存放在哪里看個(gè)人選擇
(2)后端將該sessionId放到響應(yīng)頭的Set-Cookie字段,返給前端。
(3)前端記下該sessionId并放到cookie字段,之后每次客戶端請(qǐng)求服務(wù)器時(shí)都會(huì)在請(qǐng)求頭帶上cookie字段,服務(wù)端根據(jù)sessionId來獲取具體信息(比如TTL,過期時(shí)間,用戶id)
Koa2中使用session首先當(dāng)然是引入包了啊,這里選擇了koa-session2`。koa-session2`已經(jīng)幫你做好了所有,使用起來相當(dāng)簡單,方便快速開發(fā)。
const Koa = require("koa") const app = new Koa() const session = require("koa-session2") app.use(session({ stort: new RedisStore(), //存放session的地方,我這里選擇放到redis里 key: "SESSION_ID" }))
new RedisStore()又是什么呢?其實(shí)查看koa-session2的git倉https://github.com/Secbone/koa-session2就能知道
以下來自官方git倉:
const Redis = require("ioredis"); const { Store } = require("koa-session2"); class RedisStore extends Store { constructor() { super(); this.redis = new Redis(); // 連接redis } async get(sid, ctx) { let data = await this.redis.get(`SESSION:${sid}`); return JSON.parse(data); } async set(session, { sid = this.getID(24), maxAge = 1000000 } = {}, ctx) { try { // Use redis set EX to automatically drop expired sessions // 設(shè)置redis的Ex 以自動(dòng)丟棄過期的session await this.redis.set(`SESSION:${sid}`, JSON.stringify(session), "EX", maxAge / 1000); } catch (e) {} return sid; } async destroy(sid, ctx) { // 刪除redis中的數(shù)據(jù) return await this.redis.del(`SESSION:${sid}`); } } module.exports = RedisStore;
接下來就是判斷登陸,以及將需要的信息寫入session
let sid = ctx.cookies.get("SESSION_ID") // 獲得cookie中的sid ctx.session.myinfo = {a: 1, b: 2} //將一個(gè)數(shù)據(jù)對(duì)象放到session中 // 最后的結(jié)果就是: // redis中的鍵為SESSION:sid // 值為{myinfo: {a: 1, b: 2}}
當(dāng)你退出時(shí),清空cookie和session即可
ctx.cookies.set("SESSION_ID", "") ctx.session = nullJWT 簡答認(rèn)識(shí)JWT
讓我們來看看重頭戲JWT,全稱JSONWebToken,是一種目前較為流行的驗(yàn)證方式。
JWT由三部分組成,第一部分我們稱它為頭部(header),
//header { "typ": "JWT", // 類型 "alg": "HS256" // 加密算法 } // 對(duì)其base64 得到了第一個(gè)部分
第二部分我們稱其為載荷(payload, 類似于飛機(jī)上承載的物品)
// payload 存放有效信息的地方 比如userId { "id": "1234567890", "name": "John Doe", "isMan": true } // 對(duì)其base64 得到第二個(gè)部分
第三部分是簽證(signature).
// 將base64后的header和base64后的payload使用.連接組成新的字符串,然后使用header中聲明的加密方式對(duì)其進(jìn)行加鹽secret組合加密,得到了第三個(gè)部分
將三部分用.連接成一個(gè)完整的字符串,得到了最終的jwt。
注意:
不應(yīng)該在jwt的payload部分存放敏感信息,因?yàn)樵摬糠质强蛻舳丝山饷艿牟糠帧?/p>
保護(hù)好secret私鑰,該私鑰非常重要。
如果可以,請(qǐng)使用https協(xié)議
具體的過程如下:
(1)客戶端第一次發(fā)送請(qǐng)求到服務(wù)端,服務(wù)器驗(yàn)證用戶信息
(2)服務(wù)端生成一個(gè)token發(fā)送給客戶端
(3)客戶端保存token,之后每次請(qǐng)求時(shí)帶上這個(gè)token
(4)服務(wù)端驗(yàn)證token,返回?cái)?shù)據(jù)。
與session的過程是類似的,但是缺少了將jwt保存到服務(wù)端,這樣便于擴(kuò)展,不會(huì)因?yàn)榈卿浀讲煌姆?wù)器導(dǎo)致session無法共享。
Koa2中使用jwt第一步當(dāng)然還是下包。。npm install jsonwebtoken
const jwt = require("jsonwebtoken")
服務(wù)端生成token,并返給前端
// 生成token const token = jwt.sign({role: user.role, id: user._id}, key, {expiresIn: "1 days"}) // 第一個(gè)參數(shù)為負(fù)載的信息,第二個(gè)參數(shù)為secret,第三個(gè)參數(shù)我是過期時(shí)間 // 返回前端 ctx.body = { token: token }
客戶端之后發(fā)起請(qǐng)求,應(yīng)該帶上token字段,將其放在authorization請(qǐng)求頭字段或者以query的方式。
if(ctx.header.authorization && ctx.headers.authorization.split(" ")[0] === "Bearer") { token = ctx.header.authorization.split(" ")[1] } else if(ctx.query && ctx.query.token) { token = ctx.query.token }
然后服務(wù)端驗(yàn)證token,進(jìn)行相應(yīng)的處理返回?cái)?shù)據(jù)。
// 解密token 一般使用jwt.verify不適用jwt.decode let decoded = jwt.verify(token, key) // 得到token中包含的信息對(duì)象
文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址:http://specialneedsforspecialkids.com/yun/94670.html
摘要:由于是存在客戶端上的,所以瀏覽器加入了一些限制確保不會(huì)被惡意使用,同時(shí)不會(huì)占據(jù)太多磁盤空間。簽名是對(duì)前兩部分的簽名,防止數(shù)據(jù)被篡改。的作用最開始的初衷是為了實(shí)現(xiàn)授權(quán)和身份認(rèn)證作用的,可以實(shí)現(xiàn)無狀態(tài),分布式的應(yīng)用授權(quán)。 前言 無狀態(tài)的HTTP協(xié)議 很久很久之前, Web基本都是文檔的瀏覽而已。既然是瀏覽, 作為服務(wù)器, 不需要記錄在某一段時(shí)間里都瀏覽了什么文檔, 每次請(qǐng)求都是一個(gè)新的HT...
摘要:為用戶提供授權(quán)以允許用戶操作非公開資源,有很多種方式。具體的代碼根據(jù)不同的授權(quán)方案而有所不同。使用授權(quán)原理利用來驗(yàn)證用戶,有兩種機(jī)制實(shí)現(xiàn)。使用來實(shí)現(xiàn)用戶授權(quán)主要用于簽發(fā)如果有將異步的簽名。注意這里的與之前用于簽發(fā)的應(yīng)該是同一個(gè)。 在很多應(yīng)用中,我們都需要向服務(wù)端提供自己的身份憑證來獲得訪問一些非公開資源的授權(quán)。比如在一個(gè)博客平臺(tái),我們要修改自己的博客,那么服務(wù)端要求我們能夠證明 我是...
摘要:為用戶提供授權(quán)以允許用戶操作非公開資源,有很多種方式。具體的代碼根據(jù)不同的授權(quán)方案而有所不同。使用授權(quán)原理利用來驗(yàn)證用戶,有兩種機(jī)制實(shí)現(xiàn)。使用來實(shí)現(xiàn)用戶授權(quán)主要用于簽發(fā)如果有將異步的簽名。 ? 在很多應(yīng)用中,我們都需要向服務(wù)端提供自己的身份憑證來獲得訪問一些非公開資源的授權(quán)。比如在一個(gè)博客平臺(tái),我們要修改自己的博客,那么服務(wù)端要求我們能夠證明 我是我 ,才會(huì)允許我們修改自己的...
摘要:最近,項(xiàng)目的安全認(rèn)證機(jī)制全面采用。為了伸縮性考慮,采用機(jī)制,必然面臨著應(yīng)用狀態(tài)的問題,而且必然牽涉到的復(fù)制。為了安全性考慮,機(jī)制僅驗(yàn)證時(shí)天然對(duì)免疫。若有可能,使用標(biāo)志。采用來防止這是因?yàn)椋谡军c(diǎn)上發(fā)起向站點(diǎn)的請(qǐng)求時(shí),站點(diǎn)的同樣會(huì)被發(fā)送給。 最近,項(xiàng)目的安全認(rèn)證機(jī)制全面采用JWT。現(xiàn)在,趁整個(gè)工作基本告一段落之際,將一些知識(shí)點(diǎn)總結(jié)一下發(fā)布出來。 為什么要遷移? 原因很簡單,就以下幾點(diǎn): ...
摘要:客戶端發(fā)起非登錄請(qǐng)求時(shí),服務(wù)端通過中的找到對(duì)應(yīng)的來知道此次請(qǐng)求是誰發(fā)出的。數(shù)量隨著登錄用戶的增多而增多,存儲(chǔ)會(huì)增加很多。還記得在上家公司做全干工程師的時(shí)候,基本從頁面寫到運(yùn)維,當(dāng)時(shí)做登錄這塊的時(shí)候,被session、cookie、token各種概念差點(diǎn)整蒙圈了,上網(wǎng)查詢相關(guān)概念,發(fā)現(xiàn)很多人都是類似的疑惑,比如:showImg(https://user-gold-cdn.xitu.io/201...
閱讀 989·2023-04-26 01:47
閱讀 1674·2021-11-18 13:19
閱讀 2047·2019-08-30 15:44
閱讀 656·2019-08-30 15:44
閱讀 2299·2019-08-30 15:44
閱讀 1237·2019-08-30 14:06
閱讀 1427·2019-08-30 12:59
閱讀 1904·2019-08-29 12:49