前景:本周五的时候后端让我从前端工程中排查,有没有设置cookie。在我连续说了没有的情况下,连续四次被质疑。最后以我发四说没有,不欢而散。 基于对前端的不信任,写个小作文来说明vue前端怎么设置cookie
Cookie的概念性质的东西这里不赘述。
一:Cookie生成机制
- 服务端生成,在Http响应头Respond-Header 中****Set-Cookie
- 客户端生成
二:服务端生成
- 服务端可通过 Cookie类的构造函数和实例方法设置Cookie(key=value)并返回,
- 浏览器收到响应并发现响应头中有 Set-Cookie,浏览器就会把key、value保存在浏览器中。
- 在向同一个域名发起的后续请求中,浏览器会在请求头中加上该cookie字段(除非它过期了)。
服务器端通过设置Set-Cookie 的 Expires和 Max-Age两个属性来设置cookie的有效期
1、Expires
javascript
Set-Cookie: sessionId=abc123; Expires=Thu, 01 Jan 1970 00:00:00 UTC;
Expires 的值必须是一个完整的日期和时间,包括年、月、日、时、分、秒和时区。
- Expires 值为 过去时,浏览器立马删除该Cookie;
- Expires 值为 将来时,浏览器会在将来的那个时点删除该Cookie
2、Max-Age
javascript
Set-Cookie: sessionId=abc123; Max-Age=0;
Max-Age的值是个秒值。
- Max-Age = 0;浏览器立即删除该Cookie
- Max-Age = -1; 浏览器重启后Cookie消失。关闭当前页签或者关闭浏览器,Cookie都会消失。
- Max-Age=3600; 表示3600 秒(即 1H)内有效,超期失效。
同时设置这俩属性时,Max-Age的优先级高于Expires
三:客户端生成方式
- JavaScript 自带的 document.cookie
- 第三方依赖库:如js-cookie
1、document.cookie
javascript
// 设置cookie
document.cookie = 'sessionId=abc123; path=/'
// 获取Cookie值
const getCookie = name => {
var cookies = document.cookie.split(";");
for (let i = 0; i < cookies.length; i++) {
const [key, value] = cookies[i].split("=")
if (key.trim() === name) {
return value;
}
}
return ""
};
// 删除cookie
// 方式:将cookie的 过期时间(expires)属性指定为一个过去的时间
const deleteCookie = name => {
document.cookie = name + '=;expires=Thu, 01 Jan 1970 00:00:00 UTC; path=/;';
}
deleteCookie('password');
2、js-cookie
javascript
import Cookies from 'js-cookie';
// 设置cookie
Cookies.set('sessionId', 'abc123');
// 获取cookie
const sessionId = Cookies.get('sessionId');
// 删除cookie
Cookies.remove('sessionId');
四:--------- 我是分割线 ---------
前端是否设置cookie,工程中全局搜索cookie关键字,就能判断前端是否做了特殊处理。
cookie通过浏览器自动管理,大多数情况下前端并不需要处理cookie。
浏览器本地数据存储:建议使用web storage(包括localStorage和sessionStorage)。更大的存储空间(5M左右),提供了多个属性和方法,数据操作更简单。
五:鉴权
1)cookie的缺点
- 不安全:cookie的键值对都是明文,用户可通过浏览器或其他工具拿到cookie,可能被篡改(document.cookie),存在安全隐患。因cookie存在安全问题,有些企业的内网或安全策略会要求禁用cookie。
- 容量限制:每个cookie的大小不超过4KB,单个域名设置的Cookie数量有限制。
- 不能存实例
- 一些设备或浏览器可能不支持cookie
- 跨域问题
- ...
因上面的缺点,cookie不适合做鉴权,需要用session配合。
2)Session
Cookie将内容(key、value等信息)通过响应头返回。如果这些内容不直接返回,而是保存在服务器端,给内容取个名字叫session上下文,给上下文取个id叫SessionId(随便叫什么id都行)。客户端跟服务器端通过SessionId关联。
SessionId通常以Cookie的形式存储在客户端。但Cookie并不是唯一方式,URL也可以。不过URL方式对用户不友好,所以基本上没有互联网项目会采用这种方案。
Session的问题
- Session中保存的数据的大小要考虑到存储上限
- 依赖Session的关键业务一定要确保客户端开启了Cookie
- 在负载均衡的情况下,由于存在Web服务器内存中的Session无法共享,通常需要重写Session的实现。
- Session内容的丢失都是有原因的,通常都是由于Web服务器的重启造成的
cookie或者sesssion,都是后端在主导,前端相关的动作都是由标准浏览器来完成。js在其中只是用户体验的工作,而不是逻辑功能层面的工作
现在最普遍的鉴权方案是:Token。
3)Token
Token 是在服务端产生的。前端使用用户名/密码向服务端请求认证,服务端认证成功,那么服务端会返回 Token 给前端。前端可以在每次请求的时候带上 Token 证明自己的合法地位。
Token的全称是JSON Web Token,简称jwt。
详述
前端使用用户名/密码向服务端请求认证,服务端认证成功后,将用户id等信息进行打包,打包时利用secret(HS256算法、RS256算法等)加密,那么服务端会返回 Token 给前端。
前端拿到token,是解不开的,因为服务器肯定不会把secret传给前端,让前端去解。
前端可以在每次请求的时候带上 Token 证明自己的合法地位。后端在请求头(一般放在请求头)中拿到这个Token,进行验证。验证主要是两个层面:签名是否有效,是否过期。
The end.