fix(auth): tolerate string booleans in oidc provider config - #2606
Merged
Conversation
Regression test for #2599. Exercises getProviderFromMap with native bools and with stringified booleans ("true"/"false"/"1"/"0") for all four boolean provider fields — emailfallback, usernamefallback, forceuserinfo, requireavailability. From env vars and from the GetConfigValueFromFile path every leaf arrives as a string, so the current .(bool) assertion silently zeros these fields.
The four boolean OIDC provider fields (emailfallback, usernamefallback, forceuserinfo, requireavailability) were parsed with a strict .(bool) type assertion. That works for YAML/JSON config where leaves are native bools, but fails for every other input path: env vars always arrive as strings, and GetConfigValueFromFile (used by the *.file Docker secret convention) also always returns strings. The assertion would silently zero the field for emailfallback and usernamefallback, and log an error and zero the field for forceuserinfo and requireavailability, which is what #2599 reports. Extract a small parseBoolField helper that accepts both native bools and strings (via strconv.ParseBool) and logs a parse error from each call site. This also fixes the previously-silent drop of stringified emailfallback / usernamefallback values — those now log an error if the input is garbage, matching the behaviour of the other two fields. Fixes #2599
github-actions
Bot
added
area/auth
kolaente
approved these changes
Apr 11, 2026
kolaente
enabled auto-merge
April 11, 2026 19:03
Preview DeploymentPreview deployments for this PR are available at:
The preview environment will start automatically on first visit. Subsequent pushes to this PR will update the Run locally with Dockerdocker pull ghcr.io/go-vikunja/vikunja:pr-2606
docker run -p 3456:3456 ghcr.io/go-vikunja/vikunja:pr-2606Last updated for commit a11abb4 |
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
2 participants
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.
The four OIDC provider boolean fields (
emailfallback,usernamefallback,forceuserinfo,requireavailability) were parsed with a strict.(bool)type assertion, which fails whenever config arrives as strings — i.e. from environment variables or the*.fileDocker secret convention (both flow throughGetConfigValueFromFilewhich always returns strings).requireavailabilityis the one #2599 reports.Extract a small
parseBoolFieldhelper that accepts both native bools and strings viastrconv.ParseBool.Bonus fix: the same bug was silently dropping stringified
emailfallback/usernamefallbackvalues with no log at all — those two call sites had noelsebranch. They now log a parse error from the shared helper's code path, matching the other two fields.Fixes #2599