token的用户验证

token的思想

相对于session token在服务端不需要存储用户的登录记录，全部发给客户端有客户端自己存(cookie,local)

1、客户端使用用户名跟密码请求登录
2、服务端收到请求，去验证用户名与密码
3、验证成功后，服务端会签发一个 Token（加了密的字符串），再把这个 Token 发送给客户端
4、客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里或者 Local Storage 里
5、客户端每次向服务端请求资源的时候需要带着服务端签发的 Token
6、服务端收到请求，然后去验证客户端请求里面带着的 Token，如果验证成功，就向客户端返回请求的数据

const express = require('express')//引入封装服务器的express模块
const jwt = require('jsonwebtoken')//引入 token 的模块
const bodyparser = require('body-parser') //进入body-parser 这个中间件 这个可以让服务端可以接收到post请求携带的参数

let app =  express()//创建一个服务器
app.listen(8000,localhost,()=>{console.log("监听服务器成功")})//监听服务器

app.use(express.static('./public'))//设置静态托管 参数是你的静态页面的存储地址


//登录并返回加密字符串 token
app.get('/api/login',(req,res)=>{
    console.log(req.query)
   let token =  jwt.sign({username:req.query.username},'ccccc',{expiresIn:60})这里单位时s
   //设置token 并且返回给客户端 服务端不存储 
   //第一个参数是存储请求携带的用户的用户名参数
   //第二个参数可以是加密规则，字符串，或者私钥path模块
   //第三个参数是设置失效时间
    res.send({
        err:0,
        data:'登陆成功',
        token:token//当你设置成功给客户端返回这个加密字符串(token)让客户端存起来（cookie或者localhost）
    })
})

//验证是否登录
app.get('/api/user',(req,res)=>{
	//获取地址上 或不再地址上 或者请求头里面的token参数
    let token = req.query.token || req.body.token || req.headers.token
    //这里再次请求是如果携带的参数中有token这个属性 且和原来签发到客户端的token相同则表示验证成功 该用户已经登陆过
    //验证 解密 用jwt的verify方法  
    //第一个参数是你获取的token值 第二个是你当时签发token时设置的加密规则，第三个时回调函数 err 为null就是成功  decode 是的到的参数对象以及 cookie时效
    jwt.verify(token,'ccccc',(err,decode)=>{
        console.log('err',err) //错误的时候会报错 没有错误则会显示null
        console.log('encode',decode)//{ username: '张三', iat: 1584014286, exp: 1584014346 } 前面的是请求时间  后面的是到期时间
        if(err){ //一旦报错会显示用户信息校验失败
            res.send('用户验证错误............')
        }else{
            res.send({
                err:0,
                msg:'登陆成功',
                data:'user的库数据'
            })
        }
    })
})
//删除token由客户端进行删除

与session的区别
session的服务端保存用户信息 而token的服务端不保存
session不能避免csrf攻击 而token可以
session安装性一般 token 安装性很强
session有多服务器粘性问题 而 token没有

注：多服务器粘性问题
当在应用中进行 session的读，写或者删除操作时，会有一个文件操作发生在操作系统的temp 文件夹下，至少在第一次时。假设有多台服务器并且 session 在第一台服务上创建。当你再次发送请求并且这个请求落在另一台服务器上，session 信息并不存在并且会获得一个“未认证”的响应。你可以通过一个粘性 session 解决这个问题。然而，在基于 token 的认证中，这个问题很自然就被解决了。没有粘性 session 的问题，因为在每个发送到服务器的请求中这个请求的 token 都会被拦截