共计 1089 个字符，预计需要花费 3 分钟才能阅读完成。
基于前后端拆散的根本架构，利用的后端服务应该至多 实现 以下接口:
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 查问登录状态，验证后果), 再执行业务逻辑.
【须要实现的业务逻辑】
- 从 cookie 中获取 token
- 拿 token 去查问 cas.enbrands.com
https://cas.enbrands.com/verify?token=${token}
- 依据后果(result.hasLogin ?)
- hasLogin = false 间接 401
- hasLogin = true 无效的话，继续执行业务逻辑
- 失常返回即可.
Verify 接口的返回，
后果参数 类型 构造 备注
result Object {hasLogin: true，userInfo: {} }
code Number 200 或者 500
error Object 错误信息
- UserInfo 接口 /user-info
【场景形容】
提供给前端验证用户是否登录。相似个别业务接口，验证后，只是不执行业务逻辑，间接返回后果即可.
【须要实现的业务逻辑】
- 从 cookie 中获取 token
- 拿 token 去查问 cas.enbrands.com
https://cas.enbrands.com/verify?token=${token}
- 依据后果(result.hasLogin ?)
- hasLogin = false 间接 401
5. hasLogin = true 无效的话，返回 200
