更新语句
This commit is contained in:
22
6.1.md
22
6.1.md
@@ -1,30 +1,30 @@
|
||||
#6.1 session和cookie
|
||||
session和cookie是网站浏览中较为常见的两个概念,也是比较难以辨析的两个概念,但它们在用户浏览需要认证的服务页面以及页面统计中却相当关键。首先我们先来了解一下session和cookie怎么来的?我们先来考虑一个问题:
|
||||
session和cookie是网站浏览中较为常见的两个概念,也是比较难以辨析的两个概念,但它们在浏览需要认证的服务页面以及页面统计中却相当关键。我们先来了解一下session和cookie怎么来的?考虑这样一个问题:
|
||||
|
||||
如何抓取一个访问受限的网页?如新浪微博好友的主页,个人微博页面等。
|
||||
|
||||
显然,通过浏览器,我们可以手动输入用户名密码来访问页面,而所谓的“抓取”,其实就是使用程序来模拟完成同样的工作,因此我们需要了解“登陆”过程中到底发生了什么。
|
||||
显然,通过浏览器,我们可以手动输入用户名和密码来访问页面,而所谓的“抓取”,其实就是使用程序来模拟完成同样的工作,因此我们需要了解“登陆”过程中到底发生了什么。
|
||||
|
||||
对于未登录的用户系统跳转到了登陆页面,用户输入用户名和密码之后POST给远端的服务器,通过验证之后跳转到了微博首页,那么服务器如何验证我们访问其他受限制的页面呢?由于HTTP协议是无状态的,显然,服务器不可能知道我们上一秒刚刚登录成功。当然,最简单的解决方案就是所有的请求里面都带上用户名和密码,这样虽然可行,但大大加重了服务器的负担(对于每个request都需要到数据库验证),也大大降低了用户体验(每个页面都需要重新输入用户名密码,每个页面都带有登录表单).
|
||||
当用户来到微博登陆页面,输入用户名和密码之后点击“登录”后浏览器将认证信息POST给远端的服务器,服务器执行验证逻辑,如果验证通过,则浏览器会跳转到登录用户的微博首页,在登录成功后,服务器如何验证我们对其他受限制页面的访问呢?因为HTTP协议是无状态的,所以很显然服务器不可能知道我们已经在上一次的HTTP请求中通过了验证。当然,最简单的解决方案就是所有的请求里面都带上用户名和密码,这样虽然可行,但大大加重了服务器的负担(对于每个request都需要到数据库验证),也大大降低了用户体验(每个页面都需要重新输入用户名密码,每个页面都带有登录表单)。既然直接在请求中带上用户名与密码不可行,那么就只有在服务器或客户端保存一些类似的可以代表身份的信息了,所以就有了cookie与session。
|
||||
|
||||
所以自然就产生了第一种解决方案:cookie,简而言之就是在本地计算机保存一些用户操作的历史信息(当然包括登录信息),并在用户再次访问该站点时浏览器通过HTTP协议将本地cookie内容发送给服务器,从而完成验证,或继续上一步操作。
|
||||
cookie,简而言之就是在本地计算机保存一些用户操作的历史信息(当然包括登录信息),并在用户再次访问该站点时浏览器通过HTTP协议将本地cookie内容发送给服务器,从而完成验证,或继续上一步操作。
|
||||
|
||||
另一种解决方案:session,简而言之就是在服务器上保存用户操作的历史信息。但该方式下,仍然需要将发送请求的客户端与session对象进行对应,所以可以借助cookie机制来获取客户端的标识(即session id),也可以通过GET方式将id提交给服务器。session id,即服务器上session对象文件的名称,由服务器负责产生,保证随机性与唯一性,相当于一个随机密钥,避免在握手或传输中暴露用户真实密码。
|
||||
session,简而言之就是在服务器上保存用户操作的历史信息。但该方式下,仍然需要将发送请求的客户端与session对象进行对应,所以可以借助cookie机制来获取客户端的标识(即session id),也可以通过GET方式将id提交给服务器。session id,即服务器上session对象文件的名称,由服务器负责产生,保证随机性与唯一性,相当于一个随机密钥,避免在握手或传输中暴露用户真实密码。
|
||||
|
||||
##cookie
|
||||
Cookie是客户端的存储空间,由浏览器来维持。cookie是一小段文本信息,伴随着用户请求和页面在Web服务器和浏览器之间传递。用户每次访问站点时,Web应用程序都可以读取cookie包含的信息。打开我们的浏览器设置,里面有cookie隐私数据选项,打开我们可以看到很多我们访问网站的cookie信息,如下图所示:
|
||||
Cookie是由浏览器维持的,存储在客户端的一小段文本信息,伴随着用户请求和页面在Web服务器和浏览器之间传递。用户每次访问站点时,Web应用程序都可以读取cookie包含的信息。浏览器设置里面有cookie隐私数据选项,打开它,可以看到很多已访问网站的cookies,如下图所示:
|
||||
|
||||

|
||||
|
||||
cookie是有时间限制的,根据生命期不同分成两种cookie:会话cookie和持久cookie;
|
||||
cookie是有时间限制的,根据生命期不同分成两种:会话cookie和持久cookie;
|
||||
|
||||
如果不设置过期时间,则表示这个cookie生命周期为浏览器会话期间,只要关闭浏览器窗口,cookie就消失了。这种生命期为浏览会话期的cookie被称为会话cookie。会话cookie一般不保存在硬盘上而是保存在内存里。
|
||||
如果不设置过期时间,则表示这个cookie生命周期为从创建到浏览器关闭止,只要关闭浏览器窗口,cookie就消失了。这种生命期为浏览会话期的cookie被称为会话cookie。会话cookie一般不保存在硬盘上而是保存在内存里。
|
||||
|
||||
如果设置了过期时间(setMaxAge(60*60*24)),浏览器就会把cookie保存到硬盘上,关闭后再次打开浏览器,这些cookie依然有效直到超过设定的过期时间。存储在硬盘上的cookie可以在不同的浏览器进程间共享,比如两个IE窗口。而对于保存在内存的cookie,不同的浏览器有不同的处理方式。
|
||||
|
||||
|
||||
###Go设置cookie
|
||||
Go语言中设置cookie在net/http包中已经有这样的函数,我们来看一下:
|
||||
Go语言中通过net/http包中的SetCookie来设置:
|
||||
|
||||
http.SetCookie(w ResponseWriter, cookie *Cookie)
|
||||
|
||||
@@ -68,7 +68,7 @@ w表示需要写入的response,cookie是一个struct,让我们来看一下co
|
||||
fmt.Fprint(w, cookie.Name)
|
||||
}
|
||||
|
||||
我们看到通过request获取cookie非常方便。
|
||||
可以看到通过request获取cookie非常方便。
|
||||
|
||||
##session
|
||||
|
||||
@@ -87,7 +87,7 @@ session机制本身并不复杂,然而其实现和配置上的灵活性却使
|
||||
如上文所述,session和cookie的目的相同,都是为了克服http协议无状态的缺陷,但完成的方法不同。session通过cookie,在客户端保存session id,而将用户的其他会话消息保存在服务端的session对象中,与此相对的,cookie需要将所有信息都保存在客户端。因此cookie存在着一定的安全隐患,例如本地cookie中保存的用户名密码被破译,或cookie被其他网站收集(例如:1. appA主动设置域B cookie,让域B cookie获取;2. XSS,在appA上通过javascript获取document.cookie,并传递给自己的appB)。
|
||||
|
||||
|
||||
通过上面的一些简单介绍我们了解了cookie和session的一些基础知识,知道他们之间的联系和区别,所以,知其然,还需要知其所以然。磨刀不误砍柴工,授人以渔,做web开发之前,有必要将一些必要知识了解清楚,才不会在用到时捉襟见肘,或是在调bug时候如无头苍蝇乱转。
|
||||
通过上面的一些简单介绍我们了解了cookie和session的一些基础知识,知道他们之间的联系和区别,做web开发之前,有必要将一些必要知识了解清楚,才不会在用到时捉襟见肘,或是在调bug时候如无头苍蝇乱转。接下来的几小节我们将详细介绍session相关的知识。
|
||||
|
||||
## links
|
||||
* [目录](<preface.md>)
|
||||
|
||||
Reference in New Issue
Block a user