fix: seed tenant for SSO auth types (OKTA/KEYCLOAK/AZUREAD) on fresh database#6247
Open
ahbeigi wants to merge 2 commits intokeephq:mainfrom
Open
fix: seed tenant for SSO auth types (OKTA/KEYCLOAK/AZUREAD) on fresh database#6247ahbeigi wants to merge 2 commits intokeephq:mainfrom
ahbeigi wants to merge 2 commits intokeephq:mainfrom
Conversation
…database on_starting() skipped try_create_single_tenant() for OKTA, KEYCLOAK, and AZUREAD auth types because they were missing from the allowlist. On a fresh database this leaves the tenant table empty, causing an infinite redirect loop after successful SSO login. Add all three to the allowlist and to excluded_from_default_user (SSO types delegate auth to the IdP so no local user is needed). try_create_single_tenant() is already idempotent, so existing deployments are unaffected.
|
You have used all of your free Bugbot PR reviews. To receive reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
on_starting() skipped try_create_single_tenant() for OKTA, KEYCLOAK, and AZUREAD auth types because they were missing from the allowlist. On a fresh database this leaves the tenant table empty, causing an infinite redirect loop after successful SSO login.
Add all three to the allowlist and to excluded_from_default_user (SSO types delegate auth to the IdP so no local user is needed).
try_create_single_tenant() is already idempotent, so existing deployments are unaffected.
Closes #6246
📑 Description
When
AUTH_TYPEis set toOKTA,KEYCLOAK, orAZUREADand the database is fresh (new PG cluster, PVC recreated, etc.),on_starting()inkeep/api/config.pynever callstry_create_single_tenant()because these auth types are missing from the allowlist. Thetenanttable stays empty, and authenticated users hit an infinite redirect loop between/signinand/incidents.This PR adds the three missing auth types to the allowlist and to
excluded_from_default_userso the tenant row is seeded on startup without creating a local default user (SSO delegates auth to the IdP).Note:
AZUREADhas noIdentityManagerTypesenum entry (it is enterprise-only underee/and loaded dynamically), so the raw string"azuread"is used.OKTA,KEYCLOAK,"azuread"to auth-type allowlistOKTA,KEYCLOAK,"azuread"toexcluded_from_default_user✅ Checks
ℹ Additional Information
The bug went unnoticed because the PVC normally persists across redeployments — the tenant row created during initial setup survives indefinitely. It only surfaces on a fresh database bootstrap.
Workaround for anyone on older versions: add an idempotent
INSERT INTO tenant (id, name) VALUES ('keep', 'Single Tenant') ON CONFLICT (id) DO NOTHING;to the backend init container.