github-starred/actual
2
0
Fork 0
mirror of https://github.com/actualbudget/actual.git synced 2026-03-10 20:23:07 -05:00
Code Issues 250 Packages Projects Releases 53 Wiki Activity

Feature Request: Environment Variable to Hide Password Login Method #2446

New Issue
Closed
opened 2026-02-28 20:13:59 -06:00 by GiteaMirror · 3 comments
GiteaMirror commented 2026-02-28 20:13:59 -06:00
Owner
Copy Link

Originally created by @dojoca on GitHub (Sep 4, 2025).

Verified feature request does not already exist?

  • I have searched and found no existing issue

💻

  • Would you like to implement this feature?

Pitch: what problem are you trying to solve?

I have ActualBudget deployed with OpenID authentication (using Authentik) and need to balance two conflicting requirements:

Users should only see and use SSO login - I want a clean, secure login experience that directs users to our corporate identity provider with 2FA
API/CLI tools need password authentication - My backup scripts, automation, and CLI tools require password-based API access to function

Currently, ActualBudget's authentication options are all-or-nothing:

  • ACTUAL_OPENID_ENFORCE=true completely disables password auth, breaking my API scripts
  • ACTUAL_OPENID_ENFORCE=false shows a "Select the login method" UI that confuses users and provides an unwanted password login path

This creates a security and user experience problem where I have to choose between functional automation or clean SSO-only user experience.

Describe your ideal solution to this problem

Add a new environment variable ACTUAL_HIDE_PASSWORD_LOGIN=true that:

Hides password login from the web UI - Users only see the OpenID login button, no "Select login method" option
Keeps password authentication functional for API calls - Background scripts and CLI tools continue working
Maintains backward compatibility - Defaults to false (current behavior)
Works alongside existing OpenID settings - Complements rather than replaces ACTUAL_OPENID_ENFORCE

The implementation would affect only the frontend login component while leaving all backend authentication endpoints unchanged.

Example usage - docker compose
environment:

  • ACTUAL_OPENID_ENFORCE=false
  • ACTUAL_HIDE_PASSWORD_LOGIN=true
  • ACTUAL_OPENID_DOMAIN=authentik.company.com
    This gives users a seamless SSO experience while maintaining full API functionality for automation.

Teaching and learning

Discoverability:

Document this variable alongside other OpenID/authentication environment variables
Include it in the "Authentication" section of the deployment docs
Add it to docker-compose examples for enterprise/SSO deployments

Documentation should include:

Clear explanation of when to use this vs ACTUAL_OPENID_ENFORCE
Example docker-compose configurations for common SSO scenarios
Security best practices (e.g., using complex passwords when this option is enabled)
API authentication examples showing how scripts continue to work

Potential user confusion to address:

"Why can't I see password login?" - Documentation should explain this is intentional when the variable is set
"My API stopped working" - Clear examples showing API calls still use the same password endpoint
"What's the difference from OPENID_ENFORCE?" - Comparison table showing the behavior differences

Originally created by @dojoca on GitHub (Sep 4, 2025). ### Verified feature request does not already exist? - [x] I have searched and found no existing issue ### 💻 - [ ] Would you like to implement this feature? ### Pitch: what problem are you trying to solve? I have ActualBudget deployed with OpenID authentication (using Authentik) and need to balance two conflicting requirements: Users should only see and use SSO login - I want a clean, secure login experience that directs users to our corporate identity provider with 2FA API/CLI tools need password authentication - My backup scripts, automation, and CLI tools require password-based API access to function Currently, ActualBudget's authentication options are all-or-nothing: - ACTUAL_OPENID_ENFORCE=true completely disables password auth, breaking my API scripts - ACTUAL_OPENID_ENFORCE=false shows a "Select the login method" UI that confuses users and provides an unwanted password login path This creates a security and user experience problem where I have to choose between functional automation or clean SSO-only user experience. ### Describe your ideal solution to this problem Add a new environment variable ACTUAL_HIDE_PASSWORD_LOGIN=true that: Hides password login from the web UI - Users only see the OpenID login button, no "Select login method" option Keeps password authentication functional for API calls - Background scripts and CLI tools continue working Maintains backward compatibility - Defaults to false (current behavior) Works alongside existing OpenID settings - Complements rather than replaces ACTUAL_OPENID_ENFORCE The implementation would affect only the frontend login component while leaving all backend authentication endpoints unchanged. Example usage - docker compose environment: - ACTUAL_OPENID_ENFORCE=false - ACTUAL_HIDE_PASSWORD_LOGIN=true - ACTUAL_OPENID_DOMAIN=authentik.company.com This gives users a seamless SSO experience while maintaining full API functionality for automation. ### Teaching and learning Discoverability: Document this variable alongside other OpenID/authentication environment variables Include it in the "Authentication" section of the deployment docs Add it to docker-compose examples for enterprise/SSO deployments Documentation should include: Clear explanation of when to use this vs ACTUAL_OPENID_ENFORCE Example docker-compose configurations for common SSO scenarios Security best practices (e.g., using complex passwords when this option is enabled) API authentication examples showing how scripts continue to work Potential user confusion to address: "Why can't I see password login?" - Documentation should explain this is intentional when the variable is set "My API stopped working" - Clear examples showing API calls still use the same password endpoint "What's the difference from OPENID_ENFORCE?" - Comparison table showing the behavior differences
GiteaMirror added the needs votesfeature labels 2026-02-28 20:13:59 -06:00
GiteaMirror commented 2026-02-28 20:13:59 -06:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Sep 4, 2025):

✨ Thanks for sharing your idea! ✨

This repository uses a voting-based system for feature requests. While enhancement issues are automatically closed, we still welcome feature requests! The voting system helps us gauge community interest in potential features. We also encourage community contributions for any feature requests marked as needing votes (just post a comment first so we can help guide you toward a successful contribution).

The enhancement backlog can be found here: https://github.com/actualbudget/actual/issues?q=label%3A%22needs+votes%22+sort%3Areactions-%2B1-desc+

Don’t forget to upvote the top comment with 👍!

@github-actions[bot] commented on GitHub (Sep 4, 2025): :sparkles: Thanks for sharing your idea! :sparkles: This repository uses a voting-based system for feature requests. While enhancement issues are automatically closed, we still welcome feature requests! The voting system helps us gauge community interest in potential features. We also encourage community contributions for any feature requests marked as needing votes (just post a comment first so we can help guide you toward a successful contribution). The enhancement backlog can be found here: https://github.com/actualbudget/actual/issues?q=label%3A%22needs+votes%22+sort%3Areactions-%2B1-desc+ Don’t forget to upvote the top comment with 👍! <!-- feature-auto-close-comment -->
GiteaMirror commented 2026-02-28 20:14:00 -06:00
Author
Owner
Copy Link

@jfdoming commented on GitHub (Sep 4, 2025):

It's an interesting idea. I wonder if it might be better to support user-scoped PATs instead.

@jfdoming commented on GitHub (Sep 4, 2025): It's an interesting idea. I wonder if it might be better to support user-scoped PATs instead.
GiteaMirror commented 2026-02-28 20:14:00 -06:00
Author
Owner
Copy Link

@QasimK commented on GitHub (Feb 15, 2026):

My Actual Budget instance is only accessible to authenticated clients behind my VPN, and the password introduces unnecessary friction to using the application.

However, my request is slightly smaller than this request. I want to remove the login screen if ACTUAL_HIDE_PASSWORD_LOGIN was set and directly start the app. No relation to OpenID.

I'd be willing to implement this. Is there anything I should know before I start?

@QasimK commented on GitHub (Feb 15, 2026): My Actual Budget instance is only accessible to authenticated clients behind my VPN, and the password introduces unnecessary friction to using the application. However, my request is slightly smaller than this request. I want to remove the login screen if `ACTUAL_HIDE_PASSWORD_LOGIN` was set and directly start the app. No relation to OpenID. I'd be willing to implement this. Is there anything I should know before I start?
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
AI generated
API
bank sync
budgeting
bug
can’t replicate
dependencies
docker
documentation
electron
experimental feature
feature
feedback
goal templates
good first issue
help wanted
importers
maintenance
needs info
needs testing
needs triage
needs votes
openid
payees
pull-request
Mirrored from GitHub Pull Request
 regression
reports
responsive
rules
schedules
server
✨ merged
split transactions
tech debt
theme
transaction import
transaction reconciliation
transactions
translations
upstream
user interface
✅ approved
wontfix
No Label feature needs votes
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/actual#2446
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?