关于session
用户登录网页时会给服务器发送请求,带着用户信息,此时服务器会进行判断并返回session给用户
- 服务器获取用户信息
- 判断验证用户
- 判断成功,将用户信息写入redis并得到sessionid
- 将session写入cookie返回给前端发送给用户
用户拿着session去请求服务器,服务器解析session后判断用户信息并成功访问
session的缺点:
- 因为用户信息是保存在redis中的,redis是保存在服务器内存,随着用户量增大,所需要的内存资源也随之增大,不可避免的造成内存溢出
- 因为session是基于cookie来进行用户识别的,所以如果cookie会被黑客截获进行CSRF攻击,这样一来就容易被跨站攻击,用户信息被泄露,造成经济损失
- 虽然可以关闭浏览器每次访问都携带cookie和session信息的功能,但是有些网站是基于session登录,这样一来就无法使用该网页
- 随着用户量信息量增多,不可避免进行扩容,建立服务器集群。而随之而来问题就是当用户登录服务器1的时候进行下一个操作可能会被分配到服务器2,此时服务器2没有保存用户的登录信息,所以需要进行再次登录。此时造成了逻辑缺失。
关于token
token机制与session机制的差距不大,最主要的是服务器处理的第三步:
- session: 判断成功,将用户信息写入redis并得到sessionid
- token:判断成功,将用户信息进行加密生成一个加密字符串保存在token变量中
此时服务器返回给用户的就不是session值而是一个token值
前端接受加密字符串通过js代码保存在storage中,用户使用该token值访问网页,网页使用get方法通过js代码获取storage中的token值,并且进行解密,当解密成功获取用户信息
token值就像一串随机字符串,就算被黑客截获也无法使用token来跨域攻击网站致使用户信息泄露,因为浏览器的同源策略致使无法使用不同浏览器登录用户;其次token值不是存在cookie中,而是随着js代码保存在storage中
同源策略:
- 不同源的客户端脚本js文件在没有明确授权的情况下不能读写对方资源。只有同一个圆的脚本赋予dom、读写cookie、session、ajax等操作的权限
token是一个变量,其值是一个加密后的字符串,因此在多个服务器中,用户在服务器1中操作后下一个操作被分配到服务器2也不会重新登录。因为服务器只需要get到用户js代码中的token值并进行解密后即可获取用户信息。
token就想一个凭证,如果对了浏览器就被服务器允许访问
token相对于session的优势:
- 进行加密,保护用户的信息不被泄露
- 因为token是存在变量中的,变量是在程序完成后悔自动销毁所以不会占用大量内存
- 通过token多个服务器之间不需要用户重复登录,只需要通过token进行解密后即可获得用户的信息