讓每個(gè)Http請(qǐng)求都自動(dòng)帶上token

1.將token放到cookie中

這樣每個(gè)http請(qǐng)求就都可以帶上token信息了。

access_token="eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJhWExsdzZEM1pJNWtkSDc2UUdGdVVtc0h1ckFKRTJXeGlZMDF3QmVKYTMwIn0......";
document.cookie = "keycloakToken=" + access_token;

下面以Django的中間件為例，看看后端是怎樣從request中得到token信息。

if not request.META.get('HTTP_COOKIE'): #判斷有沒(méi)有cookie信息。
?? ?print("Debug: can't get the cookie keycloak token");
?? ?return JsonResponse({"detail": NotAuthenticated.default_detail},
?? ??? ?status=NotAuthenticated.status_code)
else:
? ? ? ? if "keycloakToken" in request.COOKIES: # request.COOKIES是字典類型，判斷其中是否有keycloakToken這個(gè)key
?? ? ? ?accessToken =request.COOKIES["keycloakToken"]; #從cookie中取得token信息。
? ? ? ? ? ? print("Debug: the request token in cookie is: " + accessToken);
? ? ? ? else:
? ? ? ? ? ? return JsonResponse({"res": "1", "resMsg": "No Token Provided"},status=401)

2.將token放到某個(gè)http請(qǐng)求的header中

var token="eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJhWExsdzZEM1pJNWtkSDc2UUdGdVVtc0h1ckFKRTJXeGlZMDF3QmVKYTMwIn0........"; ?
?
prepareHeaders() {
? return new Headers({
? ? 'Content-Type': 'application/json; charset=UTF-8',
? ? 'Authorization': 'Bearer ' + token
? });
}
?
addProduct(body: any): Observable<any> {
? return this.http.post(`${this.backendUrl}/api/project/`, body, { headers: this.prepareHeaders() }).map(this.extractData);
}

下面同樣以Django的中間件為例，看看后端是怎樣從request中得到token信息。

#使用key HTTP_AUTHORIZATION從header中獲取token信息。
auth_header = request.META.get('HTTP_AUTHORIZATION').split()
accessToken = auth_header[1] if len(auth_header) == 2 else auth_header[0]

以上只是以token為例，當(dāng)然了，除了token，可以帶上任何你想帶的信息。

3.使用哪種方式更好呢？

為了避開(kāi)CSRF（跨站請(qǐng)求偽造）攻擊，請(qǐng)使用第二種方式，發(fā)送請(qǐng)求的時(shí)候不要將Token放到cookie這個(gè)header里，而應(yīng)該放到自定義的header里。 

token一般存放在哪里

Token一般是存放在哪里？ Token放在cookie和放在localStorage、sessionStorage中有什么不同？

Token是什么？

Token 其實(shí)就是訪問(wèn)資源對(duì)憑證。一般是用戶通過(guò)用戶名和密碼登錄成功之后，服務(wù)器將登錄憑證做數(shù)字簽名，加密之后得到的字符串作為token。

Token存放位置

Token 其實(shí)就是訪問(wèn)資源對(duì)憑證。一般是用戶通過(guò)用戶名和密碼登錄成功之后，服務(wù)器將登錄憑證做數(shù)字簽名，加密之后得到的字符串作為token。

它在用戶登錄成功之后會(huì)返回給客戶端，客戶端主要以下幾種存儲(chǔ)方式：

1、存儲(chǔ)在localStorage中，每次調(diào)用接口的時(shí)候都把它當(dāng)成一個(gè)字段傳給后臺(tái)

2、存儲(chǔ)在cookie中，讓它自動(dòng)發(fā)送，不過(guò)缺點(diǎn)就是不能跨域

3、拿到之后存儲(chǔ)在localStorage中，每次調(diào)用接口的時(shí)候放在HTTP請(qǐng)求頭的Authorization字段里面。token 在客戶端一般存放于localStorage、cookie、或sessionStorage中。

Token 放在 cookie、localStorage、sessionStorage中的不同點(diǎn)？

將Token存儲(chǔ)于localStorage或 sessionStorage

Web存儲(chǔ)（localStorage/sessionStorage）可以通過(guò)同一域商Javascript訪問(wèn)。這意味著任何在你的網(wǎng)站上的運(yùn)行的JavaScript都可以訪問(wèn)Web存儲(chǔ)，所以容易受到XSS攻擊。尤其是項(xiàng)目中用到了很多第三方JavaScript類庫(kù)。

為了防止XSS，一般的處理是避開(kāi)和編碼所有不可信的數(shù)據(jù)。但這并不能百分百防止XSS。比如我們使用托管在CDN或者其它一些公共的JavaScript庫(kù)，還有像npm這樣的包管理器導(dǎo)入別人的代碼到我們的應(yīng)用程序中。

如果你使用的腳本中有一個(gè)被盜用了怎么辦？惡意的JavaScript可以嵌入到頁(yè)面上，并且Web存儲(chǔ)被盜用。這些類型的XSS攻擊可以得到每個(gè)人的Web存儲(chǔ)來(lái)訪問(wèn)你的網(wǎng)站。

這也是為什么許多組織建議不要在Web存儲(chǔ)中存儲(chǔ)任何有價(jià)值或信任任何Web存儲(chǔ)中的信息。 這包括會(huì)話標(biāo)識(shí)符和令牌。作為一種存儲(chǔ)機(jī)制，Web存儲(chǔ)在傳輸過(guò)程中不強(qiáng)制執(zhí)行任何安全標(biāo)準(zhǔn)。

XSS攻擊：Cross-Site Scripting（跨站腳本攻擊）簡(jiǎn)稱XSS，是一種代碼注入攻擊。攻擊者通過(guò)在目標(biāo)網(wǎng)站注入惡意腳本，使之在用戶的瀏覽器上運(yùn)行。利用這些惡意腳本，攻擊者可以獲取用戶的敏感信息如Cookie、SessionID等，進(jìn)而危害數(shù)據(jù)安全。

將Token存儲(chǔ)與cookie

• 優(yōu)點(diǎn)：可以制定httponly，來(lái)防止被JavaScript讀取，也可以制定secure，來(lái)保證token只在HTTPS下傳輸。
• 缺點(diǎn)：不符合Restful 最佳實(shí)踐。 容易遭受CSRF攻擊（可以在服務(wù)器端檢查Refer和Origin）

CSRF：跨站請(qǐng)求偽造，簡(jiǎn)單的說(shuō)，是攻擊者通過(guò)一些技術(shù)手段欺騙用戶的瀏覽器去訪問(wèn)一個(gè)自己曾經(jīng)認(rèn)證過(guò)的網(wǎng)站并運(yùn)行一些操作（如：發(fā)郵件、發(fā)信息、甚至財(cái)產(chǎn)操作如轉(zhuǎn)賬和購(gòu)買商品）。由于瀏覽器曾經(jīng)認(rèn)證過(guò)，所以被訪問(wèn)的網(wǎng)站會(huì)認(rèn)為是真正的用戶操作而去運(yùn)行。這利用了web中用戶身份驗(yàn)證的一個(gè)漏洞：簡(jiǎn)單的身份驗(yàn)證職能保證請(qǐng)求發(fā)自某個(gè)用戶的瀏覽器，卻不能保證請(qǐng)求本身是用戶自愿發(fā)出去的。CSRF并不能夠拿到用戶的任何信息，它只是欺騙用戶瀏覽器，讓其以用戶的名義進(jìn)行操作。

小結(jié)一下：

關(guān)于token 存在cookie還是localStorage有兩個(gè)觀點(diǎn)：

支持Cookie的開(kāi)發(fā)人員會(huì)強(qiáng)烈建議不要將敏感信息（例如JWT)存儲(chǔ)在localStorage中，因?yàn)樗鼘?duì)于XSS毫無(wú)抵抗力。

支持localStorage的一派則認(rèn)為：撇開(kāi)localStorage的各種優(yōu)點(diǎn)不談，如果做好適當(dāng)?shù)腦SS防護(hù)，收益是遠(yuǎn)大于風(fēng)險(xiǎn)的。

放在cookie中看似看全，看似“解決”（因?yàn)槿匀淮嬖赬SS的問(wèn)題）一個(gè)問(wèn)題，卻引入了另一個(gè)問(wèn)題（CSRF）

localStorage具有更靈活，更大空間，天然免疫 CSRF的特征。Cookie空間有限，而JWT一半都占用較多字節(jié)，而且有時(shí)你不止需要存儲(chǔ)一個(gè)JWT。

總結(jié)

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

最新評(píng)論