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/clientSecretauth: 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 是否包含该 providersign-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。验证结果配置修改后验证分两步再次运行yarn backstage-cli config:check --strict确认auth配置本身没有语法问题。重新在浏览器中点击该 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
