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 都会被拦截