彻底搞懂Web前端开发的Cookie、Session机制

1. 1、Cookie 机制
• 1.1 什么是 Cookie
• 1.2 记录用户访问次数
• 1.3 Cookie 的不可跨域名性
• 1.4 Unicode 编码：保存中文
• 1.5 BASE64 编码：保存二进制图片
• 1.6 设置 Cookie 的所有属性
• 1.7 Cookie 的有效期
• 1.8 Cookie 的修改、删除
• 1.10 Cookie 的路径
• 1.11 Cookie 的安全属性
• 1.12 JavaScript 操作 Cookie
2. 2 Session 机制
• 2.1 什么是 Session
• 2.2 实现用户登录
• 2.3 Session 的生命周期
• 2.4 Session 的有效期
• 2.5 Session 的常用方法
• 2.6 Session 对浏览器的要求
• 2.7 URL 地址重写
• 2.8 Session 中禁止使用 Cookie
3. 结语

会话（Session）跟踪是 Web 程序中常用的技术，用来跟踪用户的整个会话

常用的会话跟踪技术是Cookie与Session。

• Cookie通过在客户端记录信息确定用户身份
• Session通过在服务器端记录信息确定用户身份

本文将系统地讲述Cookie与Session机制，并比较说明什么时候不能用Cookie，什么时候不能用 Session。

相关文章推荐阅读：解决 chrome 浏览器请求无法携带 Cookie 问题、如何解决 js 在编写 HTML 通过 document.cookie 写入不了 cookie 的问题

1、Cookie 机制

理论上，一个用户的所有请求操作都应该属于同一个会话，而另一个用户的所有请求操作则应该属于另一个会话，二者不能混淆

例如，用户 A 在超市购买的任何商品都应该放在 A 的购物车内，不论是用户 A 什么时间购买的，这都是属于同一个会话的，不能放入用户 B 或用户 C 的购物车内，这不属于同一个会话。

而 Web 应用程序是使用 HTTP 协议传输数据的

HTTP 协议是无状态的协议。一旦数据交换完毕，客户端与服务器端的连接就会关闭，再次交换数据需要建立新的连接。这就意味着服务器无法从连接上跟踪会话。

即用户 A 购买了一件商品放入购物车内，当再次购买商品时服务器已经无法判断该购买行为是属于用户 A 的会话还是用户 B 的会话了。要跟踪该会话，必须引入一种机制。

Cookie就是这样的一种机制。它可以弥补 HTTP 协议无状态的不足。在Session出现之前，基本上所有的网站都采用Cookie来跟踪会话。

1.1 什么是 Cookie

由于 HTTP 是一种无状态的协议，服务器单从网络连接上无从知道客户身份。怎么办呢？

给客户端们颁发一个通行证吧，每人一个，无论谁访问都必须携带自己通行证。这样服务器就能从通行证上确认客户身份了。这就是 Cookie 的工作原理。

Cookie 实际上是一小段的文本信息。客户端请求服务器，如果服务器需要记录该用户状态，就使用 response 向客户端浏览器颁发一个 Cookie。客户端浏览器会把 Cookie 保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该 Cookie 一同提交给服务器。服务器检查该 Cookie，以此来辨认用户状态。服务器还可以根据需要修改 Cookie 的内容。

查看某个网站颁发的 Cookie 很简单。在浏览器地址栏输入javascript:alert (document. cookie)就可以了（需要有网才能查看）。JavaScript 脚本会弹出一个对话框显示本网站颁发的所有 Cookie 的内容

Tomcat 中 Session 的默认超时时间为 20 分钟。通过setMaxInactiveInterval(int seconds)修改超时时间。可以修改web.xml改变 Session 的默认超时时间。例如修改为 60 分钟：

注意：参数的单位为分钟，而setMaxInactiveInterval(int s)单位为秒。

2.6 Session 对浏览器的要求

虽然 Session 保存在服务器，对客户端是透明的，它的正常运行仍然需要客户端浏览器的支持。这是因为 Session 需要使用 Cookie 作为识别标志。HTTP 协议是无状态的，Session 不能依据 HTTP 连接来判断是否为同一客户，因此服务器向客户端浏览器发送一个名为 JSESSIONID 的 Cookie，它的值为该 Session 的 id（也就是HttpSession.getId()的返回值）。Session 依据该 Cookie 来识别是否为同一用户。

该 Cookie 为服务器自动生成的，它的 maxAge 属性一般为–1，表示仅当前浏览器内有效，并且各浏览器窗口间不共享，关闭浏览器就会失效。

因此同一机器的两个浏览器窗口访问服务器时，会生成两个不同的 Session。但是由浏览器窗口内的链接、脚本等打开的新窗口（也就是说不是双击桌面浏览器图标等打开的窗口）除外。这类子窗口会共享父窗口的 Cookie，因此会共享一个 Session。

注意：新开的浏览器窗口会生成新的 Session，但子窗口除外。子窗口会共用父窗口的 Session。例如，在链接上右击，在弹出的快捷菜单中选择“在新窗口中打开”时，子窗口便可以访问父窗口的 Session。

如果客户端浏览器将 Cookie 功能禁用，或者不支持 Cookie 怎么办？例如，绝大多数的手机浏览器都不支持 Cookie。Java Web 提供了另一种解决方案：URL 地址重写。

2.7 URL 地址重写

URL 地址重写是对客户端不支持 Cookie 的解决方案。

URL 地址重写的原理是将该用户 Session 的 id 信息重写到 URL 地址中。

服务器能够解析重写后的 URL 获取 Session 的 id。这样即使客户端不支持 Cookie，也可以使用 Session 来记录用户状态。HttpServletResponse 类提供了encodeURL(Stringurl)实现 URL 地址重写，例如：

<td>
    <a href="<%=response.encodeURL("index.jsp?c=1&wd=Java") %>">Homepage</a>
</td>

该方法会自动判断客户端是否支持 Cookie。如果客户端支持 Cookie，会将 URL 原封不动地输出来。如果客户端不支持 Cookie，则会将用户 Session 的 id 重写到 URL 中。重写后的输出可能是这样的：

<td>
    <ahref="index.jsp;jsessionid=0CCD096E7F8D97B0BE608AFDC3E1931E?c=
    1&wd=Java">Homepage</a>
</td>

即在文件名的后面，在 URL 参数的前面添加了字符串“;jsessionid=XXX”。其中 XXX 为 Session 的 id。
分析一下可以知道，增添的 jsessionid 字符串既不会影响请求的文件名，也不会影响提交的地址栏参数。用户单击这个链接的时候会把 Session 的 id 通过 URL 提交到服务器上，服务器通过解析 URL 地址获得 Session 的 id。

如果是页面重定向（Redirection），URL 地址重写可以这样写：

<%
    if(“administrator”.equals(userName))
    {
       response.sendRedirect(response.encodeRedirectURL(“administrator.jsp”));
        return;
    }
%>

效果跟response.encodeURL(String url)是一样的：如果客户端支持 Cookie，生成原 URL 地址，如果不支持 Cookie，传回重写后的带有 jsessionid 字符串的地址。

对于 WAP 程序，由于大部分的手机浏览器都不支持 Cookie，WAP 程序都会采用 URL 地址重写来跟踪用户会话。比如用友集团的移动商街等。

注意：TOMCAT 判断客户端浏览器是否支持 Cookie 的依据是请求中是否含有 Cookie。尽管客户端可能会支持 Cookie，但是由于第一次请求时不会携带任何 Cookie（因为并无任何 Cookie 可以携带），URL 地址重写后的地址中仍然会带有 jsessionid。当第二次访问时服务器已经在浏览器中写入 Cookie 了，因此 URL 地址重写后的地址中就不会带有 jsessionid 了。

2.8 Session 中禁止使用 Cookie

Java Web 规范支持通过配置的方式禁用 Cookie。下面举例说一下怎样通过配置禁止使用 Cookie。

打开项目 sessionWeb 的 WebRoot 目录下的 META-INF 文件夹（跟 WEB-INF 文件夹同级，如果没有则创建），打开 context.xml（如果没有则创建），编辑内容如下：

<?xml version='1.0' encoding='UTF-8'?>

<Context path="/sessionWeb"cookies="false">

</Context>

或者修改 Tomcat 全局的 conf/context.xml，修改内容如下：

<!-- The contents of this file will be loaded for eachweb application -->

<Context cookies="false">

    <!-- ... 中间代码略 -->

</Context>

部署后 TOMCAT 便不会自动生成名 JSESSIONID 的 Cookie，Session 也不会以 Cookie 为识别标志，而仅仅以重写后的 URL 地址为识别标志了。

注意：该配置只是禁止 Session 使用 Cookie 作为识别标志，并不能阻止其他的 Cookie 读写。也就是说服务器不会自动维护名为 JSESSIONID 的 Cookie 了，但是程序中仍然可以读写其他的 Cookie。

结语

以上就是技术博客为大家整理的 Web 前端开发的 Cookie、Session 机制相关知识，希望大家通过本文学习，彻底搞懂 Cookie、Session 机制，如有错误，欢迎指正。