2026-06-15: force Uptime Kuma websocket transport for SSO

This commit is contained in:
kenpat 2026-06-15 09:49:40 -05:00
parent 42734af0f0
commit a6662425b7

View file

@ -501,6 +501,23 @@ Verified current live state on monk before making changes:
still returns `button` 6/6. If a browser still has a pre-fix bad token in
localStorage, clear site data or click the Authentik button again to mint a
fresh token.
- User retested and still saw the socket reconnect banner. Follow-up finding:
public Uptime Kuma frontend was using Socket.IO's default long-polling-first
transport. In the active-active Cloudflare Tunnel setup, polling requests can
bounce between monk and kscloud1 before a socket session is established,
causing reconnect loops before Kuma even logs `Login by token`.
- Fix applied 2026-06-15 on BOTH monk and kscloud1: copied the built frontend
bundle `index-BBxTfFCS.js` into the overlay and patched the minified socket
call from `Ze=Nc(n)` to `Ze=Nc(n,{transports:["websocket"]})`. Regenerated
`.gz` and `.br` variants and mounted all three over
`/app/dist/assets/index-BBxTfFCS.js*` in both compose files. Restarted both
Uptime Kuma containers.
- Verification after websocket-only patch:
- monk local asset contains `transports:["websocket"]`
- kscloud1 local asset contains `transports:["websocket"]`
- public repeated asset check over `https://status.kitestacks.com/assets/index-BBxTfFCS.js`
found `transports:["websocket"]` 6/6, confirming both tunnel backends serve
the patched client bundle.
Important security hygiene: local git remote for `~/claude-memory` contains an
HTTP token in the URL; do not print it in summaries. Prefer redacted URLs in