Token之关于基础概念(一)

阔别了一阵,再次提笔,有些感慨。

聊聊Token吧,以前工作中总是遇到。

首先明确什么是token?

一些关键标签:服务端签发的一个字符串,客户端的请求令牌,用户第一次使用用户名密码登录后生成,在token的有效期内使用token登录无需用户名密码

明确之后我们来聊聊,token的生成及请求过程:

1、客户端带上用户名密码请求登录(前端校验通过)

2、服务器收到请求,校验用户名密码(服务端校验通过)

3、服务端签发token,并写进cookie发送给客户端

4、客户端收到token后会存入cookies或者LocalStorage中

5、客户端请求服务端每次都会携带这串token(具体携带方式:放消息体里,或者url直接携带)

6、服务端收到token后,验证通过,开始返回相应数据(验证不通过会返回错误信息)

7、token在服务端会设置一个有效期,每次请求都会验证是否token过期和token的有效性

  • 注意:token在url中被携带时注意浏览器的url截断问题,有可能会导致登录验证不通过(经验之谈,苹果设备上见过,尤其是从端跳H5)从测试角度去看的这个问题。

那为什么要用token?

1、支持跨域访问,token支持跨域访问,但cookie不支持

2、可以避开同源策略(后面会写写我理解的同源策略)

3、token是无状态的,可以多个服务器间共享(无状态在后面写写)

4、token可以避免CSRF攻击(跨站请求伪造)

5、易于扩展

扩展:

  那啥是CSRF呢?简单理解,就是攻击者盗用了你的身份信息,并完成以你的名义发起的恶意活动。至于多恶意,比如:转账!发邮件!购物!……

至于完成一次CSRF攻击必要的两个步骤:

  1、首先登了一个正常的网站A,并且在本地生成了cookie

  2、在cookie有效时间内,访问了危险网站B(就获取了身份信息)

Q:那我不访问危险网站就完了呗?

A:危险网站也许只是个存在漏洞的可信任网站!

Q:那我访问完正常网站,关了浏览器就好了呀?

A:即使关闭浏览器,cookie也不保证一定立即失效,而且关闭浏览器并不能结束会话,session的生命周期跟这些都没关系。

当然CSRF不在本次研究重点!

 啥是同源策略捏?就是不同源的客户端脚本在没有明确授权情况下,不准读写对方的资源!

问题来了:啥是源?

源就是协议,域名,端口号。

同源:就是url里的源都相同。(听着像废话!哈哈

举例:http://www.abcd.com:80 

http://www.abcd.com/dir/index.html(同源)

http://www.ah.com/dir1/index.html(域名不同,不同源)

https://www.abcd.com/dir2/page.html(协议不同,不同源)

http://www.abcd.com:8888/dir3/page.html(端口号不同,不同源)

所以,如果假设a.com中的js脚本要是采用ajax去读写b.com中的资源文件数据是会报错滴!

但有不收同源策略限制的:1、页面中的连接,重定向及表单提交 2、跨域资源的引入可以,但js不能读写加载的内容,如:iframe,img,link,<script src=''>等等。

 那啥是跨域?想要操作另一个源下的对象就需要跨域!

至于怎么跨域,或者跨域的实现方式,咱们以后再讨论!

  易于扩展:比如有多台服务器,使用负载均衡,第一次登录转发到了A,A中seesion缓存了用户的登录信息,第二次登录转发到了B,这时候就丢失了登录状态,,当然这样也是有解决方案可以共享session,但token只需要所有的服务器使用相同的解密手段即可。

 无状态:服务端不保存客户端请求者的任何信息,客户端每次请求必须自备描述信息,通过这些信息来识别客户端身份。服务端只需要确认该token是否是自己亲自签发即可,签发和验证都在服务端进行。这里面其实涉及加密方法,后续讨论,给自己立个flag!

   有状态:我们说的cookie和session就是有状态的,第一次客户端请求,服务端产生session,然后将信息返回给浏览器,浏览器会将session中的关键数据,保存到本地的cookie中,然后每次客户端请求都会携带cookie去访问服务器,这时服务器就会拿出session中的内容和携带过来的cookie进行比较。

   缺点:服务器需要保存大量数据,给存储增加压力。服务端保存用户状态,很难水平扩展。客户端请求依赖服务器,多次请求必须访问同一台服务器(假设集群,就需要各个服务器之间共享数据),有状态登录的方式难以共享session,所以采用单点登录的方式。

请多指教,有啥新理解持续更新!

原文地址:https://www.cnblogs.com/yuki-nana/p/14001600.html