该项目代码的地址是:redis存储token,实现登录的校验
项目实现了token登录,校验时的规则是前端把token放到请求头里,校验时是通过拦截器进行拦截,再对redis的token和请求头的token进行校验。
测试一下:
一开始没有登录时:
http://localhost:9090/user/hello
,postman的结果是:
http://localhost:9090/user/login
:
{
"mobile":"123456",
"password":"123"
}
结果:
{
"code": 200,
"msg": null,
"data": {
"mobile": "123456",
"password": null,
"name": null,
"nickName": null,
"token": "4a190fab72784304891d041b926eb5dbeyJhbGciOiJIUzUxMiIsInppcCI6IkdaSVAifQ.H4sIAAAAAAAAAKtWKi5NUrJSCg5y0g0Ndg1S0lFKrShQsjI0Mze2NDUxMTHQUSotTi3yTAGJGZoYmRkYmJsaGxsaWFgYW5jpKOXmJ2XmpAJNMDQyNjE1U6oFAGt_bmJSAAAA.C2LhWcM5KwKFY-_Tb-VtWsjJNHrj_V6I3rV83sH_34RAZ1FqLFTbzEsTGW-Sk7efXhUmrKgf2MNKd4c1dRZukg"
},
"map": {}
}
看一下redis的管理工具:
发现确实存到了redis里,然后再带token测试一下其他接口:
发现也是可以的!
说明成功了。
心得与小结
说一下最近做登录的的心得吧,登录现在据我了解的就是使用session或token技术了,而为什么这里使用了session而不是token,其实之前是想到了session放到浏览器的cookie里的话可能会有csrf攻击,于是就先去实现token的案例了,因为token实现可以避免这一session的缺陷。也不是说session实现就一定会避免不了csrf攻击,好像还有其他防护措施,比如我不使用cookie里存储sessionID等等;也不是使用token登录就好了,xss攻击两种方式都是没办法避免的,只能做好防范措施了。token的实现实际上也没那么复杂,但是想弄懂session和token实现的原理以及如何落实落地到一个项目里去也是想要一些时间的。springsecurity这个框架一开始就是劝退,对于一开始我想搞登录和权限来说是很难的,因为之前既使用过cookie-session做过javaweb项目,也使用过session和token做过spring项目,因此之前搞混了,可以说当时懵逼一批,现在不怕了哈哈,因为最近总算找了很多的文章去看session实现登录和token实现登录的原理、所遇到的问题以及部分实现的思路。现在在屏幕的我终于可以舒畅一口气了哈哈,欠的技术债总是要换的。sprigsecurity也是封装的好点,用的比较显得厉害些罢了,实际上应该和我的demo大体思路差不多的。都是讲要加密的内容转换通过token来记录,并且该token已经是加密了的,在登录的同时就将token放到缓存里,并且返回给前端,下次请求来时,通过拦截器对缓存的token以及前端带过来的token进行校验,应该都是这样了。
end