只是集思廣益，我正在建設的Web應用程序的一些想法。無會話設計是否可行？
Web的基石之一是會話處理：讓用戶登錄，發送帶有魔術二進制編碼精靈灰塵的cookie，然後盲目地信任用戶。
我只是想知道是否可以完全消除通常使用它的web應用程序的「傳統」會話，例如，一家網上商店。
這個想法是有一個'服務器端會話'，不使用SessionID或任何東西，而是用戶名。所以每個用戶只有一個會話，而不是更多。這將允許諸如持久性購物車之類的東西起作用。
認證的處理方式與Web服務的工作方式類似：在每個頁面視圖上都需要進行HTTP摘要認證。
忽略匿名訪問者必須以不同方式處理的事實，您認爲這種方法是可行的嗎？或者長期來看，用於持續認證的額外流量/負載是否會成爲交易中斷者？
類似REST的實現，例如ASP.NET MVC根本不需要會話狀態。
您應該只使用會話。即使它自己的會話實現：例如。 cookie包含用於存儲服務器信息的隨機密鑰。必須使用Cookie，否則您必須使用指定關鍵字的查詢參數對網站上的所有鏈接進行編碼 - 不好的主意！
然後，我會在數據庫中存儲「會話密鑰」或每個你想要調用它的人員用戶名。
當用戶登錄到您的站點時，只需恢復其以前的「會話」即可。
除了查詢參數選項，這是一個壞主意，您可以通過IP地址跟蹤用戶。但這又是一個可怕的主意！例如。許多建築物的互聯網IP數量有限，內部計算機數量也多了很多倍。
沒有好方法可以在不使用cookies的情況下跟蹤用戶。
是的，也許你可以使用HTTP身份驗證，但爲什麼打擾？你只是要介紹新的問題，並對你的用戶界面進行限制。
我不必編碼任何鏈接，因爲每個用戶只有一個會話，並且我知道用戶是誰，因爲他們必須爲每個請求進行身份驗證 - 所以我已經有了「好」的密鑰。 – 2010-10-26 18:06:55
如果你不使用cookies，但是你不需要指望http驗證總是隨每個請求一起發送，所以你知道這個人是？我以前沒有嘗試過。您將希望所有請求都通過安全連接。不能使用http，因爲我相信每次請求都會以純文本格式發送http認證。此外，您無法提供註銷方式。 – 2010-10-28 20:13:20
首先，我們根本不使用會話。
我們發現利用會話複雜的代碼沒有任何好處。甚至考慮使用會話狀態只有兩個原因。首先是減少流量到您的SQL服務器..但是，對於負載平衡的Web服務器等，會話必須存儲在SQL服務器......哪種消除它的第一點。但它比這更糟，因爲會話必須被檢索，反序列化，序列化並存儲在每一個頁面加載中。
第二個原因是不讓瀏覽器在每次請求時都將用戶標識傳遞迴應用程序。然而，「會話劫持」是一個相當簡單的訣竅，很少被考慮到。
因此，我們使用一個高度加密的cookie，其中包含非可猜測的值，可準確指出用戶是誰。我們將這一點與一個不斷變化的，不可猜測的請求ID結合起來，並且消除了會話狀態（這是不必要的開銷），同時提高了所有的安全性。
Cookie可以被盜嗎？當然，但它的生命非常有限，這是兩次回傳之間的時間。這意味着它會被發現相當快速的妥協。
所以，我不會說會話是網絡的「角落石頭」。相反，我會說他們是柺杖，經常使用不當，應該避免出於安全和性能的原因。
所有這一切都說，你要把這個綁定到用戶ID的唯一方法是如果你強迫你的用戶在購物之前登錄/創建帳戶..除非沒有其他人會去做選擇，但要在您的網站上。
哦，不要把我的話：
4GuysFromRolla.com -> Session variables are evil.
aps.net -> Are session variables still evil?
Scott Hansleman -> Moving Viewstate to Session注重以粗體覆蓋內存消耗的一部分，它的留周圍太長能力。
Coding Horror -> Your Session has timed out這個細節只是一些與使用會話相關的問題
Wikipedia -> Session Hijacking什麼清單將是完整的，沒有鏈接到維基百科？
因此，如果有人在使用您的網站，並且最新的加密密鑰是「1234」，那麼當它們回來時會消失幾個小時，該密鑰是否仍然有效？如果是這樣，那麼除了更改每個請求之外，您如何將它們暴露爲標準.Net會話？無論如何，從一臺機器到另一臺機器都有一把鑰匙，活動將恢復正常，對吧？我瞭解，如果原始用戶繼續使用該網站，您就會知道有人試圖攻擊您，並且此「安全漏洞」已最小化，但它仍然存在，對不對？ – Matt 2010-10-26 22:06:49
@Matt：首先我們告訴cookies在非常短的時間段後過期。其次，我們對自己測試的cookie中的值進行了加密，這可以讓我們在重播時強制cookie過期。當然，如果他們偷走了最後一個，那麼他們可以在幾分鐘後重放它。但是，這必須是一個非常有針對性的攻擊工作。 – NotMe 2010-10-26 22:30:36
我明白了。那麼你如何處理過期的cookies？我正在考慮某人在任務中間離開計算機時回來，然後他們的cookie已經過期，所以他們的工作將會丟失。當然，您的網站要求可能會使這個問題沒有意義。我對您的網站/商業需求一無所知。只是好奇。 – Matt 2010-10-27 18:24:00
這實際上幾乎是一個傳統的會話 - 提供一個唯一的標識符來區分瀏覽器的「會話」，你所做的只是把它綁定到用戶名而不是隨機變量。
我會說只是非常小心你如何生成你的令牌，如果它是可重複的，你可以很容易地通過生成某人elses會話並將其卡入到cookie中來實現會話固定攻擊的目標。這就是會話通常是隨機的獨特價值的原因。
這個想法是沒有令牌。沒有什麼會發送給客戶端 - 沒有cookie，沒有花哨的URL，什麼也沒有。相反，HTTP驗證每個請求。 – 2010-10-26 19:01:04
HTTP身份驗證會在每個請求上發送自己的內容。你只是不要惹它，服務器和客戶端。 – Matt 2010-10-26 21:58:08
這個想法是有一個'服務器端會話'，不使用SessionID或任何東西，但用戶名。所以每個用戶只有一個會話，而不是更多。這將允許諸如持久性購物車之類的東西起作用。
這只是一個會話，但使用用戶名作爲會話標識符 - 這會導致各種各樣的問題 - 即使您對其進行加密，它也會對重放攻擊開放。您無法更改每個請求的加密，因爲當用戶打開第二個窗口或按下後退按鈕時，該加密將會中斷。
您不能依賴客戶端地址 - 多個用戶可能共享一個NAT地址，同一個用戶可能會從一個負載均衡代理羣集的後面訪問您的站點。
像一個執着的購物車
......意味着你有服務器端數據的客戶 - 因爲這數據的大小會有所不同，你不能把它存儲在URL也不在cookie中。
預計每個單頁面視圖上的HTTP摘要認證。
這假設您爲每個用戶創建帳戶，並且您不關心不同客戶端使用的相同用戶標識的影響。我不認爲這需要比傳統會話更多的處理 - ，但它仍然是基於網絡的會話管理，與傳統方法相比，它們具有不同的問題和漏洞集合。
這聽起來像你要求服務器端會話，而不是基於cookie的會話。會話狀態存儲在數據庫中。然後在每個頁面加載中，您可以查閱會話數據庫以提取所有適當的用戶相關信息。這聽起來像你的意思？ – jcolebrand 2010-10-26 17:52:15
@drachenstern是和否。與會話的事情是，客戶端有一個會話ID，允許他完全規避授權。基本上我的想法是一個Session，其中UserName是SessionID。 – 2010-10-26 18:04:47
〜我覺得你錯過了一些基本的東西在這裏...你必須有對大多數人的會話ID授權令牌，因此，舉例來說，這裏是我的身份驗證令牌我現在的web應用程序'45BE8B86E43F81228307F9B8D8F1B37D68F110295DC3875B977AA7CDC11B37628F36 F6852F21BCFB16E7FC16D057603C32431425603AC11D333661329EE34BD09084917D 9145FC2A63C63D82E3A2C5259DD3E67899C564110FA1D1AC4A623553C32D7402819C 5668EABC9C4A2A386FE008EACAB822D750E80A6F58BF50CC9AFD15D7CA2D5784B723 36FFC4F1CF08FB1C9AFBF98301942B72983EF273CA30A376E1D110B1'（當然，我正在使用ASP.NET WebForms，所以有這個） – jcolebrand 2010-10-26 18:09:38