禁止了瀏覽器 cookie，session 還可以用嗎？
01-09
瀏覽器禁止了 cookie， session 還可以用嗎？
Session是用戶會話，那麼要實現用戶會話，伺服器端應該有個儲存會話信息的程序存在。Session的服務端服務實現由很多種，常見有磁碟文件保存（PHP默認方式，會阻塞）、MySQL（Discuz! 的自己的實現方式）、Memcached（性能較高的一種實現）、Redis。大致原理就是儲存一個獨一無二的用戶令牌（這裡暫且稱為SessionID吧）和令牌對應的用戶數據，例如這樣：
SessionID | UserID
1A6B78E7 | 195
B6SE3C66 | 0 (默認，未登陸狀態)
E135C338 | 131 （用戶將賬號密碼驗證碼和SessionID發回伺服器後，將UserID改為用戶主鍵值）
客戶端要實現Session就需要從服務端獲取一個SessionID（服務端可以用一個meta tag把SessionID發到客戶端，客戶端用js獲取，方法簡直不要太多），永久性或半永久性地保存在本地（起碼不能再開一次網頁，會話就沒了），每次訪問需要Session的頁面，就將SessionID發出。
想到這裡，難點就只有兩個了，保存和發送。主要難點是前者。
前面有人提到的URL傳參但沒有提到保存方式，永久性或半永久性地儲存，除了Cookie外還有什麼呢？Etag單頁有效並且緩存容易被衝掉，想了想，HTML5新增的LocalStorage就可實現近乎永久性的保存。（IE 8+）解決了客戶端接收和儲存這個問題，那麼發出SessionID就簡單了：1、前端模板實現的全非同步網站，在需要SessionID的請求時，使用：xhr.setRequestHeader("X-SessionID-Header", "B6SE3C66");
這樣就實現了SessionID的收發。
2、非非同步網站，粗暴的做法可以讓JS可以遍歷所有a標籤，判斷host，如果非跨域，則為其href指向鏈接追加SessionID參數，同樣實現了收發。當然也還有更加精細的做法。LocalStorage雖然不如Cookie方便，相對於Cookie來說也是有一定好處的，同域的所有頁面請求都會附加上同個Cookie，這會影響載入速度，很多網站的靜態資源都另外使用了一個域名一部分原因就是這個。LocalStorage的令牌發送是可控的，Cookie的發送是不可控的。
早幾年還沒LocalStorage的時候，我還見過有人在Cookie里保存本地草稿，提交前操作Cookie清除草稿。這兩個東西功能上可以說有些類似，因此一定程度上可以互相替代。可以。可以在url中傳遞sessionID。但是需要你在php.ini裡面開啟一個選項，就是允許在url中存在sessionID。
session 是什麼？
伺服器生成的一個 shit 值，甩給客戶端，客戶端拿著當金牌令箭，只要客戶端有辦法把這個金牌令箭告知伺服器就好了。在這樣的情況下，你怎麼傳遞這個金牌令箭，就看你的個人喜好了。
在這樣的認知下，你應該知道，怎樣使用 session 技術僅看你客戶端和伺服器溝通的方式，什麼 get post shit 隨你喜好了所以說，學東西要多想想為什麼、這樣做的原因是什麼？好處是什麼？不這麼做會怎樣？有沒有更好的設計方案？特別是搞 web 的，不能連我這個沒搞過 web 的人都不如。可以，在每條url中都加上session欄位，這種做法現在在很多老式WAP網站上依然能夠見到，因為當時的具有WAP瀏覽器的手機因為內存小的可憐無法存儲cookie。還有一種辦法就是每個頁面都加一個hidden隱藏域，value寫上session，總之方法很多，靈活變通。
ETag 已經是最要臉的追蹤手段了好嗎。。。試試 authentication cookie
&