讓每個Http請求都自動帶上token

1.將token放到cookie中

這樣每個http請求就都可以帶上token信息了。

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

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

if not request.META.get('HTTP_COOKIE'): #判斷有沒有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這個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放到某個http請求的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.使用哪種方式更好呢？

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

token一般存放在哪里

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

Token是什么？

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

Token存放位置

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

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

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

2、存儲在cookie中，讓它自動發(fā)送，不過缺點就是不能跨域

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

Token 放在 cookie、localStorage、sessionStorage中的不同點？

將Token存儲于localStorage或 sessionStorage

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

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

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

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

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

將Token存儲與cookie

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

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

小結(jié)一下：

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

支持Cookie的開發(fā)人員會強烈建議不要將敏感信息（例如JWT)存儲在localStorage中，因為它對于XSS毫無抵抗力。

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

放在cookie中看似看全，看似“解決”（因為仍然存在XSS的問題）一個問題，卻引入了另一個問題（CSRF）

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

總結(jié)

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

最新評論