免费在线a视频-免费在线观看a视频-免费在线观看大片影视大全-免费在线观看的视频-色播丁香-色播基地

還分不清 Cookie、Session、Token、JWT?

:2020年01月24日 秋天不落葉 腳本之家
分享到:

什么是認(rèn)證(Authentication)通俗地講就是驗證當(dāng)前用戶的身份,證明“你是你自己”(比如:你每天上下班打卡,都需要通過指紋打卡,當(dāng)你的指紋和系統(tǒng)里錄入的指紋相匹配時,就打卡成功)互聯(lián)網(wǎng)中的認(rèn)證...

什么是認(rèn)證(Authentication)

  • 通俗地講就是驗證當(dāng)前用戶的身份,證明“你是你自己”(比如:你每天上下班打卡,都需要通過指紋打卡,當(dāng)你的指紋和系統(tǒng)里錄入的指紋相匹配時,就打卡成功)

  • 互聯(lián)網(wǎng)中的認(rèn)證:

  • 用戶名密碼登錄

  • 郵箱發(fā)送登錄鏈接

  • 手機號接收驗證碼

  • 只要你能收到郵箱/驗證碼,就默認(rèn)你是賬號的主人

什么是授權(quán)(Authorization)

  • 用戶授予第三方應(yīng)用訪問該用戶某些資源的權(quán)限

  • 你在安裝手機應(yīng)用的時候,APP 會詢問是否允許授予權(quán)限(訪問相冊、地理位置等權(quán)限)

  • 你在訪問微信小程序時,當(dāng)?shù)卿洉r,小程序會詢問是否允許授予權(quán)限(獲取昵稱、頭像、地區(qū)、性別等個人信息)

  • 實現(xiàn)授權(quán)的方式有:cookie、session、token、OAuth

什么是憑證(Credentials)

  • 實現(xiàn)認(rèn)證和授權(quán)的前提是需要一種媒介(證書) 來標(biāo)記訪問者的身份

  • 在戰(zhàn)國時期,商鞅變法,發(fā)明了照身帖。照身帖由官府發(fā)放,是一塊打磨光滑細(xì)密的竹板,上面刻有持有人的頭像和籍貫信息。國人必須持有,如若沒有就被認(rèn)為是黑戶,或者間諜之類的。

  • 在現(xiàn)實生活中,每個人都會有一張專屬的居民身份證,是用于證明持有人身份的一種法定證件。通過身份證,我們可以辦理手機卡/銀行卡/個人貸款/交通出行等等,這就是認(rèn)證的憑證。

  • 在互聯(lián)網(wǎng)應(yīng)用中,一般網(wǎng)站(如掘金)會有兩種模式,游客模式和登錄模式。游客模式下,可以正常瀏覽網(wǎng)站上面的文章,一旦想要點贊/收藏/分享文章,就需要登錄或者注冊賬號。當(dāng)用戶登錄成功后,服務(wù)器會給該用戶使用的瀏覽器頒發(fā)一個令牌(token),這個令牌用來表明你的身份,每次瀏覽器發(fā)送請求時會帶上這個令牌,就可以使用游客模式下無法使用的功能。

什么是 Cookie

  • HTTP 是無狀態(tài)的協(xié)議(對于事務(wù)處理沒有記憶能力,每次客戶端和服務(wù)端會話完成時,服務(wù)端不會保存任何會話信息):每個請求都是完全獨立的,服務(wù)端無法確認(rèn)當(dāng)前訪問者的身份信息,無法分辨上一次的請求發(fā)送者和這一次的發(fā)送者是不是同一個人。所以服務(wù)器與瀏覽器為了進行會話跟蹤(知道是誰在訪問我),就必須主動的去維護一個狀態(tài),這個狀態(tài)用于告知服務(wù)端前后兩個請求是否來自同一瀏覽器。而這個狀態(tài)需要通過 cookie 或者 session 去實現(xiàn)。

  • cookie 存儲在客戶端: cookie 是服務(wù)器發(fā)送到用戶瀏覽器并保存在本地的一小塊數(shù)據(jù),它會在瀏覽器下次向同一服務(wù)器再發(fā)起請求時被攜帶并發(fā)送到服務(wù)器上。

  • cookie 是不可跨域的: 每個 cookie 都會綁定單一的域名,無法在別的域名下獲取使用,一級域名和二級域名之間是允許共享使用的靠的是 domain)

cookie 重要的屬性屬性說明name=value鍵值對,設(shè)置 Cookie 的名稱及相對應(yīng)的值,都必須是字符串類型

  • 如果值為 Unicode 字符,需要為字符編碼。

  • 如果值為二進制數(shù)據(jù),則需要使用 BASE64 編碼。domain指定 cookie 所屬域名,默認(rèn)是當(dāng)前域名path****指定 cookie 在哪個路徑(路由)下生效,默認(rèn)是 '/'。如果設(shè)置為 /abc,則只有 /abc 下的路由可以訪問到該 cookie,如:/abc/read。maxAgecookie 失效的時間,單位秒。如果為整數(shù),則該 cookie 在 maxAge 秒后失效。如果為負(fù)數(shù),該 cookie 為臨時 cookie ,關(guān)閉瀏覽器即失效,瀏覽器也不會以任何形式保存該 cookie 。如果為 0,表示刪除該 cookie 。默認(rèn)為 -1。

  • 比 expires 好用expires過期時間,在設(shè)置的某個時間點后該 cookie 就會失效。一般瀏覽器的 cookie 都是默認(rèn)儲存的,當(dāng)關(guān)閉瀏覽器結(jié)束這個會話的時候,這個 cookie 也就會被刪除secure該 cookie 是否僅被使用安全協(xié)議傳輸。安全協(xié)議有 HTTPS,SSL等,在網(wǎng)絡(luò)上傳輸數(shù)據(jù)之前先將數(shù)據(jù)加密。默認(rèn)為false。當(dāng) secure 值為 true 時,cookie 在 HTTP 中是無效,在 HTTPS 中才有效。httpOnly****如果給某個 cookie 設(shè)置了 httpOnly 屬性,則無法通過 JS 腳本 讀取到該 cookie 的信息,但還是能通過 Application 中手動修改 cookie,所以只是在一定程度上可以防止 XSS 攻擊,不是絕對的安全

什么是 Session

  • session 是另一種記錄服務(wù)器和客戶端會話狀態(tài)的機制

  • session 是基于 cookie 實現(xiàn)的,session 存儲在服務(wù)器端,sessionId 會被存儲到客戶端的cookie 中

session.png

  • session 認(rèn)證流程:

  • 用戶第一次請求服務(wù)器的時候,服務(wù)器根據(jù)用戶提交的相關(guān)信息,創(chuàng)建對應(yīng)的 Session

  • 請求返回時將此 Session 的唯一標(biāo)識信息 SessionID 返回給瀏覽器

  • 瀏覽器接收到服務(wù)器返回的 SessionID 信息后,會將此信息存入到 Cookie 中,同時 Cookie 記錄此 SessionID 屬于哪個域名

  • 當(dāng)用戶第二次訪問服務(wù)器的時候,請求會自動判斷此域名下是否存在 Cookie 信息,如果存在自動將 Cookie 信息也發(fā)送給服務(wù)端,服務(wù)端會從 Cookie 中獲取 SessionID,再根據(jù) SessionID 查找對應(yīng)的 Session 信息,如果沒有找到說明用戶沒有登錄或者登錄失效,如果找到 Session 證明用戶已經(jīng)登錄可執(zhí)行后面操作。

根據(jù)以上流程可知,SessionID 是連接 Cookie 和 Session 的一道橋梁,大部分系統(tǒng)也是根據(jù)此原理來驗證用戶登錄狀態(tài)。

Cookie 和 Session 的區(qū)別

  • 安全性: Session 比 Cookie 安全,Session 是存儲在服務(wù)器端的,Cookie 是存儲在客戶端的。

  • 存取值的類型不同:Cookie 只支持存字符串?dāng)?shù)據(jù),想要設(shè)置其他類型的數(shù)據(jù),需要將其轉(zhuǎn)換成字符串,Session 可以存任意數(shù)據(jù)類型。

  • 有效期不同: Cookie 可設(shè)置為長時間保持,比如我們經(jīng)常使用的默認(rèn)登錄功能,Session 一般失效時間較短,客戶端關(guān)閉(默認(rèn)情況下)或者 Session 超時都會失效。

  • 存儲大小不同: 單個 Cookie 保存的數(shù)據(jù)不能超過 4K,Session 可存儲數(shù)據(jù)遠(yuǎn)高于 Cookie,但是當(dāng)訪問量過多,會占用過多的服務(wù)器資源。

什么是 Token(令牌)

Acesss Token

  • 訪問資源接口(API)時所需要的資源憑證

  • 簡單 token 的組成: uid(用戶唯一的身份標(biāo)識)、time(當(dāng)前時間的時間戳)、sign(簽名,token 的前幾位以哈希算法壓縮成的一定長度的十六進制字符串)

  • 特點:

  • 服務(wù)端無狀態(tài)化、可擴展性好

  • 支持移動端設(shè)備

  • 安全

  • 支持跨程序調(diào)用

  • token 的身份驗證流程:

  1. 客戶端使用用戶名跟密碼請求登錄

  2. 服務(wù)端收到請求,去驗證用戶名與密碼

  3. 驗證成功后,服務(wù)端會簽發(fā)一個 token 并把這個 token 發(fā)送給客戶端

  4. 客戶端收到 token 以后,會把它存儲起來,比如放在 cookie 里或者 localStorage 里

  5. 客戶端每次向服務(wù)端請求資源的時候需要帶著服務(wù)端簽發(fā)的 token

  6. 服務(wù)端收到請求,然后去驗證客戶端請求里面帶著的 token ,如果驗證成功,就向客戶端返回請求的數(shù)據(jù)

  • 每一次請求都需要攜帶 token,需要把 token 放到 HTTP 的 Header 里

  • 基于 token 的用戶認(rèn)證是一種服務(wù)端無狀態(tài)的認(rèn)證方式,服務(wù)端不用存放 token 數(shù)據(jù)。用解析 token 的計算時間換取 session 的存儲空間,從而減輕服務(wù)器的壓力,減少頻繁的查詢數(shù)據(jù)庫

  • token 完全由應(yīng)用管理,所以它可以避開同源策略

Refresh Token

  • 另外一種 token——refresh token

  • refresh token 是專用于刷新 access token 的 token。如果沒有 refresh token,也可以刷新 access token,但每次刷新都要用戶輸入登錄用戶名與密碼,會很麻煩。有了 refresh token,可以減少這個麻煩,客戶端直接用 refresh token 去更新 access token,無需用戶進行額外的操作。

  • Access Token 的有效期比較短,當(dāng) Acesss Token 由于過期而失效時,使用 Refresh Token 就可以獲取到新的 Token,如果 Refresh Token 也失效了,用戶就只能重新登錄了。

  • Refresh Token 及過期時間是存儲在服務(wù)器的數(shù)據(jù)庫中,只有在申請新的 Acesss Token 時才會驗證,不會對業(yè)務(wù)接口響應(yīng)時間造成影響,也不需要向 Session 一樣一直保持在內(nèi)存中以應(yīng)對大量的請求。

Token 和 Session 的區(qū)別

  • Session 是一種記錄服務(wù)器和客戶端會話狀態(tài)的機制,使服務(wù)端有狀態(tài)化,可以記錄會話信息。而 Token 是令牌訪問資源接口(API)時所需要的資源憑證。Token 使服務(wù)端無狀態(tài)化,不會存儲會話信息。

  • Session 和 Token 并不矛盾,作為身份認(rèn)證 Token 安全性比 Session 好,因為每一個請求都有簽名還能防止監(jiān)聽以及重放攻擊,而 Session 就必須依賴鏈路層來保障通訊安全了。如果你需要實現(xiàn)有狀態(tài)的會話,仍然可以增加 Session 來在服務(wù)器端保存一些狀態(tài)。

  • 所謂 Session 認(rèn)證只是簡單的把 User 信息存儲到 Session 里,因為 SessionID 的不可預(yù)測性,暫且認(rèn)為是安全的。而 Token ,如果指的是 OAuth Token 或類似的機制的話,提供的是 認(rèn)證 和 授權(quán) ,認(rèn)證是針對用戶,授權(quán)是針對 App 。其目的是讓某 App 有權(quán)利訪問某用戶的信息。這里的 Token 是唯一的。不可以轉(zhuǎn)移到其它 App上,也不可以轉(zhuǎn)到其它用戶上。Session 只提供一種簡單的認(rèn)證,即只要有此 SessionID ,即認(rèn)為有此 User 的全部權(quán)利。是需要嚴(yán)格保密的,這個數(shù)據(jù)應(yīng)該只保存在站方,不應(yīng)該共享給其它網(wǎng)站或者第三方 App。所以簡單來說:如果你的用戶數(shù)據(jù)可能需要和第三方共享,或者允許第三方調(diào)用 API 接口,用 Token 。如果永遠(yuǎn)只是自己的網(wǎng)站,自己的 App,用什么就無所謂了。

什么是 JWT

  • JSON Web Token(簡稱 JWT)是目前最流行的跨域認(rèn)證解決方案。

  • 是一種認(rèn)證授權(quán)機制

  • JWT 是為了在網(wǎng)絡(luò)應(yīng)用環(huán)境間傳遞聲明而執(zhí)行的一種基于 JSON 的開放標(biāo)準(zhǔn)(RFC 7519)。JWT 的聲明一般被用來在身份提供者和服務(wù)提供者間傳遞被認(rèn)證的用戶身份信息,以便于從資源服務(wù)器獲取資源。比如用在用戶登錄上。

  • 可以使用 HMAC 算法或者是 RSA 的公/私秘鑰對 JWT 進行簽名。因為數(shù)字簽名的存在,這些傳遞的信息是可信的。

  • 阮一峰老師的 JSON Web Token 入門教程 講的非常通俗易懂,這里就不再班門弄斧了

生成 JWT

jwt.io/www.jsonwebtoken.io/

JWT 的原理

  • JWT 認(rèn)證流程:

  • 用戶輸入用戶名/密碼登錄,服務(wù)端認(rèn)證成功后,會返回給客戶端一個 JWT

  • 客戶端將 token 保存到本地(通常使用 localstorage,也可以使用 cookie)

  • 當(dāng)用戶希望訪問一個受保護的路由或者資源的時候,需要請求頭的 Authorization 字段中使用Bearer 模式添加 JWT,其內(nèi)容看起來是下面這樣

  • Authorization: Bearer復(fù)制代碼

  • 服務(wù)端的保護路由將會檢查請求頭 Authorization 中的 JWT 信息,如果合法,則允許用戶的行為

  • 因為 JWT 是自包含的(內(nèi)部包含了一些會話信息),因此減少了需要查詢數(shù)據(jù)庫的需要

  • 因為 JWT 并不使用 Cookie 的,所以你可以使用任何域名提供你的 API 服務(wù)而不需要擔(dān)心跨域資源共享問題(CORS)

  • 因為用戶的狀態(tài)不再存儲在服務(wù)端的內(nèi)存中,所以這是一種無狀態(tài)的認(rèn)證機制

JWT 的使用方式

  • 客戶端收到服務(wù)器返回的 JWT,可以儲存在 Cookie 里面,也可以儲存在 localStorage。

方式一

  • 當(dāng)用戶希望訪問一個受保護的路由或者資源的時候,可以把它放在 Cookie 里面自動發(fā)送,但是這樣不能跨域,所以更好的做法是放在 HTTP 請求頭信息的 Authorization 字段里,使用 Bearer 模式添加 JWT。

GET /calendar/v1/events

Host: api.example.com

Authorization: Bearer

  • 用戶的狀態(tài)不會存儲在服務(wù)端的內(nèi)存中,這是一種 無狀態(tài)的認(rèn)證機制

  • 服務(wù)端的保護路由將會檢查請求頭 Authorization 中的 JWT 信息,如果合法,則允許用戶的行為。

  • 由于 JWT 是自包含的,因此減少了需要查詢數(shù)據(jù)庫的需要

  • JWT 的這些特性使得我們可以完全依賴其無狀態(tài)的特性提供數(shù)據(jù) API 服務(wù),甚至是創(chuàng)建一個下載流服務(wù)。

  • 因為 JWT 并不使用 Cookie ,所以你可以使用任何域名提供你的 API 服務(wù)而不需要擔(dān)心跨域資源共享問題(CORS)

方式二

  • 跨域的時候,可以把 JWT 放在 POST 請求的數(shù)據(jù)體里。

方式三

  • 通過 URL 傳輸

http://www.example.com/user?token=xxx

項目中使用 JWT

**項目地址: https://github.com/yjdjiayou/jwt-demo **

Token 和 JWT 的區(qū)別

相同:

  • 都是訪問資源的令牌

  • 都可以記錄用戶的信息

  • 都是使服務(wù)端無狀態(tài)化

  • 都是只有驗證成功后,客戶端才能訪問服務(wù)端上受保護的資源

區(qū)別:

  • Token:服務(wù)端驗證客戶端發(fā)送過來的 Token 時,還需要查詢數(shù)據(jù)庫獲取用戶信息,然后驗證 Token 是否有效。

  • JWT:將 Token 和 Payload 加密后存儲于客戶端,服務(wù)端只需要使用密鑰解密進行校驗(校驗也是 JWT 自己實現(xiàn)的)即可,不需要查詢或者減少查詢數(shù)據(jù)庫,因為 JWT 自包含了用戶信息和加密的數(shù)據(jù)。

常見的前后端鑒權(quán)方式

  1. Session-Cookie

  2. Token 驗證(包括 JWT,SSO)

  3. OAuth2.0(開放授權(quán))

常見的加密算法

image.png

  • 哈希算法(Hash Algorithm)又稱散列算法、散列函數(shù)、哈希函數(shù),是一種從任何一種數(shù)據(jù)中創(chuàng)建小的數(shù)字“指紋”的方法。哈希算法將數(shù)據(jù)重新打亂混合,重新創(chuàng)建一個哈希值。

  • 哈希算法主要用來保障數(shù)據(jù)真實性(即完整性),即發(fā)信人將原始消息和哈希值一起發(fā)送,收信人通過相同的哈希函數(shù)來校驗原始數(shù)據(jù)是否真實。

  • 哈希算法通常有以下幾個特點:

  • 正像快速:原始數(shù)據(jù)可以快速計算出哈希值

  • 逆向困難:通過哈希值基本不可能推導(dǎo)出原始數(shù)據(jù)

  • 輸入敏感:原始數(shù)據(jù)只要有一點變動,得到的哈希值差別很大

  • 沖突避免:很難找到不同的原始數(shù)據(jù)得到相同的哈希值,宇宙中原子數(shù)大約在 10 的 60 次方到 80 次方之間,所以 2 的 256 次方有足夠的空間容納所有的可能,算法好的情況下沖突碰撞的概率很低:

  • 2 的 128 次方為 340282366920938463463374607431768211456,也就是 10 的 39 次方級別

  • 2 的 160 次方為 1.4615016373309029182036848327163e+48,也就是 10 的 48 次方級別

  • 2 的 256 次方為 1.1579208923731619542357098500869 × 10 的 77 次方,也就是 10 的 77 次方

注意:

  1. 以上不能保證數(shù)據(jù)被惡意篡改,原始數(shù)據(jù)和哈希值都可能被惡意篡改,要保證不被篡改,可以使用RSA 公鑰私鑰方案,再配合哈希值。

  2. 哈希算法主要用來防止計算機傳輸過程中的錯誤,早期計算機通過前 7 位數(shù)據(jù)第 8 位奇偶校驗碼來保障(12.5% 的浪費效率低),對于一段數(shù)據(jù)或文件,通過哈希算法生成 128bit 或者 256bit 的哈希值,如果校驗有問題就要求重傳。

常見問題

使用 cookie 時需要考慮的問題

  • 因為存儲在客戶端,容易被客戶端篡改,使用前需要驗證合法性

  • 不要存儲敏感數(shù)據(jù),比如用戶密碼,賬戶余額

  • 使用 httpOnly 在一定程度上提高安全性

  • 盡量減少 cookie 的體積,能存儲的數(shù)據(jù)量不能超過 4kb

  • 設(shè)置正確的 domain 和 path,減少數(shù)據(jù)傳輸

  • cookie 無法跨域

  • 一個瀏覽器針對一個網(wǎng)站最多存 20 個Cookie,瀏覽器一般只允許存放 300 個Cookie

  • 移動端對 cookie 的支持不是很好,而 session 需要基于 cookie 實現(xiàn),所以移動端常用的是 token

使用 session 時需要考慮的問題

  • 將 session 存儲在服務(wù)器里面,當(dāng)用戶同時在線量比較多時,這些 session 會占據(jù)較多的內(nèi)存,需要在服務(wù)端定期的去清理過期的 session

  • 當(dāng)網(wǎng)站采用集群部署的時候,會遇到多臺 web 服務(wù)器之間如何做 session 共享的問題。因為 session 是由單個服務(wù)器創(chuàng)建的,但是處理用戶請求的服務(wù)器不一定是那個創(chuàng)建 session 的服務(wù)器,那么該服務(wù)器就無法拿到之前已經(jīng)放入到 session 中的登錄憑證之類的信息了。

  • 當(dāng)多個應(yīng)用要共享 session 時,除了以上問題,還會遇到跨域問題,因為不同的應(yīng)用可能部署的主機不一樣,需要在各個應(yīng)用做好 cookie 跨域的處理。

  • sessionId 是存儲在 cookie 中的,假如瀏覽器禁止 cookie 或不支持 cookie 怎么辦? 一般會把 sessionId 跟在 url 參數(shù)后面即重寫 url,所以 session 不一定非得需要靠 cookie 實現(xiàn)

  • 移動端對 cookie 的支持不是很好,而 session 需要基于 cookie 實現(xiàn),所以移動端常用的是 token

使用 token 時需要考慮的問題

  • 如果你認(rèn)為用數(shù)據(jù)庫來存儲 token 會導(dǎo)致查詢時間太長,可以選擇放在內(nèi)存當(dāng)中。比如 redis 很適合你對 token 查詢的需求。

  • token 完全由應(yīng)用管理,所以它可以避開同源策略

  • token 可以避免 CSRF 攻擊(因為不需要 cookie 了)

  • 移動端對 cookie 的支持不是很好,而 session 需要基于 cookie 實現(xiàn),所以移動端常用的是 token

使用 JWT 時需要考慮的問題

  • 因為 JWT 并不依賴 Cookie 的,所以你可以使用任何域名提供你的 API 服務(wù)而不需要擔(dān)心跨域資源共享問題(CORS)

  • JWT 默認(rèn)是不加密,但也是可以加密的。生成原始 Token 以后,可以用密鑰再加密一次。

  • JWT 不加密的情況下,不能將秘密數(shù)據(jù)寫入 JWT。

  • JWT 不僅可以用于認(rèn)證,也可以用于交換信息。有效使用 JWT,可以降低服務(wù)器查詢數(shù)據(jù)庫的次數(shù)。

  • JWT 最大的優(yōu)勢是服務(wù)器不再需要存儲 Session,使得服務(wù)器認(rèn)證鑒權(quán)業(yè)務(wù)可以方便擴展。但這也是 JWT 最大的缺點:由于服務(wù)器不需要存儲 Session 狀態(tài),因此使用過程中無法廢棄某個 Token 或者更改 Token 的權(quán)限。也就是說一旦 JWT 簽發(fā)了,到期之前就會始終有效,除非服務(wù)器部署額外的邏輯。

  • JWT 本身包含了認(rèn)證信息,一旦泄露,任何人都可以獲得該令牌的所有權(quán)限。為了減少盜用,JWT的有效期應(yīng)該設(shè)置得比較短。對于一些比較重要的權(quán)限,使用時應(yīng)該再次對用戶進行認(rèn)證。

  • JWT 適合一次性的命令認(rèn)證,頒發(fā)一個有效期極短的 JWT,即使暴露了危險也很小,由于每次操作都會生成新的 JWT,因此也沒必要保存 JWT,真正實現(xiàn)無狀態(tài)。

  • 為了減少盜用,JWT 不應(yīng)該使用 HTTP 協(xié)議明碼傳輸,要使用 HTTPS 協(xié)議傳輸。

使用加密算法時需要考慮的問題

  • 絕不要以明文存儲密碼

  • 永遠(yuǎn)使用 哈希算法 來處理密碼,絕不要使用 Base64 或其他編碼方式來存儲密碼,這和以明文存儲密碼是一樣的,使用哈希,而不要使用編碼。編碼以及加密,都是雙向的過程,而密碼是保密的,應(yīng)該只被它的所有者知道, 這個過程必須是單向的。哈希正是用于做這個的,從來沒有解哈希這種說法, 但是編碼就存在解碼,加密就存在解密。

  • 絕不要使用弱哈希或已被破解的哈希算法,像 MD5 或 SHA1 ,只使用強密碼哈希算法。

  • 絕不要以明文形式顯示或發(fā)送密碼,即使是對密碼的所有者也應(yīng)該這樣。如果你需要 “忘記密碼” 的功能,可以隨機生成一個新的 一次性的(這點很重要)密碼,然后把這個密碼發(fā)送給用戶。

分布式架構(gòu)下 session 共享方案

1. session 復(fù)制

  • 任何一個服務(wù)器上的 session 發(fā)生改變(增刪改),該節(jié)點會把這個 session 的所有內(nèi)容序列化,然后廣播給所有其它節(jié)點,不管其他服務(wù)器需不需要 session ,以此來保證 session 同步

優(yōu)點: 可容錯,各個服務(wù)器間 session 能夠?qū)崟r響應(yīng)。

缺點: 會對網(wǎng)絡(luò)負(fù)荷造成一定壓力,如果 session 量大的話可能會造成網(wǎng)絡(luò)堵塞,拖慢服務(wù)器性能。

2. 粘性 session /IP 綁定策略

  • 采用 Ngnix 中的 ip_hash 機制,將某個 ip的所有請求都定向到同一臺服務(wù)器上,即將用戶與服務(wù)器綁定。 用戶第一次請求時,負(fù)載均衡器將用戶的請求轉(zhuǎn)發(fā)到了 A 服務(wù)器上,如果負(fù)載均衡器設(shè)置了粘性 session 的話,那么用戶以后的每次請求都會轉(zhuǎn)發(fā)到 A 服務(wù)器上,相當(dāng)于把用戶和 A 服務(wù)器粘到了一塊,這就是粘性 session 機制。

優(yōu)點: 簡單,不需要對 session 做任何處理。

缺點: 缺乏容錯性,如果當(dāng)前訪問的服務(wù)器發(fā)生故障,用戶被轉(zhuǎn)移到第二個服務(wù)器上時,他的 session 信息都將失效。

適用場景: 發(fā)生故障對客戶產(chǎn)生的影響較小;服務(wù)器發(fā)生故障是低概率事件。實現(xiàn)方式: 以 Nginx 為例,在 upstream 模塊配置 ip_hash 屬性即可實現(xiàn)粘性 session。

3. session 共享(常用)

  • 使用分布式緩存方案比如 Memcached 、Redis 來緩存 session,但是要求 Memcached 或 Redis 必須是集群

  • 把 session 放到 Redis 中存儲,雖然架構(gòu)上變得復(fù)雜,并且需要多訪問一次 Redis ,但是這種方案帶來的好處也是很大的:

  • 實現(xiàn)了 session 共享;

  • 可以水平擴展(增加 Redis 服務(wù)器);

  • 服務(wù)器重啟 session 不丟失(不過也要注意 session 在 Redis 中的刷新/失效機制);

  • 不僅可以跨服務(wù)器 session 共享,甚至可以跨平臺(例如網(wǎng)頁端和 APP 端)

4. session 持久化

  • 將 session 存儲到數(shù)據(jù)庫中,保證 session 的持久化

優(yōu)點: 服務(wù)器出現(xiàn)問題,session 不會丟失

缺點: 如果網(wǎng)站的訪問量很大,把 session 存儲到數(shù)據(jù)庫中,會對數(shù)據(jù)庫造成很大壓力,還需要增加額外的開銷維護數(shù)據(jù)庫。

只要關(guān)閉瀏覽器 ,session 真的就消失了?

不對。對 session 來說,除非程序通知服務(wù)器刪除一個 session,否則服務(wù)器會一直保留,程序一般都是在用戶做 log off 的時候發(fā)個指令去刪除 session。然而瀏覽器從來不會主動在關(guān)閉之前通知服務(wù)器它將要關(guān)閉,因此服務(wù)器根本不會有機會知道瀏覽器已經(jīng)關(guān)閉,之所以會有這種錯覺,是大部分 session 機制都使用會話 cookie 來保存 session id,而關(guān)閉瀏覽器后這個 session id 就消失了,再次連接服務(wù)器時也就無法找到原來的 session。如果服務(wù)器設(shè)置的 cookie 被保存在硬盤上,或者使用某種手段改寫瀏覽器發(fā)出的 HTTP 請求頭,把原來的 session id 發(fā)送給服務(wù)器,則再次打開瀏覽器仍然能夠打開原來的 session。恰恰是由于關(guān)閉瀏覽器不會導(dǎo)致 session 被刪除,迫使服務(wù)器為 session 設(shè)置了一個失效時間,當(dāng)距離客戶端上一次使用 session 的時間超過這個失效時間時,服務(wù)器就認(rèn)為客戶端已經(jīng)停止了活動,才會把 session 刪除以節(jié)省存儲空間。

項目地址

在項目中使用 JWT:https://github.com/yjdjiayou/jwt-demo

[我要糾錯]
文:王振袢&發(fā)表于江蘇
關(guān)鍵詞: 什么 認(rèn)證 Authentication 通俗 就是

來源:本文內(nèi)容搜集或轉(zhuǎn)自各大網(wǎng)絡(luò)平臺,并已注明來源、出處,如果轉(zhuǎn)載侵犯您的版權(quán)或非授權(quán)發(fā)布,請聯(lián)系小編,我們會及時審核處理。
聲明:江蘇教育黃頁對文中觀點保持中立,對所包含內(nèi)容的準(zhǔn)確性、可靠性或者完整性不提供任何明示或暗示的保證,不對文章觀點負(fù)責(zé),僅作分享之用,文章版權(quán)及插圖屬于原作者。

點個贊
0
踩一腳
0

您在閱讀:還分不清 Cookie、Session、Token、JWT?

Copyright?2013-2024 JSedu114 All Rights Reserved. 江蘇教育信息綜合發(fā)布查詢平臺保留所有權(quán)利

蘇公網(wǎng)安備32010402000125 蘇ICP備14051488號-3技術(shù)支持:南京博盛藍(lán)睿網(wǎng)絡(luò)科技有限公司

南京思必達(dá)教育科技有限公司版權(quán)所有   百度統(tǒng)計

主站蜘蛛池模板: 精品久久久久久国产 | 麻豆国产免费影片 | 久爱www成人网免费视频 | 人人射人人 | 欧美亚洲性色影视在线 | 中文字幕日韩一区二区三区不 | 国产欧美日本 | 国产高清在线精品一区二区三区 | 一级爱视频 | 狠狠色狠狠色综合系列 | 国产日韩视频一区 | 中国第一毛片 | 久久久免费的精品 | 久久大香香蕉国产免费网站 | 日韩一区二区三区中文字幕 | 欧美成人中文字幕在线视频 | 在线观看深夜 | 欧美一区二区三区男人的天堂 | 欧美国产在线视频 | 国产一区视频在线 | videos欧美黑白爆交 | 国产日韩欧美视频在线 | 国产成人综合亚洲动漫在线 | 91免费视 | 狠狠色综合久久久久尤物 | 精品亚洲福利一区二区 | 国产高清在线精品一区在线 | 亚洲va欧美 | 一个人看的www视频在线播放 | xxxx性xx另类 | 人人做人人澡人人人爽 | 国产精品手机在线 | 激情综合丁香 | 免费观看一级一片 | 91亚洲成人 | 久久精品国产大片免费观看 | 一级特黄aaa大片在 一级特黄aaa大片在线观看 | 天天干天日| 国产亚洲成在线播放va | 91av短视频| 天天操天天干天天干 |
最熱文章
最新文章
  • 阿里云上云鉅惠,云產(chǎn)品享最低成本,有需要聯(lián)系,
  • 卡爾蔡司鏡片優(yōu)惠店,鏡片價格低
  • 蘋果原裝手機殼