钉钉登录

Posted 2021-09-15 一吃三大碗

基于前后端分离的基本架构，应用的后端服务应该至少实现以下接口:

1.登录接口/ding-login-cb

【场景描述】

用户扫码登录后，内部钉钉服务会在redis中生成token, 把token 和 用户信息 返回给这个接口(通过回调的方式).

【需要实现的业务逻辑】

从query中获取token, 塞到cookie中.

重定向到应用首页.

query 中可以获取的参数：

data | Object | 用户信息
token | String | redis key

2.等出接口 /logout

【场景描述】

前端检测到用户未登录/或者过期，会弹出一个对话框，用户点击对话框中的登录，会直接发起一个get请求，请求这个接口. 此接口直接301到 钉钉扫码登录页面，并在url中加上回调参数(处理钉钉的回调)

示例： 代码中直接 301到 这个地址 http://cas.enbrands.com/ding-login?destUrl=http://your-domain.com/ding-login-cb

上面的URL中，destUrl 参数的值，应该是你的服务器的登录接口url

【需要实现的业务逻辑】

301到扫码地址

3.一般其他接口

【场景描述】

所有其他业务接口，都应该实现 verifySession 这个事情 (即 从cookie中获取token,  拿token去 cas.enbrands.com 查询登录状态， 验证结果),    再执行业务逻辑.

【需要实现的业务逻辑】

1. 从cookie中获取token
2. 拿token去查询cas.enbrands.com

https://cas.enbrands.com/verify?token=${token}

1. 根据结果( result.hasLogin ? )
2. hasLogin = false 直接 401
3. hasLogin = true 有效的话，继续执行业务逻辑
4. 正常返回即可.

Verify 接口的返回，

结果参数 类型 结构 备注

result Object { hasLogin: true，userInfo: { } }
code Number  200 或者 500
error Object 错误信息

1. UserInfo 接口 /user-info

【场景描述】

提供给前端验证用户是否登录。 类似一般业务接口，验证后，只是不执行业务逻辑，直接返回结果即可.

【需要实现的业务逻辑】

1. 从cookie中获取token
2. 拿token去查询cas.enbrands.com

https://cas.enbrands.com/verify?token=${token}

1. 根据结果( result.hasLogin ? )
2. hasLogin = false 直接 401

5.  hasLogin = true 有效的话，返回 200