coffey-labs/ihasmail
1
2 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 6 Wiki Activity Sponsor

Installed PWA can never sign in again after a front-door auth proxy (Cloudflare Access) session expires: "Network error" #47

New Issue
Closed
opened 2026-10-09 22:17:32 +00:00 by dwofford · 3 comments
dwofford commented 2026-10-09 22:17:32 +00:00
Copy link
Copy source

Summary
When ihasmail is installed as a Home Screen app and sits behind an authenticating reverse proxy (Cloudflare Access), the app can't be signed in to once the proxy's session cookie expires. Every sign-in attempt shows "Network error. Please check your connection." The only way back in is to delete the Home Screen app and install it again. The same account works normally in a regular browser tab.

Steps to reproduce

  1. Put ihasmail behind Cloudflare Access (any proxy that answers an unauthenticated request with a 302 to its own login page on another origin).
  2. On an iPhone, open ihasmail in Safari, pass the Access login, and Add to Home Screen with "Open as Web App" on. The installed URL is https:///mail, from the manifest's start_url "mail".
  3. Let the Access session expire (ours is 168 h), or clear the Access cookie.
  4. Open the Home Screen app and try to sign in.

Expected
The app notices it is no longer authenticated at the proxy and does a real navigation, so the proxy can show its login page.

Actual

  • The login page renders from the service worker cache. The logo image is broken, because its request is redirected to the proxy too.
  • Signing in shows "Network error. Please check your connection." on every attempt.
  • The request never reaches ihasmail's server or Stalwart: neither logs anything for it.
  • This continues until the Home Screen app is removed and installed again.

Cause (from reading web/public/sw.js)
For navigations matching APP_ROUTE (mail|search|contacts|calendar|files|settings|admin|login), the fetch handler returns the cached shell whenever one exists and only refreshes it in the background. An installed app always launches into "mail", so it never makes a navigation that reaches the network. The proxy's 302 only ever hits /api/* fetches, which are redirected cross-origin and fail. The background refresh also gets the redirect (res.ok is false), so the shell is never replaced.

Suggested fix
When an /api/* request or the background navigation refresh comes back redirected, opaque, or as HTML, or fails while navigator.onLine is true, skip the cached shell once and do a full window.location.replace(BASE + "/") so the proxy can re-authenticate.

Environment
ihasmail 2026.10.5+g20c32ed (same sw.js on main 2649c00), Docker behind cloudflared and Cloudflare Access (Authentik OIDC), Stalwart 0.16.23, iPhone Home Screen web app. Not Stalwart-dependent: Stalwart is never contacted.

Workaround
Delete the Home Screen app, sign in through the proxy in Safari, and add it again. It breaks again at the next proxy session expiry.

**Summary** When ihasmail is installed as a Home Screen app and sits behind an authenticating reverse proxy (Cloudflare Access), the app can't be signed in to once the proxy's session cookie expires. Every sign-in attempt shows "Network error. Please check your connection." The only way back in is to delete the Home Screen app and install it again. The same account works normally in a regular browser tab. **Steps to reproduce** 1. Put ihasmail behind Cloudflare Access (any proxy that answers an unauthenticated request with a 302 to its own login page on another origin). 2. On an iPhone, open ihasmail in Safari, pass the Access login, and Add to Home Screen with "Open as Web App" on. The installed URL is https://<host>/mail, from the manifest's start_url "mail". 3. Let the Access session expire (ours is 168 h), or clear the Access cookie. 4. Open the Home Screen app and try to sign in. **Expected** The app notices it is no longer authenticated at the proxy and does a real navigation, so the proxy can show its login page. **Actual** - The login page renders from the service worker cache. The logo image is broken, because its request is redirected to the proxy too. - Signing in shows "Network error. Please check your connection." on every attempt. - The request never reaches ihasmail's server or Stalwart: neither logs anything for it. - This continues until the Home Screen app is removed and installed again. **Cause (from reading web/public/sw.js)** For navigations matching APP_ROUTE (mail|search|contacts|calendar|files|settings|admin|login), the fetch handler returns the cached shell whenever one exists and only refreshes it in the background. An installed app always launches into "mail", so it never makes a navigation that reaches the network. The proxy's 302 only ever hits /api/* fetches, which are redirected cross-origin and fail. The background refresh also gets the redirect (res.ok is false), so the shell is never replaced. **Suggested fix** When an /api/* request or the background navigation refresh comes back redirected, opaque, or as HTML, or fails while navigator.onLine is true, skip the cached shell once and do a full window.location.replace(BASE + "/") so the proxy can re-authenticate. **Environment** ihasmail 2026.10.5+g20c32ed (same sw.js on main 2649c00), Docker behind cloudflared and Cloudflare Access (Authentik OIDC), Stalwart 0.16.23, iPhone Home Screen web app. Not Stalwart-dependent: Stalwart is never contacted. **Workaround** Delete the Home Screen app, sign in through the proxy in Safari, and add it again. It breaks again at the next proxy session expiry.
jcoffey-dev added the bug
priority
p2
 labels 2026-10-09 22:22:48 +00:00
jcoffey-dev self-assigned this 2026-10-09 22:22:48 +00:00
jcoffey-dev added the due date 2026-10-16 2026-10-09 22:28:44 +00:00
jcoffey-dev commented 2026-10-09 23:00:26 +00:00
Owner
Copy link
Copy source

This one may be more of a fumble along for me to fix, I do not have any Apple products for testing right now. Will take a stab at it though.

This one may be more of a fumble along for me to fix, I do not have any Apple products for testing right now. Will take a stab at it though.
jcoffey-dev commented 2026-10-10 01:41:37 +00:00
Owner
Copy link
Copy source

Thanks for the detailed report, @dwofford. Fixed in #52: when the app hits the proxy's redirect it now goes back through the front door so Access can show its login, instead of sitting on the cached sign-in page. It'll be in Monday's release. If you get a chance to try it on your phone after that, I'd like to hear how it goes.

Thanks for the detailed report, @dwofford. Fixed in #52: when the app hits the proxy's redirect it now goes back through the front door so Access can show its login, instead of sitting on the cached sign-in page. It'll be in Monday's release. If you get a chance to try it on your phone after that, I'd like to hear how it goes.
jcoffey-dev commented 2026-10-10 01:47:09 +00:00
Owner
Copy link
Copy source

This is live on ihasmail.com now. The self-hosted image picks it up in Monday's release.

This is live on ihasmail.com now. The self-hosted image picks it up in Monday's release.
Sign in to join this conversation.
No Branch/Tag Specified
Labels
Clear labels
bug
Something isn't working
 dependencies
Dependency updates
 documentation
Docs, README or site copy
 duplicate
Already tracked elsewhere
 enhancement
New feature or improvement
 good first issue
Good for newcomers
 help wanted
Contributions welcome
 invalid
Not a valid issue
 needs info
Waiting on the reporter for details
 question
Needs an answer, not a code change
 security
Security issue or hardening
 translation
New language or translation fixes
 wontfix
Will not be worked on
priority
p1
High priority
priority
p2
Medium priority
priority
p3
Low priority
No labels bug
priority
p2
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
jcoffey-dev (John Coffey)
No Assignees jcoffey-dev
2 Participants
Notifications
Due Date
2026-10-16
Dependencies

No dependencies set.

Reference: coffey-labs/ihasmail#47