Open Tamce opened 7 years ago
简单补充几点
Laravel
应对这个问题使用了自己的session加密方法。用 jwt
的话依旧不能在客户端保存敏感信息,只能做用户身份确认和授权,当检查授权成功时如果要读取用户数据的话依然要从数据库中取出,且现代框架大部分都支持直接设置 session 载体,使用 memcache, redis 等可以有效降低读写文件/数据库带来的开销;当然将数据加密之后放到 jwt
里的话确实可行,但就算是加密过的敏感数据放到客户端,我总有种不安心的感觉。
而且关于移动端适配我有一种并不算十分好的解决方案,那就是将 session-id 签名后作为 token 放到 HTTP Header 中来使用,且可以使用 app-secret 进行签名,服务端确认签名后直接使用 session-id 恢复会话数据,这样将 API 拓展到给移动端使用的时候仅需要在重建会话时加一层验证即可。
你这样和自己实现session有什么区别,所以我说不如抛弃session-cookie的模式,这样连共享session的问题也不用考虑了,redis共享用户信息就行
哈哈哈哈哈好像确实是这样,只是名义上还顶着一个 session 的名字
昂,这是为了线下分享的预热做一个简单的预告和梗概。 才学尚浅,如有错误欢迎指正
HTTP 的状态保持机制(如记住用户的登录状态等)要用到
cookie
这个玩意,而常常cookie
又和session
一起出现,而这两个玩意又是比较容易搞混的,因此这次的分享我就来谈谈cookie
和session
,顺便简单引出几点安全问题以及解决方案。Cookie 的实现原理
cookie
是由客户端UserAgent
所负责管理的文本文件,由服务器要求设置,保存在客户端,在客户端访问页面时,会在 HTTP 请求中附上已经设置的 cookie 值。Cookie 的安全问题及解决
暂略,线下分享
Session 的实现原理
session
是由服务器端进行实现的用于存储会话数据的玩意,它可以直接由 HTTP 服务器软件进行实现,也可由一些服务端语言进行实现,会话数据可以保存在任何地方如内存、内存型数据库、文件、数据库、其他服务器(分布式架构之类的)等等,这些都只是一个载体,我们不具体讨论。session
会话机制主要由服务端和客户端共同维护一个session id
来实现,服务端通过cookie
来把一个特定的随机产生的session id
发送给客户端,客户端之后每次请求时都会通过cookie
来提交这个session id
给服务器。服务器获得一个
session id
时,从 session 载体(上述)中把该 id 对应的数据重新读出使用。Session 机制的安全问题及解决
暂略,线下分享
额外的阅读资料
随意搜索网上很多( 别告诉我搞技术的搜索引擎都不会用(逃