讨论一下关于 token 的使用

讨论 · echo · 于 6年前 发布 · 4828 次阅读

架构说明

比方说现在一个项目的架构是这样的:

RESTful 提供所有的客户端的 API 接口,现在要设计一种验证机制,返回 token。

问题

比方说现在有一个更新商品接口。接口URL是 /v1/product/12 12 是商品 ID,因为我们项目是多商户的,肯定不能这样简单吧。 如果这个商品 ID 不为当前登录商户的呢?所以我们要加一层 token,因为是 web-admin 和 RESTful 是两个独立的系统,所以不能简单的时候 Session 来判断当前商户。

微信端登录的时候也只能操作当前用户的所有数据。

因为 RESTful 提供所有客户端的接口,所以功能相同的接口尽量值提供一个。

目前的方案

因为项目是多商户的系统,所以我设计了这种验证机制:

设计一个 token 表,web-admin 端商户登录成功之后,token 表插入一条数据,生成的唯一 token 绑定当前登录的商户ID。

然后所有的 Api 登录都必须带 token 参数,根据 token 参数从数据库中查出商户ID。之所有这样做,是怕当前商户操作其他商户的信息。 之前一直以为这样还可以,直到后来开始 做 web-weixin 端。登录的用户角色变了,那么问题来了:

  1. 微信端用户登录之后,我返回的 token 继续为绑定当前微信用户所在的商户 ID?
  2. 如果以后 RESTful Api 对接 Android 和 iOS 之后怎么办?总不能返回的 token 继续为绑定当前用户所在的商户 ID 吧?我的理解是在 App 端 token 应该当 session ID 用,到时候用来判断当前登录用户的。

另外一种解决方案设想

重新设计 token 机制,分别给 web-admin 、web-weixin、Android 和 iOS 端各分配不同的 client id 和 client secret, 根据 client id 和 client secret 设计一种算法获取 token。(有一个专门获取 token 的 api 接口,只传 client id 参数,client secret 为双方约定的配置信息)

获取 token 之后,每次请求的所有参数根据根据一个算法然后 MD5 加密生成一个签名 sign,同样这个生成签名的算法 client secret 会参与进去,但是在请求的时候不传输。

RESTful 服务器端使用同样的算法计算签名,如果签名与请求的参数签名一致,则执行请求,否则返回错误信息。

这种算法应该能保证数据的安全性了吧,也不必考虑当前商户获取其他商户的数据了吧?

当然以上 token 都是带有时效性的,过期需要重新获取。各位觉得最后这个方案如何?

共收到 1 条回复 RESTful 讨论
forecho#16年前 0 个赞

有一种方案就是:

区分用户 token 和商户 token ,但是你以前的代码有可能会大改。有些功能相同的接口你可能要写两个:比方说,编辑会员信息,门店后台编辑和微信端编辑虽然功能相同,但是这块的 token 意义不一样,所以逻辑有点小差别。

添加回复 (需要登录)
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册