Repository navigation
Conversation
|
Thanks for your contribution! This PR doesn't have a linked issue. All PRs must reference an existing issue. Please:
See CONTRIBUTING.md for details. |
|
The following comment was made by an LLM, it may be inaccurate: |
|
Another whole-site proxy case from #57649: Caddy + Authelia in front of OpenCode 2.1.1. After the tab loses content without navigating to sign-in, signing in to Authelia separately restores the content. Unauthenticated curl probes against the protected origin returned:
I tested
This tests the wrapper, not the full app or generated service worker. Another failing request could still recover this deployment, but the Would an explicit |
|
Automated PR Cleanup Thank you for contributing to opencode. Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions. This PR was closed because it matched the following cleanup criteria:
PRs created within the last month are not affected by this cleanup. If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate. Thanks again for taking the time to contribute. |
Issue for this PR
Part of #50481: expired-session recovery behind whole-site sign-in proxies. Callback-path exclusions are separate.
Type of change
What does this PR do?
Behind a sign-in proxy that gates every path, like Dev Tunnels, the app stays on "Loading" after the proxy session expires. The service worker serves navigations from cache, so the proxy never gets a chance to redirect to sign-in.
When a same-origin request fails (other than an abort), the web
fetchchecks/api/infowithout following redirects. If that is a redirect, it reloads the current page with?reauth=1, which the service worker lets through to the network. After that it won't reload again until a same-origin request succeeds, so a proxy that keeps rejecting API requests after sign-in can't cause a reload loop.Desktop is unaffected. Proxies that only gate
/apiaren't handled here.How did you verify your code works?
e2e/service-worker/sign-in-proxy.spec.tswith a fake proxy modelled on Dev Tunnels, and a?reauthcase incache.spec.tsbun run test:service-workerandbun run checkScreenshots / recordings
Before
before.webm
After
after.webm
Checklist