看板 Ajax 關於我們 聯絡資訊
※ 引述《LaPass (LaPass)》之銘言: : 標題: Re: [問題] 靠AJAX就不用使用SESSION或COOKIE? : 時間: Sun May 13 00:41:06 2012 : ※ 引述《paulsets (阿光光)》之銘言: : : 以下問題內容稍長,麻煩各位網友見諒... : : 以下問題相信大家都會碰到 -> : : - 因為HTTP協定具有無狀態性(stateless),新的網頁頁面不會知道使用者前一次網頁 : : - 頁面的狀態,因此為了要避免使用者在進入每個網頁頁面重複輸入帳號密碼, 我很好奇你有沒有用任何語言實做過 http 的溝通模擬? 如果你有寫過(也建議你寫來玩看看),應該可以比較清楚 session / cookie 在整個溝通過程中扮演的是什麼角色。 從頭說起吧… 一般所謂的 stateless 指的是每一個 request 都是屬於「獨立」的 request, 也就是說,一個請求在發送 / 處理完畢後,client / server 兩端馬上就遺忘了 這個請求(或著應該說沒有記起來比較恰當), 反過來說,state protocal 是 client / server 兩端持續在溝通的一個過程, 在這個過程裡 client / server 經常會處於「檢查對方式否還存活」、「保持等待」 等等一類的狀態,而每個 request 都可以視為是整個大 request 循環的一部分, 因為實際上通訊仍然是一來一往,只是 request / response 的驗證都由底層作掉了 難道你以為 FTP / websocket 就沒有類 session 的機制嗎? XD : : - 所以會使用 SESSION or COOKIE or HIDDEN FIELD,儲存使用者的授權狀態。 所以是的,當一個 stateless protocal 底層無法去處理驗證機制時, 我們就會需要去作額外的驗證 / 資訊傳遞在上面, 像是透過 cookie 這一類的 client / server 額外溝通能力, : : - 但是使用大量 SESSION,會增加 SERVER 端的負擔。而改使用 COOKIE or 大量使用者使用 session 時可能會對主機有極輕微的負擔, 實際情況是,主機遠在 session io 出問題前就會因為過多連線數而被擊墜了 XD 此外就像其他人提到,這可以挪進記憶體(mmc)裡來作以迴避掉硬碟 io, 但之所以要挪進去經常不是基於 io loading 的考量, 而是為了要能處理多主機的 cross session 這件事… : : - HIDDEN FIELD 方式,則會有 COOKIE 資料遭偷竊或遭惡意更改的風險。 (hidden input 沒有太大意義…略過不提) 不知道你有沒有試過,當 cookie 被拔掉(禁用)的時候,session 是無法使用的, 在 http 裡 client / server 溝通的流程(cookie 部份)是這樣, ※ client 送出一個包含 cookie 資訊的 header, ※ server 在接收到之後,依據程式需求異動的 cookie 內容, 然後把 cookie 資料放在 header 裡丟回給 client, ※ client 在收到後更新自己的 cookie 儲存, 所以 client / server 在背後的資料傳遞上是依賴 cookie 的, (其實應該是說,從 client -> server 有很多方式, 但從 server -> client 這個部份只有兩個選擇,cookie 或 content output) 而 session 這件事其實就是 server 在 session 啟動後產生一個 session id, 並且把 id 值寫進 cookie 裡,所以從此 client 送過來的時候, server 就依照這組 cookie 內的 id 去取出相對應的 session 資料, 的確,這聽起來很危險,只要任何人拿到了你當下 cookie 內的 session id, 就有可能偽造一個登入狀態, 所以對 cookie 的存取在基本上就有著不能跨網域存取的規範條件, 你連上來我的網站,我不應該(也不能)去讀取你在其他網站上的 cookie 資料, 當然有一些人和一些手法想要解開這限制 XD 不過幸好目前沒有什麼太大的漏洞顯露出來… 換句話說,你所擔心 cookie 資料遭竊這件事, 現在主要都發生在以下幾個情況: 1)你的電腦有額外的不明程式在蒐集你的 cookie 並且複製利用它來作偽登入。 2)從你的電腦到主機端,這個網路的路徑節點上有人監聽竊取你的 cookie 資料,    並且複製利用它來作偽登入。 以上這兩件事,無論你用 cookie / session / websocket 之類, 它其實都還是有可能會發生, 網路上流動的資訊永遠沒有安全可言。 所以到頭來,大家在嘗試去作一個「可靠、安全的連線時」, 依賴的都會是加密措施,就像板友提到的數位簽章, : : 因次,想請問靠 AJAX 解決 HTTP 無狀態性衍生問題的可能性? : : 可能的解決方式 -> : : - 通常網站會有許多子頁面互相連結例如,index.htm, login.htm, list.htm : : - 但想請問如果一個網站只有一個子頁面,可以看成顯示容器,在使用者進行第一次 : : - 授權認證後使用者欲讀取新的頁面內容時,網站都使用 AJAX 方式讀取新頁面內容 : : - (XML)與新的排版方式(CSS),再搭配 JS 變換網頁的顯示內容。 : : 既然網站沒有兩個以上的子頁面,也就是沒有HTTP協定具有無狀態性, : : => 是不是就等於使用 AJAX 就可以不使用 SESSION or COOKIE or HIDDEN FIELD? Ajax 指的是什麼?是 Asynchronous JavaScript and XML, 我想你原本的意思應該是指 Ajax 應用上常見的「動態更新內容」這個效果, 但是那實際上是 javascript 去調用 XMLHTTP 相關 API 來對 server 作存取的 一種方式啊,他走的仍舊是 http,header 一樣會送 cookie, 如果 XMLHTTP 對主機作資訊存取的時候會迴避 cookie 那這個技術真的就完了 XD : : 不知道你有沒有寫過client-server的程式 : 我是指使用純socket寫的那種 : 至於純ajax應該還辦不到 : 因為ajax還是需要傳遞變數之類的東西.... : 本質上還是傳統的方式 (那種一去一回的溝通形式叫什麼?我忘記了...) : html5 出現 websocket了 : 我在想,應該可以使用websocket寫出類似的東西 : 主頁面只有一個 : 他載入一個js寫的顯示系統,負責處理介面顯示,以及訊息處理等工作 : 剩下的就完全交給websocket去溝通 : 那個顯示系統再依照websocket收到的訊息,顯示內容 : 只是 : 要寫出這種東西..... : js的技能需要點到很高..... : 而且js還有瀏覽器問題要處理,比一般的連線程式麻煩很多 : -- : ※ 發信站: 批踢踢實業坊(ptt.cc) : ◆ From: 125.233.153.200 : 推 UniFish:websocket目前的問題在於各瀏覽器版本不同, 甚至不支援 05/13 22:40 : → LaPass:嗯~ 這是三至五年後的未來會使用的方式 05/14 02:03 : 推 paulsets:謝L大,這種新技術的確很符合之前的疑問 (筆記中...) 05/14 13:08 如果是從「一次持久性的連線」來考慮,的確 websocket 可以作到, 或著應該說,目前相關的 comet 技術都是在嘗試模擬這件事, 但回歸本質它仍舊是一個 request / response 的來回傳遞, 只是雙方主機 / 資料的驗證由我們手動處理(依賴 cookie)改換為底層處理, 如果你被不明程式炸到,或著路由中有人擷取封包, 一切的資料還是可以被入侵 / 利用 / 竄改的, 真正的關鍵還是在於資料或驗證的加解密啊… 話說回來,這個(這類)技術棘手的地方倒不覺得是在瀏覽器支援上, 而是一般情況使用這個技術的最大考量…它到底會不會榨乾主機 XDDD 希望有回答到你的問題。 -- 最近越來越有嘴巴說不要身體很老實的情況 XD 一直想說不回不回不回結果又乖乖坐下來開始打…(剁手) -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 114.45.233.66
chrisQQ:推這篇,說得很詳細! 05/15 03:22
knives:推 05/15 10:56
mervynW:推 "嘴巴說不要身體很老實" 05/15 12:22
sk1765:這篇寫得真的不錯 我個人給你m 也給你讚 可惜我不能 05/15 12:36
※ 編輯: gpmm 來自: 175.181.108.101 (05/15 13:40)
Foremanytz:好文推 05/15 18:03
TonyQ:反過來了吧,大多是從記憶體挪進 disk,避免記憶體爆量吧 05/15 20:50
gpmm:樓上說的是 session 嗎? XD 05/15 21:36
fillano:補充一下,websocket在交握時,也可以使用cookie的 05/16 15:50
gpmm:感謝費公指點 05/16 15:53