github-starred/actual
2
0
Fork 0
mirror of https://github.com/actualbudget/actual.git synced 2026-07-16 07:04:23 -05:00
Code Issues 3.0k Packages Projects Releases 58 Wiki Activity

[GH-ISSUE #1092] Proxy authentication by http header value #41953

New Issue
Closed
opened 2026-04-26 01:30:07 -05:00 by GiteaMirror · 8 comments
GiteaMirror commented 2026-04-26 01:30:07 -05:00
Owner
Copy Link

Originally created by @max-tet on GitHub (Mar 14, 2023).
Original GitHub issue: https://github.com/actualbudget/actual/issues/1092

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?

When self-hosting multiple applications, you really want to have a single point for user management and authentication. It is annoying to login to each and every app seperately.

Describe your ideal solution to this problem

A pretty simple way to centralize authentication is achieved by deploying apps behind a reverse proxy, and use proxy auth. The proxy handles authentication in some way and sets http headers containing the username that was successfully logged-in. The apps read the headers and associate incoming requests to that user.

The perfect proxy auth feature for me would work like this:

  1. Start the app with additional environment variables:
  • containing the name of the initial admin user (e.g. admin=admin_user)
  • enabling proxy auth (e.g. proxy_auth=true)
  • setting the key of the http header that contains the username (e.g. auth_header=X-Authenticated-User)
  1. Configure the reverse proxy to authenticate incoming requests in any way you like.
  2. Let the reverse proxy set X-Authenticated-User to the authenticated username on every request.
  3. The app treats the requests as if they belong to the appropriate user session.
  4. Bonus: if the app does not know the username, it creates a new user with that name.

Other SSO methods like OIDC still require the user to login with each app, even it no credentials are required. It is still an additional step that is unneeded and hurting the user experience.

Here are some examples of apps that feature proxy authentication: FreshRSS, LinkDing, Navidrome.

Additional context:
I am using the app for this product. Since this is a single-user platform, users really should see no login screen at all, not even for SSO.

Teaching and learning

The documentation should contain a section about proxy auth where the configuration is described.

Originally created by @max-tet on GitHub (Mar 14, 2023). Original GitHub issue: https://github.com/actualbudget/actual/issues/1092 ### 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? When self-hosting multiple applications, you really want to have a single point for user management and authentication. It is annoying to login to each and every app seperately. ### Describe your ideal solution to this problem A pretty simple way to centralize authentication is achieved by deploying apps behind a reverse proxy, and use proxy auth. The proxy handles authentication in some way and sets http headers containing the username that was successfully logged-in. The apps read the headers and associate incoming requests to that user. The perfect proxy auth feature for me would work like this: 1. Start the app with additional environment variables: * containing the name of the initial admin user (e.g. admin=admin_user) * enabling proxy auth (e.g. proxy_auth=true) * setting the key of the http header that contains the username (e.g. auth_header=X-Authenticated-User) 2. Configure the reverse proxy to authenticate incoming requests in any way you like. 3. Let the reverse proxy set X-Authenticated-User to the authenticated username on every request. 4. The app treats the requests as if they belong to the appropriate user session. 5. Bonus: if the app does not know the username, it creates a new user with that name. Other SSO methods like OIDC still require the user to login with each app, even it no credentials are required. It is still an additional step that is unneeded and hurting the user experience. Here are some examples of apps that feature proxy authentication: [FreshRSS](http://freshrss.github.io/FreshRSS/en/admins/09_AccessControl.html), [LinkDing](https://github.com/sissbruecker/linkding/blob/master/docs/Options.md#ld_enable_auth_proxy), [Navidrome](https://www.navidrome.org/docs/usage/security/#reverse-proxy-authentication). Additional context: I am using the app for [this product](https://getportal.org/). Since this is a single-user platform, users really should see no login screen at all, not even for SSO. ### Teaching and learning The documentation should contain a section about proxy auth where the configuration is described.
GiteaMirror added the feature label 2026-04-26 01:30:07 -05:00
GiteaMirror commented 2026-04-26 01:30:09 -05:00
Author
Owner
Copy Link

@j-f1 commented on GitHub (Mar 14, 2023):

How would you feel about generating an auth token and then having the proxy inject a Authorization: Bearer ${token} header in all requests? I don’t think most existing setups would work well since they are intended to work for multiple users, although we certainly could move to one of them if/when we add multi-user support.

<!-- gh-comment-id:1573296014 --> @j-f1 commented on GitHub (Mar 14, 2023): How would you feel about generating an auth token and then having the proxy inject a `Authorization: Bearer ${token}` header in all requests? I don’t think most existing setups would work well since they are intended to work for multiple users, although we certainly could move to one of them if/when we add multi-user support.
GiteaMirror commented 2026-04-26 01:30:09 -05:00
Author
Owner
Copy Link

@max-tet commented on GitHub (Mar 14, 2023):

Right, I did not consider that Actual has no user management/is a single-user app.

In that case, tbh, the most straightforward approach would be to offer an option to just disable the password prompt completely. But I have seen a discusson about this which was deemed too insecure if I am not mistaken. I personally don't agree, after all the option would have to be actively enabled.

The alternative with the token is an interesting option. If it works for me would depend on how the token is generated and how the proxy would get to it. If Actual generates it itself, I don't think it would work. It would have to be known before the app is started.

It could be set by an environment variable, e.g. AUTH_TOKEN=supersecrettoken. Perhaps also specify the header key like AUTH_TOKEN_HEADER=auth-token. Then, the proxy would set the header auth-token=supersecrettoken. (I would skip the Bearer prefix.)

But again, an option to simply disable the password auth is the most simple approach and totally legitimate imo. You can add a large warning label in the docs that people should setup their proxy properly when using the option.

<!-- gh-comment-id:1573296022 --> @max-tet commented on GitHub (Mar 14, 2023): Right, I did not consider that Actual has no user management/is a single-user app. In that case, tbh, the most straightforward approach would be to offer an option to just disable the password prompt completely. But I have seen a discusson about this which was deemed too insecure if I am not mistaken. I personally don't agree, after all the option would have to be actively enabled. The alternative with the token is an interesting option. If it works for me would depend on how the token is generated and how the proxy would get to it. If Actual generates it itself, I don't think it would work. It would have to be known before the app is started. It could be set by an environment variable, e.g. `AUTH_TOKEN=supersecrettoken`. Perhaps also specify the header key like `AUTH_TOKEN_HEADER=auth-token`. Then, the proxy would set the header `auth-token=supersecrettoken`. (I would skip the `Bearer` prefix.) But again, an option to simply disable the password auth is the most simple approach and totally legitimate imo. You can add a large warning label in the docs that people should setup their proxy properly when using the option.
GiteaMirror commented 2026-04-26 01:30:10 -05:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jun 2, 2023):

✨ Thanks for sharing your idea! ✨

This repository is now using lodash style issue management for enhancements. This means enhancement issues will now be closed instead of leaving them open. This doesn’t mean we don’t accept feature requests, though! We will consider implementing ones that receive many upvotes, and we welcome contributions for any feature requests marked as needing votes (just post a comment first so we can help you make 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 👍!

<!-- gh-comment-id:1573296308 --> @github-actions[bot] commented on GitHub (Jun 2, 2023): :sparkles: Thanks for sharing your idea! :sparkles: This repository is now using lodash style issue management for enhancements. This means enhancement issues will now be closed instead of leaving them open. This doesn’t mean we don’t accept feature requests, though! We will consider implementing ones that receive many upvotes, and we welcome contributions for any feature requests marked as needing votes (just post a comment first so we can help you make 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-04-26 01:30:10 -05:00
Author
Owner
Copy Link

@MFYDev commented on GitHub (Sep 7, 2023):

Hi, just think this and found the issue, is there any progress here?

<!-- gh-comment-id:1709463552 --> @MFYDev commented on GitHub (Sep 7, 2023): Hi, just think this and found the issue, is there any progress here?
GiteaMirror commented 2026-04-26 01:30:11 -05:00
Author
Owner
Copy Link

@deathblade666 commented on GitHub (Jan 12, 2024):

Hello, I was pointed to this issue as i was asking about this very thing. trying to setup SSO but dont want to have to double auth. as detailed above if disabling the password prompt or using proxy auth headers could be a thing that would make this possible!!

<!-- gh-comment-id:1889773101 --> @deathblade666 commented on GitHub (Jan 12, 2024): Hello, I was pointed to this issue as i was asking about this very thing. trying to setup SSO but dont want to have to double auth. as detailed above if disabling the password prompt or using proxy auth headers could be a thing that would make this possible!!
GiteaMirror commented 2026-04-26 01:30:12 -05:00
Author
Owner
Copy Link

@joewashear007 commented on GitHub (Feb 9, 2024):

Hell, I am use Authentik for Proxy SSO. I see that the app uses the X-ACTUAL-TOKEN header which it got from the api. Is it possible to have the nginx proxy pass this header along? I tried setting it with proxy_set_header X-ACTUAL-TOKEN <value from application> but it sadly didn't work.

I would love to see this implemented, so that I can do the authentication via Authentik, and them my wife i could simple access the application with our own individual accounts (on the proxy side - i understand there is only one actual account)

<!-- gh-comment-id:1936040016 --> @joewashear007 commented on GitHub (Feb 9, 2024): Hell, I am use Authentik for Proxy SSO. I see that the app uses the `X-ACTUAL-TOKEN` header which it got from the api. Is it possible to have the nginx proxy pass this header along? I tried setting it with `proxy_set_header X-ACTUAL-TOKEN <value from application>` but it sadly didn't work. I would love to see this implemented, so that I can do the authentication via Authentik, and them my wife i could simple access the application with our own individual accounts (on the proxy side - i understand there is only one actual account)
GiteaMirror commented 2026-04-26 01:30:13 -05:00
Author
Owner
Copy Link

@d3x7r0 commented on GitHub (Feb 23, 2024):

Just adding my 2 cents to this feature request. I'm looking into setting up Actual for myself as well and I already use Authelia for authentication which supports header based Auth. It would be great to have Actual support these headers as well.

Here's Authelia's documentation on the feature. They forward 4 headers: Username, User Groups, User Display Name and User Email. Then, tools that support this will usually have some sort of configuration for these headers and a whitelist for proxies they accept headers from (see Organizr's example)

<!-- gh-comment-id:1961182995 --> @d3x7r0 commented on GitHub (Feb 23, 2024): Just adding my 2 cents to this feature request. I'm looking into setting up Actual for myself as well and I already use Authelia for authentication which supports header based Auth. It would be great to have Actual support these headers as well. [Here's Authelia's documentation on the feature](https://www.authelia.com/integration/trusted-header-sso/introduction/). They forward 4 headers: Username, User Groups, User Display Name and User Email. Then, tools that support this will usually have some sort of configuration for these headers and a whitelist for proxies they accept headers from ([see Organizr's example](https://www.authelia.com/integration/trusted-header-sso/organizr/))
GiteaMirror commented 2026-04-26 01:30:14 -05:00
Author
Owner
Copy Link

@youngcw commented on GitHub (Jun 13, 2024):

Im going to close this off as completed. The ability to pass a password via header to bypass the server password was added in v24.6.0.

For discussion on more involved login/users please use #524

<!-- gh-comment-id:2166243538 --> @youngcw commented on GitHub (Jun 13, 2024): Im going to close this off as completed. The ability to pass a password via header to bypass the server password was added in v24.6.0. For discussion on more involved login/users please use #524
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
tech-support
theme
transaction import
transaction reconciliation
transactions
translations
upstream
user interface
✅ approved
wontfix
No Label feature
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#41953
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?