我做的是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.*

谢谢。

可否问问，您做的是哪方面呀

【 在 facilitator 的大作中提到: 】
: 但是总之让前端自己验证token有效性是没有任何意义的 web api的每个请求都要验证token有效性的 而不是只在一开始验证一次 否则你的api很容易被没登录的人滥用
:
--
FROM 115.199.241.*

你对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，好像用的很少了，要不就转成明文+签名的方式了。
至于你说的token，token是api或者app的鉴权方法，它和Web网站开发的容器常规session基本没有任何关系。它只是API两端约定好的鉴权数据传递方式。
Web session也不一定用于鉴权，它在web领域最典型的案例用法是购物车。说白了Session是回话，它的核心作用是唯一性的标识客户端的那个浏览器环境。
至于楼主说的SPA的鉴权问题，底层实现上是依靠浏览器cookie的sessionid，上层代码里面如何搞，很简单，借鉴restful api方式，就是服务器端收到越权数据请求时返回401\403这类的权限拒绝信息，然后Angular里面对$http添加Interceptor，碰到这类权限拒绝信息直接给用户报个"需要登录"，然后SPA本身转向到login cotroller or page就ok了。
注意:鉴权问题必须是服务器端来判定。
ps:心态老了，越来越不喜欢参加争论和回答问题了。

【 在 facilitator 的大作中提到: 】
: 我做的是nodejs全栈 原理是一样的 你问这种问题 我估计你可能对http的cookie和session的原理缺乏基本的
【 在 facilitator 的大作中提到: 】
: 我做的是nodejs全栈 原理是一样的 你问这种问题 我估计你可能对http的cookie和session的原理缺乏基本的了解 跟java或者angular都没半毛钱关系
: auth信息是通过对server的http请求回叫来读取的
: 首先auth信息是藏在cookie当中的加密字段 （你cookie当中个加密字段叫做session 那么它就是所谓的session了 当然你定义成别的名字也无所谓） 通常存的是一个经过对称加密的、在server端有一定时限的token 用户登录之后生成这个token颁发给客户端 因为存在了cookie当中 会随着每次http请求发到server
: ...................
--
修改:dhcn FROM 123.120.255.*
FROM 123.120.255.*

高手，有open source project吗，也想跟着学习学习
【 在 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 103.217.167.*

深入浅出,高潮迭起,一看就是老司机


【 在 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搞这个都表示搞这个很费劲。
: ...................
--
FROM 218.197.87.*