Cookie and Session
閱讀時間約 4 分鐘
Cookie 的誕生
若先從一個最為陽春的網路溝通方式來看，當一個 Client 端和一個 Server 端發送請求，並由 Server 端處理後進行響應，這一整個過程會因為 http 的無狀態特性，不著痕跡也不留紀錄。問題在於，多數時候留些有用的東西比較好。
假設今天我們透過帳號密碼登入，進到了某個平台服務的會員個人頁面，而這些會員頁面如果沒有登入是無法訪問到的。換句話說，如果在過程中什麼都沒存的話，勢必每一次訪問不同的會員頁面，都需要輸入一次帳號密碼來驗證身分，那想必十分破壞用戶體驗。
Cookie 的概念正是為了要解決這問題而誕生的，在 Client 端第一次發送請求至 Server 端時，Server 端在處理過程中便生成一個標示，也就是 Cookie。這 Cookie 中存了些需要的資料，並且包裝好連同響應一起回覆給 Client 端，讓他在下次發送請求時，可以不用重複麻煩的輸入流程，就可以發送帶有必備資料的請求。
而這些存在於 Client 端的 Cookie 也是會有期限的，若無特別設置的話，Cookie 會在 Client 端瀏覽器被關閉的時刻慘遭清除。若特別去設定，則可以使其持久化，在 Golang 中可以這麼設定他：
避免鬼打牆，我先表明有 import "time" 和 "net/http" 兩個包~！line 3 的部分我設定期限為三天後，line 4 描述了 Cookie 中所需內容，並在 line 5 完成 Cookie 的設置。
Session 的誕生
Cookie 的出現固然解決了大半問題，但仍有些缺陷，比如說她是個存在於客戶端的文件資料，很容易在 Client 端被拿來動手腳的。再者，Cookie 中若包含著機密的資料像是帳號密碼等等，每次發送請求都跟著出去一次，那被攔截或竊聽的風險可就大大提高了。因此便有了 Session 誕生的理由。
同樣是在 Client 端與 Server 端進行首次溝通 hand shaking 時，Server 端生成了一個 Session，可以把它視為一種維持兩端溝通的方案，並存於 Server 端。同時會生成一把與 Session 相對應的鑰匙，也就是 session id，並隨著響應回復至 Client 端。
Session 建立完成後，接下來的溝通 Client 端發送請求時便會帶上這串 session id，送達 Server 端時便會開始查找對應的 Session 以繼續進行溝通。此方法雖可有效提高安全性，但是當多個 Session 囤積在 Server 端時光是想就覺得不對勁，所以仍是要做出適當的抉擇。
使用 Session 就一定可靠嗎？
想想 Cookie 的問題出在哪裡，便可以知道 Session 也有同樣問題，只是不那麼明顯。對於儲存資料的 Cookie ，一旦被有心人士取得其中資料便會發生問題，而 Session id 同理，只不過要再帶上他發送請求給 Server 端進行類似盜用詐欺的行為而已。Session 仍是有風險存在的，那該怎麼辦？
Cookieonly
其中一個方法便是強制 Session id 僅能由 Cookie 在發送請求時帶上，而無法透過 url 引數的方式帶上。同時降 Cookie 設置為 httponly，使其僅能在 http 溝通時被訪問，避免被從其他管道惡意讀取。
Token
另外也可以在每次 Client 端發送請求時，附上一組隨機生成的 Token，並在 Server 端進行重複性驗證，以確保請求的唯一性。
Refresh Session id
每隔一段時間就重新生成一組 Session id 也是個可能的方法，如此ㄧ來便會提高第三方竊取的成本，並增加捕捉到惡意行為的機會。
Ref
https://github.com/astaxie/build-web-application-with-golang
留言0
查看全部
你可能也想看
Google News 追蹤
嘿，大家新年快樂~ 新年大家都在做什麼呢？
跨年夜的我趕工製作某個外包設計案，在工作告一段落時趕上倒數。
然後和兩個小孩過了一個忙亂的元旦。在深夜時刻，看到朋友傳來的解籤網站，興致勃勃熬夜體驗了一下，覺得非常好玩，或許有人玩過了，但還是想寫上來分享紀錄一下~
今天寫文章來學習什麼是「第一方 Cookies」。
## 1. Cookie在LinkedIn廣告中的角色
根據Linkedin的文章[1]，
Cookie 是被設置在網站訪問者的 Web瀏覽器上，
可以幫助 Linkedin 確定廣告被展示給哪些成員，
是衡量廣告效果，改
(1) 收集用戶名單，例如 Email 和手機，未來可做廣告受眾再行銷，例如 FB 廣告、GDN 廣告、Email發送。
(2) 在網站追蹤中，用 GTM 實施「增強型轉換」，讓每一個轉換數據發送時都帶有第一方數據，能讓轉換追蹤更精準，減少受 Cookie 政策的影響。
(3)
xhr
在下面的例子裡，我們首先建立了一個 XMLHttpRequest 物件，並使用 .open() 開啟一個 URL，最後使用 .send() 發出 request。
具體來說步驟有四個：
建立XMLHttpReque
開啟一個請求。
送出請求。
拿到回應後去處理畫面要如何呈現。
與 cookie 相比，localStorage 與 sessionStorage 的機制相對單純，兩者皆是瀏覽器中的儲存空間，與 cookie 最大的不同在於：localStorage 與 ⋯⋯
在瀏覽器環境中有許多的儲存空間，想要查看這些空間的話，可以透過「chrome > Dev Tools > Application > Storage」即能進行查看。
瀏覽器內存空間的差異不僅常常被拿來被當作面試考題，在實務開發中更扮演舉足輕重的角色，今天就想透過這系列的文章深度了解這些瀏覽器內存⋯
前言
這篇文章分享cookie、sessionStorage、localStorage、session的差異，因為前後端溝通常用的就這幾個，我比較常用的是cookie或session，但也是有可能會用到sessionStorage或localStorage的時候，因此想說這邊做個紀錄比較他們的差別
整合測試的時候突然遇到一個突然無法登入產品網站的問題，把程式模組單獨拉出來測試又正常，觀察測試報告後發現出現發生登入異常的時間點並不固定，而且只要發生就會連續發生一段時間，程式被中斷掉。後來確認問題在...
在開發前後端分離架構時，使用兩個不同網域所遇到跨域請求問題。特別是在POST請求時行為差異大，揭示了「簡單請求」與「預檢請求」的關鍵差異。簡單請求不需預檢，但application/json會觸發預檢請求，需透過特定設定解決。分享這篇文章希望幫助開發者有效處理跨域問題。
發送表單用get跟post看起來好像都無所謂，然而事實並非如此，使用GET的風險如下：
安全性問題
機密資訊為何不宜用GET，是因為由GET方法提交的表單會將欄位的key,value顯示於URL上，想像一下如果小明借用你的電腦，查看你的網頁歷史紀錄時就可以看到你的帳密了，多可怕！
再來就是如果
授權碼模式連線流程
用戶端請求自己的伺服器。
伺服器發現用戶沒登入，就導向認證伺服器。
認證伺服器顯示授權頁面，等待用戶授權。
用戶確認授權後，授權頁面會向認證伺服器請求授權碼。
用戶獲取授權碼。
用戶將授權碼傳給伺服器。
伺服器拿授權碼向認證伺服器取得token。
應用註冊
嘿，大家新年快樂~ 新年大家都在做什麼呢？
跨年夜的我趕工製作某個外包設計案，在工作告一段落時趕上倒數。
然後和兩個小孩過了一個忙亂的元旦。在深夜時刻，看到朋友傳來的解籤網站，興致勃勃熬夜體驗了一下，覺得非常好玩，或許有人玩過了，但還是想寫上來分享紀錄一下~
今天寫文章來學習什麼是「第一方 Cookies」。
## 1. Cookie在LinkedIn廣告中的角色
根據Linkedin的文章[1]，
Cookie 是被設置在網站訪問者的 Web瀏覽器上，
可以幫助 Linkedin 確定廣告被展示給哪些成員，
是衡量廣告效果，改
(1) 收集用戶名單，例如 Email 和手機，未來可做廣告受眾再行銷，例如 FB 廣告、GDN 廣告、Email發送。
(2) 在網站追蹤中，用 GTM 實施「增強型轉換」，讓每一個轉換數據發送時都帶有第一方數據，能讓轉換追蹤更精準，減少受 Cookie 政策的影響。
(3)
xhr
在下面的例子裡，我們首先建立了一個 XMLHttpRequest 物件，並使用 .open() 開啟一個 URL，最後使用 .send() 發出 request。
具體來說步驟有四個：
建立XMLHttpReque
開啟一個請求。
送出請求。
拿到回應後去處理畫面要如何呈現。
與 cookie 相比，localStorage 與 sessionStorage 的機制相對單純，兩者皆是瀏覽器中的儲存空間，與 cookie 最大的不同在於：localStorage 與 ⋯⋯
在瀏覽器環境中有許多的儲存空間，想要查看這些空間的話，可以透過「chrome > Dev Tools > Application > Storage」即能進行查看。
瀏覽器內存空間的差異不僅常常被拿來被當作面試考題，在實務開發中更扮演舉足輕重的角色，今天就想透過這系列的文章深度了解這些瀏覽器內存⋯
前言
這篇文章分享cookie、sessionStorage、localStorage、session的差異，因為前後端溝通常用的就這幾個，我比較常用的是cookie或session，但也是有可能會用到sessionStorage或localStorage的時候，因此想說這邊做個紀錄比較他們的差別
整合測試的時候突然遇到一個突然無法登入產品網站的問題，把程式模組單獨拉出來測試又正常，觀察測試報告後發現出現發生登入異常的時間點並不固定，而且只要發生就會連續發生一段時間，程式被中斷掉。後來確認問題在...
在開發前後端分離架構時，使用兩個不同網域所遇到跨域請求問題。特別是在POST請求時行為差異大，揭示了「簡單請求」與「預檢請求」的關鍵差異。簡單請求不需預檢，但application/json會觸發預檢請求，需透過特定設定解決。分享這篇文章希望幫助開發者有效處理跨域問題。
發送表單用get跟post看起來好像都無所謂，然而事實並非如此，使用GET的風險如下：
安全性問題
機密資訊為何不宜用GET，是因為由GET方法提交的表單會將欄位的key,value顯示於URL上，想像一下如果小明借用你的電腦，查看你的網頁歷史紀錄時就可以看到你的帳密了，多可怕！
再來就是如果
授權碼模式連線流程
用戶端請求自己的伺服器。
伺服器發現用戶沒登入，就導向認證伺服器。
認證伺服器顯示授權頁面，等待用戶授權。
用戶確認授權後，授權頁面會向認證伺服器請求授權碼。
用戶獲取授權碼。
用戶將授權碼傳給伺服器。
伺服器拿授權碼向認證伺服器取得token。
應用註冊