“知了”开发日志——OpenAPI 权限校验的解决方案

解决方案

直接增加一个和已有登录一致的开放登录接口login,通过用户名+密码进行登录;登录后将会在知了本体服务器内保存session,其中session 是通过留存在客户端的cookie 中的sessionId 来确定的。

因此,第三方门户的后端需要通过response 中的头部字段取出set-cookie 字段,并维护这一cookie,将其加入到以后的request 头部。这样第三方门户再调用其他OpenAPI 接口时就能够通过session 判断用户是否登录。

分析

  • 优点

    login接口代码可以复用。

  • 缺点

    第三方门户需要加入对cookie 的维护逻辑;同时涉及session 的过期问题(目前设定的过期时间是三小时);

    这就涉及到,第三方门户是在前端提供给用户一个登录,这样就不需要管session 是否过期;还是后端来维护这个登录逻辑,要进行定时重新进行登录以维护保存在知了本体中的session;

    但不论怎样操作!对于第三方来讲,需要进行如此复杂的操作都是不太合理的。

2. token

解决方案

这一方案是参考微信小程序的OpenAPI。为每个用户提供appKey 和secretKey(在我们这里可以直接是账号+密码),单独设置接口getToken,参数为AK 与SK,返回一个token 字符串。其他OpenAPI 都需要加上这个token 字符串,如果有token 字符串且校验通过那么判断用户登录,可以查看非公开资源;如果没有这项,或校验失败则返回公开资源。

这里就涉及到对token 的设计,可以复杂可以简单。

  • 简单一点:token 不设过期时间,多次请求获得的token 一样,token 可以直接根据用户的账号和密码利用某种加密算法压缩而成,也方便校验,同时方便第三方维护
  • 复杂一点:token 有过期时间,动态生成;第三方需要通过定时任务维护这一token。缺点是实现起来相对复杂。(当然微信小程序采用的是这样的方式)

分析

  • 优点

    符合目前多数OpenAPI 的设计方式

  • 缺点

    知了服务端,第三方客户端的改动都非常大;

    知了服务端需要加密解密校验算法、更新生成动态token;

    第三方客户端需要维护token、设置定时任务、增加获取token的调用逻辑。

3. appKey

解决方案

一个更简单和直接的办法!目前已经有appKey用于验签了,为什么不直接利用它呢?

为每个用户颁发一个特定的随机长字符串作为appKey,在数据库存储。同时提供一个公开appKey。再细化验签过程。

  • 如果使用了公开appKey,仅返回公开资源;
  • 如果使用了某一用户的appKey,按照该用户身份返回资源;
  • 如果使用了无效的appKey,则验签失败。

分析

  • 优点

    成本很低;

    知了服务端:对于appKey的鉴权逻辑在知了服务端已有,只需要引入一步数据库的crud即可确定用户身份,不需要繁复的加密解密或是登录逻辑;

    第三方应用:只需要登录到知了,通过一个按钮获取一下属于自己的独立appKey,并将其作为第三方应用的一个配置项 ,在调用其他接口时使用该用户独有的appKey即可。


最终选定的方案为“3.直接使用appKey标识唯一用户

补充说明一下几条内容:

1. 如何通过OpenAPI 搜索公开资源?

当在调用OpenAPI 时使用公开的appkey 作为参数,搜索结果与权限等同于在知了本体中未登录时(仅能查看公开资源)。管理员可在系统管理页面进行配置公开的appKey

2. 如何通过OpenAPI 搜索非公开资源?

当在调用OpenAPI 时使用为某一用户分配的特定appKey 作为参数,搜索结果与权限等同于在知了本体登录该用户(可查看符合群组权限的全部资源)

3. 如何获取我的appKey?

请联系管理员在用户管理页面分配并查看用户的appKey

------ 本文结束,感谢观看! ------
 wechat
扫一扫,访问本站