| | |
|---|
| | | | # | 配置位置 | 内容 | 缺失后果 | |
|---|
| | | |---|----------|------|----------| |
|---|
| | | | 1 | `application-<profile>.yaml` → `wx.cp.*` | corp-id、agent-id、secret、token、aes-key | 回调接口无法解密，URL 验证失败 | |
|---|
| | | | 2 | `application-<profile>.yaml` → `justauth.type.WECHAT_ENTERPRISE` | client-id、client-secret、agent-id、redirect-uri | 调用 `social-auth-redirect` 抛 `NullPointerException` | |
|---|
| | | | 3 | 数据库 `system_social_client` | social_type=30、user_type=1、client_id=CorpId、client_secret=Secret、agent_id、status=0、deleted=0 | `social-auth-redirect` 报"社交平台(30) 不存在" | |
|---|
| | | | 2 | `application.yaml` → `justauth.type.WECHAT_ENTERPRISE`（**全局，不随 profile 变**） | client-id、client-secret、agent-id、**`ignore-check-redirect-uri: true`** | 调用 `social-auth-redirect` 抛 `AuthException: Illegal redirect uri [WECHAT_ENTERPRISE]` | |
|---|
| | | | 3 | 数据库 `system_social_client` | social_type=30、**user_type=2**、client_id=CorpId、client_secret=Secret、agent_id、status=0、deleted=0 | 只用 yaml 里的密钥，无法在后台改；填错 user_type 则该行查不到 | |
|---|
| | | |
|---|
| | | **第 2 项容易漏掉**：`AuthRequestFactory` 需要先从 yaml 拿到"社交平台基类配置"才能构造出对应的 `AuthRequest` 实例，之后才会用数据库里的密钥覆盖它。所以即使密钥全都配在数据库，yaml 里也必须保留一份占位配置。 |
|---|
| | | |
|---|
| | | **第 2 项里 `ignore-check-redirect-uri: true` 最容易漏**。yudao 的设计是 `redirect-uri` 不写死——`SocialClientServiceImpl.getAuthorizeUrl` 最后会用 `HttpUtils.replaceUrlQuery` 把 `redirect_uri` 换成前端按当前浏览器地址传进来的值。但 JustAuth 的 `AuthDefaultRequest` 构造时会调 `AuthChecker.checkConfig(AuthConfig, AuthSource)`： |
|---|
| | | |
|---|
| | | ```java |
|---|
| | | if (config.isIgnoreCheckRedirectUri()) { |
|---|
| | | return; // 有这个开关才放行 |
|---|
| | | } |
|---|
| | | if (StringUtils.isEmpty(redirectUri)) { |
|---|
| | | throw new AuthException(AuthResponseStatus.ILLEGAL_REDIRECT_URI, source); |
|---|
| | | } |
|---|
| | | ``` |
|---|
| | | |
|---|
| | | 也就是说**不写 `redirect-uri` 的前提就是打开这个开关**，两者缺一不可。只删 `redirect-uri` 而漏了开关，扫码时会在 `AuthRequestFactory.getDefaultRequest` 构造 `AuthWeChatEnterpriseQrcodeRequest` 的那一刻抛 `AuthException: Illegal redirect uri [WECHAT_ENTERPRISE]`——异常发生在构造期，早于用数据库密钥覆盖的那一步，所以配置了 `system_social_client` 也救不了。 |
|---|
| | | |
|---|
| | | **第 2 项为什么放 `application.yaml` 而不是某个 profile**：`YudaoJustAuthConfiguration` 上的 `@ConditionalOnProperty(prefix = "justauth", value = {"enabled"}, havingValue = "true", matchIfMissing = true)` 让 `AuthRequestFactory` **无论配没配都会创建**。缺配置不等于"关闭社交登录"，而是一个运行期才暴露的坑：请求走到 `AuthRequestFactory.get()` 时先按 `justauth.type` 查不到，再回落到 `justauth.extend` 分支，而 `JustAuthProperties.extend` 默认就是 `null`，直接 `NullPointerException`。 |
|---|
| | | |
|---|
| | | 这段配置历史上只存在于 `application-local.yaml`，导致用 `dev` / `test` / `chdl` / `kyzn` / `wtxc` / `yzfx` / `zsjc` 任一 profile 启动时，企业微信扫码登录必炸，并且报的是 `AuthRequestFactory.get` 第 104 行的 NPE，很难一眼看出是配置缺失。上移到全局配置文件后，这一类问题从结构上被消除。 |
|---|
| | | |
|---|
| | | **代码层兜底**：`AuthRequestFactory.get()` 已加判空守卫——`properties.getExtend()` 为 null 时跳过自定义分支，由既有逻辑抛出可读的 `AuthException`，不再抛 `NullPointerException`。 |
|---|
| | | |
|---|
| | | ### 回调 URL 配置 |
|---|
| | | |
|---|
| | | 在企业微信管理后台 → 应用管理 → 自建应用 → 「接收消息」→「设置API接收」： |
|---|
