Repository navigation
web: reverse-proxy SSO expiry blanks the UI instead of redirecting to login #57649
Description
Description
Since moving to V2, an open web tab sometimes stops showing content without navigating to our SSO login page. Signing in to Authelia separately in the same browser restores the content in OpenCode.
The deployment is browser -> Caddy + Authelia forward-auth -> opencode serve. Authelia protects the whole site, and Caddy supplies the backend's Basic authentication header.
Unauthenticated curl probes against the protected origin confirm:
GET /api/info,Accept: application/json:401with aLocationheader pointing to Authelia's login page.GET /,Accept: text/html:302to that login page.
These probes suggest an expired proxy session, but we haven't captured the failing browser requests or verified the exact SSE reconnect sequence. The V1 comparison is based on deployment experience, not a side-by-side test. A plain page reload is not a verified workaround; the service worker may serve the cached app shell.
Expected: make the sign-in path available when proxy authentication expires instead of leaving the tab without content.
This overlaps with #50481; #52223 is the existing recovery PR.
Plugins
Not isolated with plugins disabled.
OpenCode version
2.1.1
Steps to reproduce
- Serve the web UI behind Caddy + Authelia forward-auth and sign in.
- Leave the tab open until the proxy session expires.
- The tab stops showing content without navigating to sign-in.
- Sign in to Authelia separately in the same browser. OpenCode content returns.
Operating System
Server: Linux x86_64, kernel 7.0.0-30-generic. Browser/OS details not collected.
Terminal
N/A, web UI.
Activity
0xf3cd commentedon Oct 21, 2026
We run into this with
opencode servebehind Caddy + Authelia, so we have a live reproduction environment. Happy to take it.Plan: when API/SSE requests start failing with 401 (or after a 302 lands on HTML instead of the expected payload), do a guarded one-shot page reload so the proxy's own redirect can take over. Will follow up with a PR referencing this issue.
opencode-agent commentedon Oct 21, 2026
Thanks for the detailed write-up and the curl probes. I think this is a duplicate of #50481. It describes the same failure behind oauth2-proxy/Keycloak: once the proxy's SSO session expires, background
/apiand/api/eventrequests get a 302 to the IdP (followed silently) or a 401. The client keeps retrying and never sends you to the login page.Possible duplicates and related issues, ordered from most to least likely:
?reauth=1so the proxy can redirect. By its own description it doesn't yet cover proxies that only gate/api.Your notes on the
Accept: application/json→401+Locationcase would be useful on #50481 or #52223, since that PR only checks for redirects.The bot will close this issue as a duplicate in 1 day unless you reply explaining how your problem is different.
0xf3cd commentedon Oct 21, 2026
Agreed, the expired-proxy-session symptom overlaps with #50481. I'll add the Authelia
401 + Locationevidence to #52223 rather than open a competing implementation.One correction to my initial report: curl confirmed the proxy responses, but I haven't captured a browser trace proving the SSE sequence. A plain reload is also not a verified workaround, since the service worker may serve the cached app shell. Signing in to Authelia separately is the workaround we've observed.
opencode-agent commentedon Oct 22, 2026
We haven't heard back in the past day, so I'm closing this as a duplicate of #50481. That issue covers the same problem: after the reverse proxy's SSO session expires, background API and SSE requests get a 401 or a silently followed redirect, and the web client never sends you back to the login page. Please follow #50481 and the open PR #52223 for updates. Your note on the
Accept: application/json→401+Locationcase would be useful there. If your problem turns out to be different, reply here and we can reopen it. Thanks for the detailed report!