-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added Header Authentication - Client Part #2362
Conversation
✅ Deploy Preview for actualbudget ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Bundle Stats — desktop-clientHey there, this message comes from a GitHub action that helps you and reviewers to understand how these changes affect the size of this project's bundle. As this PR is updated, I'll keep you updated on how the bundle size is impacted. Total
Changeset No files were changed View detailed bundle breakdownAdded No assets were added Removed No assets were removed Bigger No assets were bigger Smaller No assets were smaller Unchanged
|
Bundle Stats — loot-coreHey there, this message comes from a GitHub action that helps you and reviewers to understand how these changes affect the size of this project's bundle. As this PR is updated, I'll keep you updated on how the bundle size is impacted. Total
Changeset No files were changed View detailed bundle breakdownAdded No assets were added Removed No assets were removed Bigger No assets were bigger Smaller No assets were smaller Unchanged
|
c80d57c
to
7512492
Compare
If the server gets set with the 'header' env var does that block using the password or just allow headers? |
It simply allows the header auth, and if that doesn't work it fail over to the regular password auth |
2882577
to
0b86f79
Compare
Are you testing this with Authentik? Could you write up your steps to get that setup? Im missing something in how that should work |
I run authentik in docker with is pretty straight forward, but my setup also runs with nginx-proxy as my main reverse proxy. So my setup assumes that, other reverse proxy providers could be used. I also had to setup the main urls and such in various places.
Once this is in place, any call to my actual instance get checked for valid Authentik logins (through the magic of nginx). Authentik should then automagically pass on X-ACTUAL-PASSWORD header to my actual instance. I hope that is good enough descriptions, I am happy to give my details on my setup, but not in the public github thread. I also haven't been able to test this end to end fully yet since I wasn't sure how to build a docker image that had my change from both the server and the client repo. |
This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days. |
I am still trying to find time to work on for actualbudget/actual-server#312. |
885ef0e
to
4fc71e6
Compare
@youngcw , I think this is ready for a review. I had it working nicely in my local env. I tested the following scenarios:
|
I do have an authentik test environment working with this, but it took me all weekend to get setup and working due to various issues. So instead I wanted to throw up a test case for others that is a bit easier to test. So if anyone wants to additionally review this and the server side of the change, you can just have nginx sit as a proxy in front of your actual server and have it pass your password as a header. No authentik required for just testing purposes. Here is an example for the nginx proxy: https://github.com/twk3/actual-auth-header-example @joewashear007 now that I have a test environment setup, I can take a closer look at this. |
packages/desktop-client/src/components/manager/subscribe/Login.tsx
Outdated
Show resolved
Hide resolved
packages/desktop-client/src/components/manager/subscribe/Login.tsx
Outdated
Show resolved
Hide resolved
packages/desktop-client/src/components/manager/subscribe/Login.tsx
Outdated
Show resolved
Hide resolved
….tsx Co-authored-by: DJ Mountney <[email protected]>
….tsx Co-authored-by: DJ Mountney <[email protected]>
….tsx Co-authored-by: DJ Mountney <[email protected]>
@joewashear007 both PRs look ready for one final review (other than the merge conflict). And then I will merge. But now that we are in mergefreeze for the release, I am going to hold off on the final review until closer to when the freeze is lifted, so the review and a merge sanity check can happen at the same time. Likely the end of next week, or over that weekend. |
Thanks for bringing up this feature. I personally can confirm it's an important one since I have a Kemp Virtual Load Master (VLM) in front of Actual with LDAP preauthentication enabed on the VLM - and I was struggling to make it work. So this header passing the "authenticated" flag to Actual server is a super cool feature. I am looking forward to it. |
Thank you @twk3 - I will be pretty excited to get this merged |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ran a final round of testing today. Looks good.
There is some weirdness around signout when using the header (as we just sign back in). But the fact that we have the change server menu option, allows you to instead use that to 'sign out'.
Thanks @joewashear007 for your long work on this contribution
Sorry to necro @joewashear007, Can you confirm if your proxy setup allows you to use the desktop app and web app without any sever connection issues? I've using Authelia + Clourflare tunnels and have trouble getting the desktop app to work as the calls to the API actually return a 302 redirect which at the moment the |
@Shazib - so the PWA/service worker network caching for offline usage is a separate issue (which is quite annoying). This PR works with passing the password via hreader from the proxy. A fix for the offline usage with an auth proxy would need to happen with the service workers. It needs a URL endpoint that can detect if the proxy is expired that is not cached. A work around that I have been using on desktop browsers is to unregister the service worker and then reload. I would like to make a PR to fix this, but I haven't gotten the time yet |
Thanks for the info @joewashear007! I will give adding the header a go. For now, to solve the other issue, I've added a bypass rule using cloudflare's 'warp' client. So if my specific PC tries to access my actual instance it bypasses the auth layer entirely. I guess in a perfect would we would add the OAuth2 capabilities directly to Actual. in the browser the auth redirect works ok, but the desktop app needs additional handling. |
Is there a way to completely remove the need to set a password? For a hosting setup using a reverse proxy and auth provider, this should also be unneccessary. In fact, IMO there should be no password at all. |
This sort of circles back to my original query, and would require Actual to natively support OIDC so it can pass auth responsibilities off to your auth provider. This is not something that is currently supported so someone would need to implement it and submit a PR, it will likely not be a priority for the core team. |
Client Side modifications for actualbudget/actual-server#312 for #1092
This change added the check for the "loginMethod" from the
/account/use-bootstrap
endpoint. It will then adjust the login page to automatically call the login endpoint if the loginMethod == "header".I was having trouble getting this built and tested, so I would appreciate pointers or testing tips.
Thanks!