http連線是無狀態的，但web程式互動中經常又需要狀態。所以目前流行的基本是cookie,session結合方式來管理，cookie中會帶乙個會話標識，如果不用cookie,可能會將會話標識跟在位址列後面。但也有不通過session這樣方式的，使用自定義的方式來維護狀態。但有一點一定要注意，不能用遞增的明碼id來做會話狀態標識，危險性太大。下面舉例說明。
前些時間，發現有個**，是flash做的遊戲，因為玩了遊戲，有積分，積分呢可以**，具體什麼**我就不透露了~~
於是，我就搞個程式玩，下了flash研究了下原始碼，配合firebug看看網路收發網路資料，驚奇的發現該**維持使用者會話是使用遞增的id，也就是說，我只要發個cookie，帶上userid，我就可以去提交積分了，連登入都不用登了。**品也需要人品的，所以獲不獲獎是另外一碼事，但寫這樣的程式還是有樂趣的~~
事後，我一想，如果是這樣的話，那我豈不是可以偽造任何人的資訊了麼？因為cookie可以用js來增刪改的。
我隨即驗證了下，發現想法成立，然後我就再也不敢往下研究了。。。本來是娛樂玩，如果這樣深入下去想搞破壞也不是難事。因為我可以遍歷出所有使用者的資訊，然後，可以以這些使用者的身份提交虛假資訊。也就是說，我可以把中獎人的****給改掉。提交成我的或者錯誤都有可能。但我不敢研究下去了。到此為止，這樣下去，一是我品格不允許，二是可能會搞出事情來，畢竟我只是名普通的程式設計師，家有妻兒，我不要搞出什麼事情來。。。
不知道是不是flash與後台互動時，這方面有什麼障礙。我不太清楚**方為何是用遞增id來維持會話的。
但不管怎樣，請記住一點，千萬不可用明碼遞增的標識來標識會話。太不安全，太危險了，後患無窮。至少也加個密是吧！
Web會話管理
基於token的管理 重新整理安全問題 web應用通常使用的是http請求，但是http是無狀態的，一次請求結束，連線就會自動斷開，伺服器只能知道每個請求的 位址，可是這對會話的管理毫無意義。根本無法對使用者進行認證和許可權控制。於是，就有了相應的方案來解決這問題。常用的方法有三個 在早期的web應...
web會話管理基礎
會話要解決的問題 每個使用者在使用瀏覽器與伺服器進行會話的過程中，不可避免各自會產生一些資料，程式要想辦法為每乙個使用者儲存這些資料，這就是會話要解決的問題。解決會話問題的兩種技術 cookie cookie是客戶端技術，程式把每乙個使用者的資料以cookie的形式寫給使用者各自的瀏覽器，當使用者使...
Web會話管理（追蹤）
背景 http 是無狀態協議，乙個請求，乙個響應，之後誰也不認識誰。為了標識 記錄每個使用者的使用者狀態，根據使用者狀態，推薦個性化服務，描繪出 使用者畫像 出現了會話管理技術 前三個只支援web 優點 使用者狀態 儲存 在客戶端 缺點 文字格式 大小受限 4kb 請求頭 使用者可以清除 禁止 實際...