国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

cookie?session?jwt

sarva / 903人閱讀

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跟蹤的。

Session

session是一種機(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 = null
JWT 簡答認(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

相關(guān)文章

  • 詳解 CookieSession,Token

    摘要:由于是存在客戶端上的,所以瀏覽器加入了一些限制確保不會(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...

    Allen 評(píng)論0 收藏0
  • JWT、OAuth 2.0、session 用戶授權(quán)實(shí)戰(zhàn)

    摘要:為用戶提供授權(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ù)端要求我們能夠證明 我是...

    Jochen 評(píng)論0 收藏0
  • JWT、OAuth 2.0、session 用戶授權(quán)實(shí)戰(zhàn)

    摘要:為用戶提供授權(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ì)允許我們修改自己的...

    zhaot 評(píng)論0 收藏0
  • JWT必知必會(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): ...

    張金寶 評(píng)論0 收藏0
  • 前端應(yīng)該知道的web登錄

    摘要:客戶端發(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...

    NervosNetwork 評(píng)論0 收藏0

發(fā)表評(píng)論

0條評(píng)論

sarva

|高級(jí)講師

TA的文章

閱讀更多
最新活動(dòng)
閱讀需要支付1元查看
<