Cookies
浏览器的开发者在很早的时候就已经意识到, HTTP’s 的无状态会对Web开发者带来很大的问题,于是(cookies)应运而生。 cookies 是浏览器为 Web 服务器存储的一小段信息。 每次浏览器从某个服务器请求页面时,它向服务器回送之前收到的cookies
来看看它是怎么工作的。当你打开浏览器并访问 google.com
,你的浏览器会给Google发送一个HTTP请求,起始部分就象这样:
GET / HTTP/1.1
Host: google.com
...
当 Google响应时,HTTP的响应是这样的:
HTTP/1.1 200 OK
Content-Type: text/html
Set-Cookie: PREF=ID=5b14f22bdaf1e81c:TM=1167000671:LM=1167000671;
expires=Sun, 17-Jan-2038 19:14:07 GMT;
path=/; domain=.google.com
Server: GWS/2.1
...
注意 Set-Cookie
的头部。你的浏览器会存储cookie值( PREF=ID=5b14f22bdaf1e81c:TM=1167000671:LM=1167000671
) ,而且每次访问google 站点都会回送这个cookie值。 因此当你下次访问Google时,你的浏览器会发送像这样的请求:
GET / HTTP/1.1
Host: google.com
Cookie: PREF=ID=5b14f22bdaf1e81c:TM=1167000671:LM=1167000671
...
于是 Cookies
的值会告诉Google,你就是早些时候访问过Google网站的人。 这个值可能是数据库中存储用户信息的key,可以用它在页面上显示你的用户名。 Google会(以及目前)使用它在网页上显示你账号的用户名。
存取Cookies
在Django中处理持久化,大部分时候你会更愿意用高层些的session 和/或 后面要讨论的user 框架。 但在此之前,我们需要停下来在底层看看如何读写cookies。 这会帮助你理解本章节后面要讨论的工具是如何工作的,而且如果你需要自己操作cookies,这也会有所帮助。
读取已经设置好的cookies极其简单。 每一个HttpRequest
对象都有一个COOKIES
对象,该对象的行为类似一个字典,你可以使用它读取任何浏览器发送给视图(view)的cookies。
def show_color(request):
if "favorite_color" in request.COOKIES:
return HttpResponse("Your favorite color is %s" % \
request.COOKIES["favorite_color"])
else:
return HttpResponse("You don't have a favorite color.")
写cookies稍微复杂点。 你需要使用 HttpResponse
对象的 set_cookie()
方法。 这儿有个基于 GET
参数来设置 favorite_color
cookie的例子:
def set_color(request):
if "favorite_color" in request.GET:
# Create an HttpResponse object...
response = HttpResponse("Your favorite color is now %s" % request.GET["favorite_color"])
# ... and set a cookie on the response
response.set_cookie("favorite_color",
request.GET["favorite_color"])
return response
else:
return HttpResponse("You didn't give a favorite color.")
你可以给 response.set_cookie()
传递一些可选的参数来控制cookie的行为,详见表14-1。
表 14-1: Cookie 选项
参数 | 缺省值 | 描述 |
---|---|---|
max_age |
None |
cookie需要延续的时间(以秒为单位)如果参数是None ,这个cookie会延续到浏览器关闭为止。 |
expires |
None |
cookie失效的实际日期/时间。它的格式必须是: "Wdy, DD-Mth-YY HH:MM:SS GMT" 。如果给出了这个参数,它会覆盖max_age 参数。 |
path |
"/" |
cookie生效的路径前缀。浏览器只会把cookie回传给带有该路径的页面,这样你可以避免将cookie传给站点中的其他的应用。当你不是控制你的站点的顶层时,这样做是特别有用的。 |
domain |
None |
domain参数意味着cookie可以生效的站点。你可以使用这个参数来让除了你本域之外的其他站点来访问cookie。例如:domain=".example.com" ,这样设置意味着example.com站点(http://www.example.com,www2.example.com ...所有example.com的子站点)也可以访问你的cookie。如果domain设置为None,这个cookie只能被你本域读取。 |
secure |
False |
如果设置为True ,浏览器将通过HTTPS来回传cookie。 |
好坏参半的Cookies
也许你已经注意到了,cookies的工作方式可能导致的问题。让我们看一下其中一些比较重要的问题:
- cookie的存储是自愿的,一个客户端不一定要去接受或存储cookie。 事实上,所有的浏览器都让用户自己控制 是否接受cookies。如果你想知道cookies对于Web应用有多重要,你可以试着打开这个浏览器的 选项: 尽管cookies广为使用,但仍被认为是不可靠的的。这意味着,开发者使用cookies之前必须 检查用户是否可以接收cookie。
- Cookie(特别是那些没通过HTTPS传输的)是非常不安全的。因为HTTP数据是以明文发送的,所以特别容易受到嗅探攻击。也就是说,嗅探攻击者可以在网络中拦截并读取cookies,因此你要绝对避免在cookies中存储敏感信息。这就意味着您不应该使用cookie来在存储任何敏感信息。 还有一种被称为”中间人”的攻击更阴险,攻击者拦截一个cookie并将其用于另一个用户。第19章将深入讨论这种攻击的本质以及如何避免。
即使从预想中的接收者返回的cookie也是不安全的。在大多数浏览器中您可以非常容易地修改cookies中的信息。有经验的用户甚至可以通过像mechanize(http://wwwsearch.sourceforge.net/mechanize/) 这样的工具手工构造一个HTTP请求。
因此不能在cookies中存储可能会被篡改的敏感数据。在cookies中存储
IsLoggedIn=1
,以标识用户已经登录。犯这类错误的站点数量多的令人难以置信;绕过这些网站的安全系统也是易如反掌。
{$ activeFileHint $}