企业官网建设流程全解析

Backstage 登录报 "provider is not configured to support sign-in" 怎么排查？

【免费下载链接】backstageBackstage is an open framework for building developer portals项目地址: https://gitcode.com/GitHub_Trending/ba/backstage

当你点击 Backstage 登录页面上的某个认证 provider（例如 GitHub）后，页面弹出The '<provider>' provider is not configured to support sign-in错误时，说明该 auth provider 被注册进后端了，但没有被配置为允许 sign-in。解决这个问题的路径是：确认signIn.resolvers配置是否缺失、配置是否有语法错误、前端 SignInPage 是否包含该 provider，然后把合适的 resolver 加回 provider 配置中。

Backstage 中每个 auth provider 的默认用途只是访问委托（代表用户向外部系统请求资源），并不包含 sign-in 能力。从 Backstage 1.1 起，所有 sign-in resolver 的默认实现都被移除了——这是一次必要的安全修复。因此从 1.1 之前版本升级上来、或从未显式配置过 resolver 的实例，登录时就会遇到这个错误。

上图是文档中给出的 GitHub provider 触发该错误时的实际界面。

排查步骤

按以下顺序检查，定位错误的具体来源：

1. 检查 provider 配置中是否缺少signIn.resolvers

打开你的app-config.yaml，找到auth.providers.<provider>下与你当前auth.environment匹配的那一层配置。这个错误最常见的直接原因，就是该层配置里没有signIn.resolvers字段。

以 GitHub provider 为例，未配置 sign-in 时只有clientId/clientSecret：

auth: environment: development providers: github: development: clientId: ${AUTH_GITHUB_CLIENT_ID} clientSecret: ${AUTH_GITHUB_CLIENT_SECRET}

如果缺少signIn.resolvers，就是根因，按下一节的说明补上即可。

2. 配置已存在但仍报错：检查配置的语法错误

如果signIn.resolvers已经写进配置里、登录时却仍然报同样的错误，说明 Auth Provider 配置里可能存在语法错误，导致配置没有生效。运行下面的命令来识别配置问题：

yarn backstage-cli config:check --strict

该命令会帮助定位auth配置中的错误。修复后重新登录验证。

3. 检查前端 SignInPage 是否包含该 provider

sign-in 需要在前端和auth后端两侧都完成配置。新前端系统中，SignInPage需要以SignInPageBlueprint的形式注册到应用里，并且provider指向该 auth provider（例如githubAuthApiRef）。如果前端没有把这个 provider 放进 SignInPage，登录流程自然不会走通。具体写法参考 Authentication in Backstage 的 "Sign-in Configuration" 一节。

添加 sign-in resolver 配置

确认配置缺失后，在对应 provider 的配置下添加signIn.resolvers。下面是文档中给出的 GitHub 示例：

auth: environment: development providers: github: development: clientId: ${AUTH_GITHUB_CLIENT_ID} clientSecret: ${AUTH_GITHUB_CLIENT_SECRET} enterpriseInstanceUrl: ${AUTH_GITHUB_ENTERPRISE_INSTANCE_URL} signIn: resolvers: - resolver: usernameMatchingUserEntityName

选择 resolver 时注意：

• 可用 resolver 的列表因 provider 而异，很多依赖上游 provider 返回的信息模型，具体清单需查对应 provider 的文档。usernameMatchingUserEntityName是 GitHub provider 特有的；emailMatchingUserEntityProfileEmail和emailLocalPartMatchingUserEntityName则是各 auth provider 通用的选项。
• 每个 auth provider只应配置一个 sign-in resolver。配置多个 resolver 只有在允许用户以多种方式登录时才有意义，但会增加账号被劫持的风险。
• 使用emailLocalPartMatchingUserEntityName时，文档强烈建议同时设置allowedDomains，确保只有授权用户能登录：

auth: providers: github: development: ... signIn: resolvers: - resolver: emailLocalPartMatchingUserEntityName allowedDomains: - acme.org

另外，用npx @backstage/create-app创建的项目默认带有 guest auth provider，它让所有用户共享同一个 guest 身份，仅用于本地测试；该 provider 在非 development 环境下会被显式禁用。生产环境应换成正式的 auth provider 并配置其 resolver。

验证结果

配置修改后，验证分两步：

1. 再次运行yarn backstage-cli config:check --strict，确认auth配置本身没有语法问题。
2. 重新在浏览器中点击该 provider 登录。provider is not configured to support sign-in消失、登录流程进入 provider 的授权环节，说明 resolver 已生效。

登录仍失败：用户不在 Catalog 中

配置好 resolver 后，如果登录报出的是另一个错误——Failed to sign-in, unable to resolve user identity（或 "User not found"），说明认证本身已成功，但 resolver 在 Catalog 里找不到匹配的 user 实体。很多内置 resolver 都要求 Catalog 中存在对应的用户。

解决方式是把组织中的 User / Group 数据导入 Catalog，可以使用现成的 Org Data provider（如 Entra ID (Azure AD/MS Graph)、GitHub、GitLab 等），或按 Custom Entity Provider 文档自建。更多细节见 Sign-in Identities and Resolvers 和 Troubleshooting Auth。

如果确认当前 resolver 找不到用户是因为"该用户实体本就不在 Catalog 里"，也可以评估dangerouslyAllowSignInWithoutUserInCatalog选项来跳过 Catalog 检查——但文档明确警告该选项在生产环境有安全风险（未入册的用户会获得与 guest 相同的权限预期），应仅在充分理解权限影响后使用。

【免费下载链接】backstageBackstage is an open framework for building developer portals项目地址: https://gitcode.com/GitHub_Trending/ba/backstage