响应设置cookie_注册登录与 Cookie

开始之前，我们先简单了解一下 注册/登录 的流程。（无代码）

进入注册页面，用户填入用户名、密码、手机号等“注册信息”。
前端验证用户填入的信息是否符合要求，如果不符合要求，就提示用户输入错误，重新输入。
如果符合要求，就将“注册信息”作为 post 的第四部分（字符串），向后端发起 post 请求。
后端收到 post 请求，将 post 的第四部分（字符串）转变成能用的格式。
后端拿到数据后，进行数据验证。
数据验证如果不通过，后端就返回 400（状态码）和错误信息（JSON 格式）给前端，前端根据错误信息，提示用户哪里输入错误。
数据验证如果通过，就将数据存入数据库。
存入数据库时，先检查数据库中是否包含该用户信息。
如果包含，后端返回错误信息给前端，前端提示用户“已注册”。
如果不包含，就将该用户数据写入数据库，并向前端发送响应，前端提示用户“注册成功”并跳转至登录页面。
用户填入“登录信息”。
前端验证“登录信息”是否符合要求，如果不符合，就重新输入。
如果符合，将“登录信息”作为 post 的第四部分，向后端发起 post 请求。
后端收到 post 请求，将 post 的第四部分（字符串）转变成能用的格式。
后端拿到数据后，与数据库的数据进行比对。
如果发现数据库没有该用户信息，就向前端发送“错误信息”，前端提示用户“未注册”。
如果数据库匹配到该用户信息，并且信息一致，说明该用户已注册，后端发送响应给前端，前端提示用户“登录成功”并跳转至首页（或其他页面）。

上面过程中，有一个注意点：

为什么前端和后端都要验证一遍用户填入的信息？

首先我们要知道，前端其实是可以不用验证用户填入的信息的，但是后端一定要验证。

但是如果前端不验证的话，就要发送一个请求给后端，让后端验证，如果后端验证失败，又要发个响应给前端。这无形中增加了请求和响应，也就给服务器增添了负担，不利于网络性能优化。所以最好让前端先把用户信息验证好，如果用户填入的信息没有问题，再将信息发送给后端。这样就不用来回的发送请求和响应。

另外，有些人可能会通过命令行，使用 curl 来访问服务器，这样一来就直接绕过了前端，直接访问后端。如果后端不验证，那么就可能出现安全问题了。

以上是注册登录的简单版本，实际工作中，会比这复杂的多。

下面有两张流程图，可以清晰看出 注册/登录 的流程。

图片来自 segmentfault 。

我们都知道，一个网站，你登录了和没登录，看到的页面是不一样的。

那么服务器是如何区分你是登录了还是没登录呢？或者你登录了以后，跳转到其他页面，其他页面是怎么知道你是已经登录的状态呢？这就需要用到 Cookie 了。

Cookie

什么是 Cookie？

Cookie 是服务器通过 HTTP 响应，写入浏览器的一小段文本信息。

为什么要使用Cookie？

Cookie 主要用来分辨两个请求是否来自同一个浏览器，以及用来保存一些状态信息。

分辨请求是否来自同一个浏览器：

比如，你的电脑上同时安装了 Chrome 浏览器和 Safari 浏览器。当你用 Chrome 登录知乎后，再使用 Safari 登录时，会要求你重新登录。这是因为，服务器给 Chrome 的 Cookie 和给 Safari 的 Cookie 是不一样的。就好比，你和你弟弟去游乐园玩，游乐园会给你们两张票，一张对你有用，一张对你弟弟有用，你不能用你弟弟的票，你弟弟也不能用你的票。

保存一些状态信息：

比如，你登录知乎后，在一段时间内，即使你关闭了浏览器，当再次打开知乎时，可以不用登录。这是因为，Cookie 中包含了“过期时间”，只要你在“过期”以前重新打开知乎，就可以不用登录。就好比，游乐园的门票的有效期为两天，在这两天时间内，不管你干嘛，哪怕你出园了，当你再次进入游乐园时，检票员发现你的票还没有过期，你就可以直接进入游乐园，不用再次买票。

怎么写 Cookie？

Cookie 是服务器写入浏览器的一小段文本信息，形如：

response.setHeader('Set-Cookie', 'userName=dongdong; password=123')  // 返回给浏览器的 Cookie 记录了用户名和密码

当然，服务器也可以设置多个 Cookie ，那么 HTTP 响应中就会包含多个 Set-Cookie 字段：

HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: a=1
Set-Cookie: b=2[page content]

浏览器向服务器发送请求时，就会带上这段文本信息，形如：

GET /xxx.html HTTP/1.1
Host: www.example.org
Cookie: userName=dongdong; password=123  // 浏览器带上的 Cookie 有用户名和密码

这样一来，服务器只要读取浏览器带上的 Cookie（票拿来给我看看），然后和服务器中的数据做对比（检查票上的信息），如果验证通过，就可以访问。

Cookie 的属性

Expires，Max-Age

上面说到，Cookie 是有过期时间的。在服务器，我们可以通过 Expires 和 Max-Age 两个属性来设置。如：

response.setHeader('Set-Cookie', 'expires=Wed, 21 Oct 2015 07:28:00 GMT')
response.setHeader('Set-Cookie', 'max-age=30')

上面代码中，分别通过 Expires 和 Max-Age 属性来设置过期时间，那么这两个有什么区别呢？

Expires 设置的是具体的过期时间，比如 xxx 年 xxx 月 xxx 日 xx : xx : xx ，到了这个时间后，Cookie 就会被删除；
Max-Age 设置的是从现在开始 Cookie 存在的秒数，比如有效期为 30s，30s 后，Cookie 就会被删除。

如果同时指定了 Expires 和 Max-Age，那么 Max-Age 的值将优先生效。

如果没有指定这两个属性，那么这个 Cookie 就是 Session Cookie，只在当前会话（Session）有效，如果关闭浏览器，那么 Cookie 就会被删除。

Secure，HttpOnly

Secure 和 HttpOnly 属性，可以不用指定属性值，如：

response.setHeader('Set-Cookie', 'Secure')
response.setHeader('Set-Cookie', 'HttpOnly')

Secure 属性指定浏览器只有在 HTTPS 协议下，才能将 Cookie 发送给服务器。另外，如果协议是 HTTP，那么浏览器会自动忽略服务器发来的 Secure 属性。换句话说，Secure 只在 HTTPS 协议下有效。

HttpOnly 属性指定只有在浏览器发出请求时，才会带上该 Cookie，该 Cookie 无法通过 JavaScript 脚本拿到。

比如通过 document.cookie 可以拿到当前网页的 Cookie：

document.cookie // "foo=bar;baz=bar"

但是如果该 Cookie 设置了 HttpOnly 属性，那就无法拿到 Cookie。

END~~