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

[PR #3286] [MERGED] Forcibly reload app from server when API is redirected #4775

New Issue
Closed
opened 2026-02-28 21:01:04 -06:00 by GiteaMirror · 0 comments
GiteaMirror commented 2026-02-28 21:01:04 -06:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/actualbudget/actual/pull/3286
Author: @TimQuelch
Created: 8/18/2024
Status: ✅ Merged
Merged: 9/25/2024
Merged by: @youngcw

Base: master ← Head: reload-app

📝 Commits (10+)

  • d7e5b6a Add advanced setting to reload app from server
  • e77d22e Add change notes
  • 132fc34 Merge branch 'master' into reload-app
  • d2ef2c4 Automatically reload when API call is redirected
  • 64f4f2a Error on redirect so we don't use the response
  • 6d7808e Remove setting to reload
  • 23d1775 Update release notes
  • 03dfd2c Merge remote-tracking branch 'origin/master' into reload-app
  • 51a9b8b Merge branch 'master' into reload-app
  • eed2101 Merge branch 'master' into reload-app

📊 Changes

7 files changed (+53 additions, -1 deletions)

View changed files

📝 packages/desktop-client/src/browser-preload.browser.js (+16 -0)
📝 packages/desktop-client/src/global-events.ts (+4 -0)
📝 packages/loot-core/src/client/actions/app.ts (+6 -0)
📝 packages/loot-core/src/platform/server/fetch/index.web.ts (+19 -1)
📝 packages/loot-core/src/types/server-events.d.ts (+1 -0)
📝 packages/loot-core/typings/window.d.ts (+1 -0)
➕ upcoming-release-notes/3286.md (+6 -0)

📄 Description

This adds a wrapper around fetch so the application is reloaded when an API request is redirected. The motivation for this is as a workaround for the bug in #2793.

This issue occurs when using forward authentication with something like authentik with a proxy (e.g. caddy, traefik). The proxy checks with the auth service whether all requests to the host are valid, if they are they are forwarded onto the backend server (in this case actual server). If the request is invalid e.g. the cookie has expired or the user has not authenticated yet, then the proxy redirects the user to the authentication page. After authenticating they are redirected back to what they were originally requesting.

For a more standard application; after a authenticatoin cookie has expired the next time the page is reloaded it would redirect to the auth page in order for the user to re-authenticate. However actual uses a service worker pattern where the application code is cached and all requests are served by the worker. This means that reloading the page in the browser does not actually result in a http request to the backend server; which means that that request cannot be redirected to authenticate. This results in an invalid authentication session and API queries to the backend failling because they are redirecting to auth pages.

This PR adds a button in the advanced settings section that un-registers the service worker handling the routing and then reloads the page. This forces the page to be requeried from the backend server which is then able to be redirected to the authentication page.

I've tested this functionality on web, mobile browser, and also iphone PWA and it works as expected.

I've got a couple things I want to check on my implementation:

  • This functionality isn't relevant on electron. I have followed the pattern that the ResetSync follows by disabling the button if we're on electron. I considered also completely hiding the setting when on electron. Which would be preferable?
  • this page mentions that changes to global.Acutal are somewhat fragile. Basically what I've done is defined the new reload function only in the browser version and typed it as maybe undefined. We check if it is defined before trying to call it; this means that on electron it won't be called. Is this the correct way to go about this?

I couldn't think of a solution that was less of a workaround than this. Maybe this reloading could be triggered if an API query gets a 302 to a configurable path? e.g if /sync/sync gets redirected uselessly to auth.mydomain.com then we trigger reloading the whole app so that the user can re-auth? I feel I don't know the full consequences of this solution though. Does anyone have any thoughts on a more automatic solution that will work in a general and/or configurable way?

Edit: After feedback I re-implemented the solution to wrap the API fetch so that if any API call is redirected the application is reloaded.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/actualbudget/actual/pull/3286 **Author:** [@TimQuelch](https://github.com/TimQuelch) **Created:** 8/18/2024 **Status:** ✅ Merged **Merged:** 9/25/2024 **Merged by:** [@youngcw](https://github.com/youngcw) **Base:** `master` ← **Head:** `reload-app` --- ### 📝 Commits (10+) - [`d7e5b6a`](https://github.com/actualbudget/actual/commit/d7e5b6ae27b6418d1ec4d07407a7ea54ae5e9567) Add advanced setting to reload app from server - [`e77d22e`](https://github.com/actualbudget/actual/commit/e77d22ea0d1fff1293925968dcb65444419dc75e) Add change notes - [`132fc34`](https://github.com/actualbudget/actual/commit/132fc34bdf5af45feb68be7b32562fd73bfb2aac) Merge branch 'master' into reload-app - [`d2ef2c4`](https://github.com/actualbudget/actual/commit/d2ef2c4becf82614126e116e04a2e09528de584a) Automatically reload when API call is redirected - [`64f4f2a`](https://github.com/actualbudget/actual/commit/64f4f2a3ee7eb1f60ddccbf1536cbdfa08d0ea31) Error on redirect so we don't use the response - [`6d7808e`](https://github.com/actualbudget/actual/commit/6d7808e0bef41e9cb244b2618a4bb36849442ca0) Remove setting to reload - [`23d1775`](https://github.com/actualbudget/actual/commit/23d17756e0791b744814bd544b9091372833d29c) Update release notes - [`03dfd2c`](https://github.com/actualbudget/actual/commit/03dfd2ccbdbf5f62c8d3b7397f1d50c62525999b) Merge remote-tracking branch 'origin/master' into reload-app - [`51a9b8b`](https://github.com/actualbudget/actual/commit/51a9b8bec6e093574a46196a7102c288303319f0) Merge branch 'master' into reload-app - [`eed2101`](https://github.com/actualbudget/actual/commit/eed2101a3315123e03a0cc4ee7a0be3d84e48759) Merge branch 'master' into reload-app ### 📊 Changes **7 files changed** (+53 additions, -1 deletions) <details> <summary>View changed files</summary> 📝 `packages/desktop-client/src/browser-preload.browser.js` (+16 -0) 📝 `packages/desktop-client/src/global-events.ts` (+4 -0) 📝 `packages/loot-core/src/client/actions/app.ts` (+6 -0) 📝 `packages/loot-core/src/platform/server/fetch/index.web.ts` (+19 -1) 📝 `packages/loot-core/src/types/server-events.d.ts` (+1 -0) 📝 `packages/loot-core/typings/window.d.ts` (+1 -0) ➕ `upcoming-release-notes/3286.md` (+6 -0) </details> ### 📄 Description <!-- Thank you for submitting a pull request! Make sure to follow the instructions to write release notes for your PR — it should only take a minute or two: https://github.com/actualbudget/docs#writing-good-release-notes --> This adds a wrapper around fetch so the application is reloaded when an API request is redirected. The motivation for this is as a workaround for the bug in #2793. This issue occurs when using forward authentication with something like authentik with a proxy (e.g. caddy, traefik). The proxy checks with the auth service whether all requests to the host are valid, if they are they are forwarded onto the backend server (in this case actual server). If the request is invalid e.g. the cookie has expired or the user has not authenticated yet, then the proxy redirects the user to the authentication page. After authenticating they are redirected back to what they were originally requesting. For a more standard application; after a authenticatoin cookie has expired the next time the page is reloaded it would redirect to the auth page in order for the user to re-authenticate. However actual uses a service worker pattern where the application code is cached and all requests are served by the worker. This means that reloading the page in the browser does not actually result in a http request to the backend server; which means that that request cannot be redirected to authenticate. This results in an invalid authentication session and API queries to the backend failling because they are redirecting to auth pages. ~This PR adds a button in the advanced settings section that un-registers the service worker handling the routing and then reloads the page. This forces the page to be requeried from the backend server which is then able to be redirected to the authentication page.~ I've tested this functionality on web, mobile browser, and also iphone PWA and it works as expected. I've got a couple things I want to check on my implementation: - ~This functionality isn't relevant on electron. I have followed the pattern that the [ResetSync](https://github.com/actualbudget/actual/blob/af5fd5b3efeef1628ad583b661fa0539d4d0f63e/packages/desktop-client/src/components/settings/Reset.tsx#L65-L77) follows by disabling the button if we're on electron. I considered also completely hiding the setting when on electron. Which would be preferable?~ - [this page](https://actualbudget.org/docs/contributing/project-details/advice) mentions that changes to global.Acutal are somewhat fragile. Basically what I've done is defined the new reload function only in the browser version and typed it as maybe undefined. We check if it is defined before trying to call it; this means that on electron it won't be called. Is this the correct way to go about this? ~I couldn't think of a solution that was less of a workaround than this. Maybe this reloading could be triggered if an API query gets a 302 to a configurable path? e.g if `/sync/sync` gets redirected uselessly to `auth.mydomain.com` then we trigger reloading the whole app so that the user can re-auth? I feel I don't know the full consequences of this solution though. Does anyone have any thoughts on a more automatic solution that will work in a general and/or configurable way?~ Edit: After feedback I re-implemented the solution to wrap the API fetch so that if any API call is redirected the application is reloaded. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
GiteaMirror added the pull-request label 2026-02-28 21:01:04 -06:00
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 pull-request
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#4775
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?