整合蓝鲸登录 about bk-user HOT 7 CLOSED

1. 自定义登录, 目前是强需求, 基本每一个企业都做了自定义登录; 所以需要提供相同的能力, 并且, 尽量已有协议不做大的变更(确保自定义代码没有迁移成本或成本足够低); 原先自定义登录成功后, 会同步用户数据到用户管理 重要
2. /api/ 需要关注登录提供给外部调用的接口, 需要支持(v1/v2/v3), ESB 侧变更即可, 然后提供一套新的api(使用新协议) 给到未来的接入方
3. 同一套代码, 需要同时支持企业版/社区版(登录页面不一样), 需要支持国际化
4. 服务的替换, 尽量做到对使用方透明
5. 需要关注下bk_token现有的生成/失效等逻辑, 是否需要做优化

做新方案之前, 需要看下原先的代码以及一些方案

• 登录流程图 https://bk.tencent.com/docs/document/6.0/130/5923
• 自定义登录 https://bk.tencent.com/docs/document/6.0/130/5927
• 应用如何接入登录 https://bk.tencent.com/docs/document/6.0/130/5925

from bk-user.

原有的自定义登录存在一个问题：
登录成功后会触发一次向用户管理同步的“写”操作。由于原来的接口协议比较单薄，这个写操作是放在请求生命周期内实现的，所以当用户管理本身在批量同步数据锁表“写”的时候，包含“写”操作的登录都会卡住，而这个锁表的时间不是完全可控（由用户同步的数据量决定）。

所以针对这一点会做协议改造：

• 自定义登录的数据来源将被挪入到自定义目录或者数据源插件，进行批量同步。登录改造成“纯读”的操作。

整体改造会是在保证使用方和接入方尽可能的平滑升级的前提下，对现有交互协议做升级。

from bk-user.

原有的自定义登录存在一个问题：
登录成功后会触发一次向用户管理同步的“写”操作。由于原来的接口协议比较单薄，这个写操作是放在请求生命周期内实现的，所以当用户管理本身在批量同步数据锁表“写”的时候，包含“写”操作的登录都会卡住，而这个锁表的时间不是完全可控（由用户同步的数据量决定）。

所以针对这一点会做协议改造：

• 自定义登录的数据来源将被挪入到自定义目录或者数据源插件，进行批量同步。登录改造成“纯读”的操作。

整体改造会是在保证使用方和接入方尽可能的平滑升级的前提下，对现有交互协议做升级。

考虑到让各个企业整体改造成本较高，想到一个新的方案解决：
由于这个写入的 API 基本属于自定义登录专用，所以这里可以将这个 API 改造成后台任务，每次写入就直接返回。

@wklken 我的理解，如果该次后台写入发生了失败，对于登录流程实际上没有影响，下次登录重试写入就可以了？

from bk-user.

对于企业应该是有影响的, 登录成功前写数据的目的, 是在登陆成功, 跳转进入saas的时候, 能够通过get_user拿到用户信息

如果异步或写入失败, 此时拿不到用户信息

from bk-user.

对于企业应该是有影响的, 登录成功前写数据的目的, 是在登陆成功, 跳转进入saas的时候, 能够通过get_user拿到用户信息

如果异步或写入失败, 此时拿不到用户信息

明白了。那这里可能还是需要预先同步进来。

from bk-user.

当前仅会将登陆相关代码迁移到用户管理项目中，暂时不对登录进行逻辑改造。

将会迁移的内容：

• 开源代码维护
• 出包流程（包括二进制 & 容器化）

from bk-user.

代码已经整合到 https://github.com/IMBlues/bk-user/tree/login-merge 分支，后期将直接在这里进行维护。

#119 流程整合另拆 issue 处理。

from bk-user.