fix(auth): harden dashboard auth modes (Codex review follow-up)#384
Merged
fix(auth): harden dashboard auth modes (Codex review follow-up)#384
Conversation
Add password_session_active field to session response so the frontend can hide Change/Remove buttons when the user is authenticated only via proxy header (no active cookie-based password session). Without this, trusted_header users with a configured fallback password see password management buttons that fail with 'Authentication required' because the backend requires a password session for those operations.
…without password session - Add _ensure_password_management_enabled guard to verify_totp endpoint (was the only auth endpoint missing it, allowing stale pre-TOTP sessions to complete login after switching to disabled mode) - Condition TotpSettings rendering on passwordSessionActive so proxy-only users in trusted_header mode don't see controls that always fail
…e header - Add verify dialog so proxy-authenticated users can re-establish a password session to unlock Change/Remove/TOTP controls - Block Cookie as a dashboard auth proxy header to prevent browser session cookies from being treated as trusted identity assertions
…serve TOTP requirement for proxy fallback - password_session_active now means fully authorized (password + TOTP if required), not just password-verified - Proxy-auth branch preserves totp_required_on_login when TOTP is pending instead of always overriding to false - Verify dialog gains a TOTP step so proxy-authenticated users can complete the full fallback login flow inline
…nt stale cookie leaking management UI
|
| GitGuardian id | GitGuardian status | Secret | Commit | Filename | |
|---|---|---|---|---|---|
| 30078943 | Triggered | Generic Password | db76398 | app/modules/dashboard_auth/api.py | View secret |
| 30078943 | Triggered | Generic Password | db76398 | app/modules/dashboard_auth/api.py | View secret |
🛠 Guidelines to remediate hardcoded secrets
- Understand the implications of revoking this secret by investigating where it is used in your code.
- Replace and store your secrets safely. Learn here the best practices.
- Revoke and rotate these secrets.
- If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.
To avoid such incidents in the future consider
- following these best practices for managing and storing secrets including API keys and other credentials
- install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.
🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.
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
1 participant
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.
Summary
Follow-up fixes for #366 (dashboard proxy auth modes) found during adversarial Codex review (5 rounds).
Changes
password_session_activefield — Distinguishes proxy-authenticated users from password-session holders so the SPA doesn't show unusable Change/Remove/TOTP buttons_ensure_password_management_enabledtoverify_totpendpoint (was the only auth endpoint missing it)cookieto_FORBIDDEN_PROXY_AUTH_HEADERSto prevent misconfigured proxy headers from collapsing the trust modelpassword_session_activenow requires both password AND TOTP verification (if enabled), preventing TOTP bypass via partial sessionpassword_session_activeonpassword_requiredso expired cookies from a removed password don't surface management UIKnown limitation (separate issue)
_is_trusted_proxy_sourceuses post-ProxyHeadersMiddlewarerequest.client.hostinstead of raw socket peer IP. Affects localhost reverse proxy setups (Authelia/Caddy/Nginx). Pre-existing in #366's original design — needs ASGI-level middleware to capture raw peer.Testing
test_trusted_header_proxy_auth_with_fallback_password_reports_no_active_session)