讓每個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為例，當然了，除了token，可以帶上任何你想帶的信息。

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

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

token一般存放在哪里

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

Token是什么？

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

Token存放位置

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

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

1、存儲在localStorage中，每次調用接口的時候都把它當成一個字段傳給后臺

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

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

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

將Token存儲于localStorage或 sessionStorage

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

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

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

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

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

將Token存儲與cookie

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

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

小結一下：

關于token 存在cookie還是localStorage有兩個觀點：

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

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

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

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

總結

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

最新評論