api 使用session替代token 的利弊在哪?

补充:几种常用的验证机制
最近写app的api,使用laravel 框架的session替代了传统的存贮到数据库的token作为校验登录用户的方法!
以下是我们目前的做法

  1. 登录后后台生产session,会往返回信息head头里写一个set_cookie

  2. ios和安卓 会从head头里得到拿到这个cookie的东西

  3. 然后再请求需要登录的地方的时候,ios和安卓会把cookie放到head头里,让框架完成自我的校验

ps:

  1. 有人说不安全

  2. 有人说不好管理

  3. 有人说性能问题

有谁具体研究过,请帮我分析分析其利弊

我个人认为的观点:

  1. 说session不安全的,感觉有点牵强,假如真的一点不安全的话,那网站也就完全被暴露了,而且laravel的session也是有自己加密的方式,不是直接暴露的!

  2. 有人说不好管理,放在redis里了,我不太知道不好管理在哪里。

  3. 性能问题,session可以存贮的位置有很多,mysql,文件,redis,我觉得性能也不是问题。我也不知其弊端在哪里,

有谁具体研究过,请帮我分析分析其利弊
也请大家有想法的各抒己见,我们一起讨论下

阅读 9.4k
评论
    12 个回答
    • 1.9k

    1.说不安全,这个有点牵强,但是使用session做用户的验证,session生成一个唯一的id存放在客户端的cookie中作为唯一的标识,换句话说,假如客户端停掉了cookie的话,那么验证的就会出现问题。
    2.至于使用token,第一token的加密方式必须严谨,第二需要为token生成一个有效时间。第三redis的性能虽然很高,但万一重启redis时候,验证就会出现一个很严重的问题,就就是说当redis重启时候必须停了服务器运营,除非你有redis的主从服务器。假如存储数据库,那就更加不实际,应该会受到很大的性能限制,每次用户需要发出请求时间,都要访问mysql服务器作验证。
    所以各个都有利与弊