※ 引述《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 ※ 编辑: gpmm 来自: 175.181.108.101 (05/15 13:40)