总结
-
框架原理真的深入某一部分具体的代码和实现方式时,要多注意到细节,不要只能写出一个框架。
-
算法方面很薄弱的,最好多刷一刷,不然影响你的工资和成功率😯
-
在投递简历之前,最好通过各种渠道找到公司内部的人,先提前了解业务,也可以帮助后期优秀 offer 的决策。
-
要勇于说不,对于某些 offer 待遇不满意、业务不喜欢,应该相信自己,不要因为当下没有更好的 offer 而投降,一份工作短则一年长则 N 年,为了幸福生活要慎重选择!!!
喜欢这篇文章文章的小伙伴们点赞+转发支持,你们的支持是我最大的动力!
4.安全
Token的起源
在介绍基于Token
的身份验证的原理与优势之前,不妨先看看之前的认证都是怎么做的。
- 基于服务器的验证
我们都是知道HTTP
协议是无状态的,这种无状态意味着程序需要验证每一次请求,从而辨别客户端的身份。
在这之前,程序都是通过在服务端存储的登录信息来辨别请求的。这种方式一般都是通过存储Session
来完成。
- 基于服务器验证方式暴露的一些问题
1.Seesion
:每次认证用户发起请求时,服务器需要去创建一个记录来存储信息。当越来越多的用户发请求时,内存的开销也会不断增加。
2.可扩展性:在服务端的内存中使用Seesion
存储登录信息,伴随而来的是可扩展性问题。
3.CORS
(跨域资源共享):当我们需要让数据跨多台移动设备上使用时,跨域资源的共享会是一个让人头疼的问题。在使用Ajax
抓取另一个域的资源,就可以会出现禁止请求的情况。
4.CSRF
(跨站请求伪造):用户在访问银行网站时,他们很容易受到跨站请求伪造的攻击,并且能够被利用其访问其他的网站。
在这些问题中,可扩展行是最突出的。因此我们有必要去寻求一种更有行之有效的方法。
基于Token的验证原理
基于Token的身份验证是无状态的,我们不将用户信息存在服务器中。这种概念解决了在服务端存储信息时的许多问题。NoSession
意味着你的程序可以根据需要去增减机器,而不用去担心用户是否登录。
基于Token的身份验证的过程如下:
-
用户通过用户名和密码发送请求。
-
服务器端程序验证。
3.服务器端程序返回一个带签名的token
给客户端。
4.客户端储存token
,并且每次访问API
都携带Token
到服务器端的。
5.服务端验证token
,校验成功则返回请求数据,校验失败则返回错误码。
Tokens的优势
- 无状态、可扩展
在客户端存储的Tokens
是无状态的,并且能够被扩展。基于这种无状态和不存储Session
信息,负载负载均衡器能够将用户信息从一个服务传到其他服务器上。tokens
自己hold
住了用户的验证信息。
- 安全性
请求中发送token
而不再是发送cookie
能够防止CSRF
(跨站请求伪造)。即使在客户端使用cookie
存储token
,cookie
也仅仅是一个存储机制而不是用于认证。不将信息存储在Session
中,让我们少了对session
操作。
token
是有时效的,一段时间之后用户需要重新验证。
- 可扩展性
Tokens
能够创建与其它程序共享权限的程序。
- 多平台跨域
我们提前先来谈论一下CORS
(跨域资源共享),对应用程序和服务进行扩展的时候,需要介入各种各种的设备和应用程序。
需要设置有效期吗?
对于这个问题,我们不妨先看两个例子。一个例子是登录密码,一般要求定期改变密码,以防止泄漏,所以密码是有有效期的;另一个例子是安全证书。SSL
安全证书都有有效期,目的是为了解决吊销的问题。所以无论是从安全的角度考虑,还是从吊销的角度考虑,Token
都需要设有效期。
- 那么有效期多长合适呢?
只能说,根据系统的安全需要,尽可能的短,但也不能短得离谱
- 然后新问题产生了,如果用户在正常操作的过程中,
Token
过期失效了,要求用户重新登录……用户体验岂不是很糟糕?
一种方案,使用 Refresh Token
,它可以避免频繁的读写操作。这种方案中,服务端不需要刷新 Token
的过期时间,一旦 Token
过期,就反馈给前端,前端使用 Refresh Token
申请一个全新Token
继续使用。这种方案中,服务端只需要在客户端请求更新 Token
的时候对 Refresh Token
的有效性进行一次检查,大大减少了更新有效期的操作,也就避免了频繁读写。当然 Refresh Token
也是有有效期的,但是这个有效期就可以长一点了,比如,以天为单位的时间。
- 时序图表示
使用 Token
和 Refresh Token
的时序图如下:
1)登录
2)业务请求
3)Token
过期,刷新 Token
上面的时序图中并未提到 Refresh Token
过期怎么办。不过很显然,Refresh Token
既然已经过期,就该要求用户重新登录了。
项目中使用token总结
使用基于 Token
的身份验证方法,在服务端不需要存储用户的登录记录。大概的流程是这样的:
1.前端使用用户名跟密码请求首次登录
2.后服务端收到请求,去验证用户名与密码是否正确
3.验证成功后,服务端会根据用户id
、用户名、定义好的秘钥、过期时间生成一个 Token
,再把这个 Token
发送给前端
4.前端收到 返回的Token
,把它存储起来,比如放在 Cookie
里或者 Local Storage
里
export interface User { token: string; userInfo: UserInfo | any; companyInfo: CompanyInfo | any; resources?: string[]; }
save(key: string, value: any, storageType ?: StorageType) { return this.storageService.put( { pool: key, key: 'chris-app', storageType: StorageType.localStorage }, value ); } this.storageService.save(CACHE_USER_KEY, user);
5.前端每次路由跳转,判断 localStroage
有无 token
,没有则跳转到登录页。有则请求获取用户信息,改变登录状态;6.前端每次向服务端请求资源的时候需要在请求头里携带服务端签发的Token
HttpInterceptor => headers = headers.set('token', this.authService.getToken());
7.服务端收到请求,然后去验证前端请求里面带着的 Token
。没有或者 token
过期,返回401
。如果验证成功,就向前端返回请求的数据。
8.前端得到 401
状态码,重定向到登录页面。
HttpInterceptor => 401: '用户登陆状态失效,请重新登陆。'
作者:chrisghb
来源:https://www.jianshu.com/p/a32634a5170c
推荐阅读
最后
四轮技术面+一轮hr面结束,学习到了不少,面试也是一个学习检测自己的过程,面试前大概复习了 一周的时间,把以前的代码看了一下,字节跳动比较注重算法,面试前刷了下leetcode和剑指offer, 也刷了些在牛客网上的面经。大概就说这些了,写代码去了~
祝大家都能收获大厂offer~
篇幅有限,仅展示部分内容