- 主题:问个auth信息存储问题（angular背景）
我做的是nodejs全栈 原理是一样的 你问这种问题 我估计你可能对http的cookie和session的原理缺乏基本的了解 跟java或者angular都没半毛钱关系
auth信息是通过对server的http请求回叫来读取的
首先auth信息是藏在cookie当中的加密字段 （你cookie当中个加密字段叫做session 那么它就是所谓的session了 当然你定义成别的名字也无所谓） 通常存的是一个经过对称加密的、在server端有一定时限的token 用户登录之后生成这个token颁发给客户端 因为存在了cookie当中 会随着每次http请求发到server
每次http请求你要从cookie当中读取token 验证token是否过期了 如果过期了就客户端登录信息无效 需要重新登录 如果token有效 你就正常处理http请求的信息 （或者针对你这个问题 就是返回一个true 无效就返回false）
由于token通常是对称加密的 你不可能让客户端自己去验证token 从安全角度来讲 只能让server去验证并返回true或者false
或者除非你自己搞一个非对称加密的token 让客户端自己能验证
【 在 saynothing 的大作中提到: 】
: 目前在看一套网络管理系统的实现代码。
: 后端： java实现
: 前端： AngularJS
: ...................
--
FROM 110.23.10.*
但是总之让前端自己验证token有效性是没有任何意义的 web api的每个请求都要验证token有效性的 而不是只在一开始验证一次 否则你的api很容易被没登录的人滥用
【 在 saynothing 的大作中提到: 】
: 目前在看一套网络管理系统的实现代码。
: 后端： java实现
: 前端： AngularJS
: ...................
--
FROM 110.23.10.*
MEAN全栈
【 在 saynothing 的大作中提到: 】
: 谢谢。
: 可否问问，您做的是哪方面呀
:
--
FROM 110.23.10.*
是 我用的就是session cookie 这个方案比较简单好用 对于小的VPS来说 既不占内存 也直接解决horizontal scalability的问题
【 在 dhcn 的大作中提到: 】
: 你对Web容器常规session的描述不太精确。首先浏览器cookie存的那个session标识一般是sessionid(一般web容器好像会在前面加prefix，不然JSESSIONID，PHPSESSIONID，这样并不好。)，正常情况下它不需要对称加密(实际上它和对称加密的那个也不是一个东西)，只要保证当前唯一性就OK，服务器端的session存储是一个key-value结构，客户cookie存的那个sessionid它标明了客户端浏览器的唯一性，也是服务器端这个session key-value存储结构的key。这个session value又是个容器，你可以往里面再天添加key-value结构存储，比如seesion.set("userid",1)这样的语句就在服务器端标明了当前登录用户是1号用户。
: 服务器端的这个Session存储有内存式，比如Java容器里面的非简单对象，有文件式，我记得PHP可以设置成这样，有RDB数据库式，django默认就是这样，有Redis缓存式，Django可以很轻松切换成这种方式，Tomcat也可以切换成这种，顺便解决了跨实例的Session共享问题，不过好多Javaer搞这个都表示搞这个很费劲。
: 至于你说的客户端对称加密session cookie，这只是前几年单机内存紧张时，某些大站变相存储跨服务的session cache信息的办法，这几年有了redis，好像用的很少了，要不就转成明文+签名的方式了。
: ...................
--
FROM 110.23.10.*