这是一个创建于 3530 天前的主题，其中的信息可能已经有所发展或是发生改变。
这个东西大体我是懂的，具体不太明白，什么时候SESSION_START(),又是cookie_read(),序列化的，我就不太懂了，感觉还是理解的不透彻。
 |
1
Septembers 2015-04-30 17:23:12 +08:00
|
 |
2
Scholer 2015-04-30 17:27:10 +08:00  1
一个完善的session机制如下：
服务器生成一个id作为会话的id，同时可以已这个id为基础存储一些数据，整个session的id和数据可以存在文件里，也可以存在数据库里（PHP的session机制默认是存储文件）。 服务器把session的id和数据经过整理、加密等一系类过程作为一个数据（字符串）发送给客户端（浏览器），客户端将这个session存储下来。存储的方式可能有多种，最常用的是cookie（也可以是别的方式，只要保证在自己的web程序中可以取到，比如存在一个form标签里也是可以的）。 客户端（浏览器）发送请求时，带上session数据（大多时候是cookie）一起送给服务器，服务器通过解析这段数据来判断请求来自哪里，已经在这次会话的过程中存储的一些数据（后端）。 session和cookie的关系 cookie是一种存储机制，指的是web服务可以在客户端存储一小段数据。当某个web服务在客户端存储有cookie数据的时候，客户端可以在之后的每次请求中都带上这段数据（浏览器是会自动带上这段数据的）。当然客户端也完全可以选择不带上这段数据，浏览器也可以禁用cookie。 session与cookie的关系在于：在绝大多数的情况下，我们会默认使用cookie来存储session会话的数据，而且现在浏览器都实现了带cookie请求的方式，再加上PHP的session机制，我们不需要考虑怎么去设计并维护一个简单的session会话。 一些网站也会在cookie被禁用的情况下通过其它方式维护session。 |
 |
3
irgil 2015-04-30 17:37:17 +08:00
@Septembers 又不是只有php有cookie和session....
|
 |
5
sallowdish 2015-05-01 00:45:53 +08:00
@Scholer form 里面的一半是token吧，form多次重复submit情况比较特殊，一般也只check一次，所有完全没有必在server写入文件或者DB。而authentication&authorization则可以用session, 每个request都要用来check identity，而且有一定延时性，所以server必须要在expire之前一直记住issue出去的session，所以存cache/memory里面不大好，一来占用关键资源，二来对于fail over抵抗力比较低（server重启一下所有用户都会被要求重新authenticate）
|
|
6
sallowdish 2015-05-01 00:47:43 +08:00 1
@jacob https://auth0.com/blog/2014/01/27/ten-things-you-should-know-about-tokens-and-cookies/ 从第十条倒着往上看比较好，然后前一篇和后一篇感兴趣也可以看看
|
|
9
Scholer 2015-05-01 12:22:45 +08:00
@sallowdish 恩 我只是说下可能的场景~ 实际应用是另外一回事儿
|
Select Language