feat(oidc): set the default group from the environment, by name

Without it every account auto-created through the env provider fell back to
Viewers (routes/mfa.py), and because the provider is locked the UI could not
correct it either -- a real limitation for a declarative deployment running
BAMBUDDY_OIDC_AUTO_CREATE_USERS=true.

BAMBUDDY_OIDC_DEFAULT_GROUP names a group rather than an id: ids are handed out
per installation, so the same compose file would point at a different group on
the next deployment. The name is matched exactly, resolved against the database
before anything is written, and default_group_id joins _APPLIED_FIELDS so
dropping the variable clears the group again -- the environment is the whole
truth for this row.

A name that matches no group is refused rather than defaulted: silently landing
users in Viewers is the failure this variable exists to remove, and the API
already answers 422 for a default_group_id that does not exist. The refusal is
logged and survivable, and it says which of the two cases happened, because
they differ sharply -- an existing provider keeps running on its last good
config, while on a first boot nothing is created and no SSO button appears.

Raised by maziggy in review of #2625 as a scope decision; documented in
.env.example and in the companion wiki PR.
This commit is contained in:
Marian
2026-07-30 14:43:23 +00:00
parent ac2f4d058e
commit 3c679459e1
5 changed files with 182 additions and 0 deletions
+10
View File
@@ -98,9 +98,19 @@ LOG_TO_FILE=true
# BAMBUDDY_OIDC_REQUIRE_EMAIL_VERIFIED=true
# BAMBUDDY_OIDC_ICON_URL=
# BAMBUDDY_OIDC_AUTOLOGIN=false
# BAMBUDDY_OIDC_DEFAULT_GROUP=
#
# Booleans accept true/1/yes; anything else keeps the default.
#
# DEFAULT_GROUP is the group new users land in when AUTO_CREATE_USERS is on;
# without it they get Viewers. It matches a group NAME exactly (case-sensitive)
# -- group ids are assigned per install, so the same compose file would point at
# a different group on every deployment. A name that matches no group is
# refused: the provider is left as it was and the reason is logged, rather than
# quietly creating under-privileged users the locked UI could not correct. On a
# FIRST boot that means no provider is created at all and no SSO button appears
# -- create the group first. Removing the variable clears the group again.
#
# AUTO_LINK_EXISTING binds an OIDC identity to an existing local account with
# the same email address. With EMAIL_CLAIM=email it is refused unless
# REQUIRE_EMAIL_VERIFIED=true, because an identity provider that does not