摘要:概念是服務器發送到用戶瀏覽器并保存在瀏覽器上的一塊數據,它會在瀏覽器下一次發起請求時被攜帶并發送到服務器上。例如,如果設置了,則瀏覽器訪問其子域名如也會發送。的值可以被修改,,再次刷新頁面,重新發送請求,服務端控制臺就會打印。
概念
來做個實驗</>復制代碼
Cookie是服務器發送到用戶瀏覽器并保存在瀏覽器上的一塊數據,它會在瀏覽器下一次發起請求時被攜帶并發送到服務器上。——MDN
服務端代碼
</>復制代碼
const http = require("http")
const path = require("path")
const url = require("url")
const fs = require("fs")
http.createServer((req, res) => {
let {
pathname,
search
} = url.parse(req.url)
let cookie = req.headers.cookie
console.log(JSON.stringify(cookie))
if (pathname === "/") {
const file = path.resolve(__dirname, "./static/index.html")
fs.readFile(file, (err, data) => {
res.writeHead(200, {
"Content-Type": "text/html",
"Set-Cookie": ["author=nbb3210", "description=genius"]
})
res.write(data.toString())
res.end()
})
} else {
res.end(pathname)
}
}).listen(3210)
./static/index.html內容如下
</>復制代碼
Cookie Cookie
這里推薦一款chrome插件,EditThisCookie,方便進行cookie的管理
啟動服務端,當我們第一次訪問http://localhost:3210/時,服務端控制它打印出undefined;當我們刷新頁面,再次訪問http://localhost:3210/時,控制臺打印出"author=nbb3210; description=genius"。
"author=nbb3210; description=genius"是由服務器通過設置響應頭
</>復制代碼
res.writeHead(200, {
"Set-Cookie": ["author=nbb3210", "description=genius"]
})
// 響應頭
HTTP/1.1 200 OK
Content-Type: text/html
Set-Cookie: author=nbb3210
Set-Cookie: description=genius
Date: Wed, 13 Dec 2017 12:35:39 GMT
Connection: keep-alive
Transfer-Encoding: chunked
發送給瀏覽器,下次發送請求時,瀏覽器便會在請求頭上帶上這段信息。
</>復制代碼
// 瀏覽器第一次訪問服務端時發送的請求頭
GET / HTTP/1.1
Host: localhost:3210
Connection: keep-alive
Cache-Control: max-age=0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36
Upgrade-Insecure-Requests: 1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
</>復制代碼
// 瀏覽器第二次訪問服務端時發送的請求頭,包含有了cookie信息
GET / HTTP/1.1
Host: localhost:3210
Connection: keep-alive
Cache-Control: max-age=0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36
Upgrade-Insecure-Requests: 1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Cookie: author=nbb3210; description=genius
這樣,服務端就可以分辨出不同瀏覽器端發來的請求,記錄用戶的狀態,同樣的請求,因為cookie的不同會有不同的響應。總而言之,借助cookie,服務端能區分出“你是誰?”,從而記起“你之前干了啥”
cookie的屬性 Domain, Path服務端設置cookie時,可以設置domain,path,從而確定該cookie的作用域。
例如,如果設置了Domain=mozilla.org,則瀏覽器訪問其子域名(如developer.mozilla.org)也會發送cookie。如果不設置domain,默認為域名A(網站A)向瀏覽器發送的cookie,只有在瀏覽器再次向域名A(網站A)發送請求時才會被帶上。
這里的path匹配scheme:[//[user[:password]@]host[:port]][/path][?query][#fragment]中的path。例如,在上面的實驗中,修改代碼
</>復制代碼
"Set-Cookie": ["author=nbb3210; Path=/abc", "description=genius"]
用插件清除cookie,分別訪問http://localhost:3210/,http://localhost:3210/abd,http://localhost:3210/abc,http://localhost:3210/,服務端控制臺分別打印出undefined,"description=genius","author=nbb3210; description=genius","description=genius",因為只有第三次的url與cookie的path設置匹配。
HttpOnlycookie的值可以被修改,document.cookie="author=ahhh",再次刷新頁面,重新發送請求,服務端控制臺就會打印"description=genius; author=ahhh"。
如果把自己的cookie修改成別人的cookie,那么就可以偽裝成別人,向服務端發送請求,這里的話。。。
如果cookie被設置了HttpOnly,那么再發送請求時,cookie會被帶上,而瀏覽器端JavaScript無法修改該cookie。
例如,在上面的實驗中,修改代碼
</>復制代碼
"Set-Cookie": ["author=nbb3210; HttpOnly", "description=genius"]
用插件清除cookie,兩次訪問http://localhost:3210/,服務端控制臺分別打印出undefined,"author=nbb3210; description=genius",其后,打開瀏覽器控制臺,
</>復制代碼
> document.cookie
< "description=genius"
// 而 author=nbb3210 對于JavaScript來說是不可見的了
再次設置cookie
</>復制代碼
> document.cookie = "author=ahhh"
< 控制臺打印 "author=ahhh"
并刷新頁面,重新訪問http://localhost:3210/,服務端控制臺仍打印"author=nbb3210; description=genius"
Secure只有在安全連接的https時,cookie才會被發送
Expires, Max-Age前面的屬性確認了cookie在什么時候會被發送,Expires,Max-Age確定了cookie在什么時間范圍內有效。如果不設置這兩個屬性,cookie在瀏覽器關閉時就會被刪除,所以在關閉瀏覽器后,再次訪問http://localhost:3210/,服務端控制臺會打印undefined
Max-Age設置了cookie從被創建到消失持續的時間(s),如修改代碼
</>復制代碼
"Set-Cookie": ["author=nbb3210; Max-Age=30", "description=genius"]
用插件清除cookie,兩次訪問http://localhost:3210/,服務端控制臺分別打印出undefined,"author=nbb3210; description=genius",超過30s后再次訪問http://localhost:3210/,服務端控制臺打印出"description=genius",超過30s后,author=nbb3210失效了。
Expires指定了過期時間GMT,如果修改代碼
</>復制代碼
let date = new Date()
date.setTime(date.getTime() + 30 * 1000)
...
"Set-Cookie": [`author=nbb3210; Expires=${date.toUTCString()}`, "description=genius"]
其作用與設置Max-Age為30s的效果一樣
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/92114.html
摘要:瀏覽器對這種行為進行了限制。大多數情況下,該請求會失敗,因為他要求的認證信息。在請求頭中添加自定義例如在知乎中給文章點贊結合中對的的介紹,知乎的這種方式被稱為。 概念 CSRF,Cross Site Request Forgery,跨站請求偽造。 為什么跨站的請求需要偽造? 因為瀏覽器實現了同源策略,這里可以將站和源視為同一個概念。 同源策略 The same-origin polic...
摘要:上一篇文章簡單介紹了在本地開發環境中搭建服務端和客戶端,對單點登錄過程有了一個直觀的認識之后,本篇將探討單點登錄的實現原理。因此引入服務端作為用戶信息鑒別和傳遞中介,達到單點登錄的效果。為該流程的實現類。表示對返回結果的處理。 上一篇文章簡單介紹了 CAS 5.2.2 在本地開發環境中搭建服務端和客戶端,對單點登錄過程有了一個直觀的認識之后,本篇將探討 CAS 單點登錄的實現原理。 一...
閱讀 604·2021-10-08 10:20
閱讀 1493·2021-09-23 11:22
閱讀 3220·2019-08-30 15:55
閱讀 1601·2019-08-28 18:25
閱讀 1865·2019-08-28 18:14
閱讀 1237·2019-08-26 11:37
閱讀 2901·2019-08-26 10:18
閱讀 2427·2019-08-23 18:39