我在一个WebAPP项目中遇到了题主的这个问题。由于API是为APP准备的,因此在WebAPP中使用ajax和api进行交互也不得不按照app与api交互时的使用习惯。 在向api发出请求的时候,可能有两种情况,一种是用户登录,一种是未登录。无论哪一种情况,都可以采用下面的这种思路,但在使用token时使用不同的token即可。登录用户使用登录时服务端生成的带nonce的token,是唯一的,而未登录用户app在请求时,携带的是一个服务端和客户端约定好的token(尽可能保密)。 在api设计时,尽可能的遵循restful风格,因此,在提交的信息中,用于鉴权的token被放在header中,token鉴权是设计我是这样的思路: app登录,服务端创建token(token为经过加密后的字符串,可被解密,解密后的数据中包含登录的用户信息或非用户登录状态下的约定好的token),并且将app与server端的时间差一并保存在redis中,并将token返回给app,app将其保存在本地,利用html5的localStorage可以轻松做到 app在请求api接口时,传入一个access_token,该access_token由token和时间戳运算后获得,从而保证了每一次发送的access_token是不同的,这个access_token的有效期为很短的一段时间,只要保证在网速比较渣的情况下有效即可 服务端在接收到这个access_token后,经过解密,从redis中取出对应的token所提供的数据,对时间差进行比较,超出一定时间的,认为无效,并获得该token对应的user_id或者判断token是否为约定值。 这个思路可以: 拒绝不携带access_token的非法调用 防止无意间抓取到某个access_token,想利用该access_token做大规模攻击 当然,这里加密解密会牺牲掉一些性能,这也只是我的一种思路。
我在一个WebAPP项目中遇到了题主的这个问题。由于API是为APP准备的,因此在WebAPP中使用ajax和api进行交互也不得不按照app与api交互时的使用习惯。
在向api发出请求的时候,可能有两种情况,一种是用户登录,一种是未登录。无论哪一种情况,都可以采用下面的这种思路,但在使用token时使用不同的token即可。登录用户使用登录时服务端生成的带nonce的token,是唯一的,而未登录用户app在请求时,携带的是一个服务端和客户端约定好的token(尽可能保密)。
在api设计时,尽可能的遵循restful风格,因此,在提交的信息中,用于鉴权的token被放在header中,token鉴权是设计我是这样的思路:
app登录,服务端创建token(token为经过加密后的字符串,可被解密,解密后的数据中包含登录的用户信息或非用户登录状态下的约定好的token),并且将app与server端的时间差一并保存在redis中,并将token返回给app,app将其保存在本地,利用html5的localStorage可以轻松做到
app在请求api接口时,传入一个access_token,该access_token由token和时间戳运算后获得,从而保证了每一次发送的access_token是不同的,这个access_token的有效期为很短的一段时间,只要保证在网速比较渣的情况下有效即可
服务端在接收到这个access_token后,经过解密,从redis中取出对应的token所提供的数据,对时间差进行比较,超出一定时间的,认为无效,并获得该token对应的user_id或者判断token是否为约定值。
这个思路可以:
拒绝不携带access_token的非法调用
防止无意间抓取到某个access_token,想利用该access_token做大规模攻击
当然,这里加密解密会牺牲掉一些性能,这也只是我的一种思路。