Hi,
Not sure whether this issue is in the right category, please feel free to move it to the more appropriate category.
I’m running HA inside my Kubernetes environment. The installation has been done with the Helm Chart and was easy and straight forwared.
In front of HA I use Trafik 2.1 as the ingress controller (reverse proxy) within my Kubernetes cluster. Until here everythin is working smooth.
To enhance the protection level of my external services as well as to enable SSO capability I use the forward-auth feature of my ingress. The first request to HA works fine as long as the service worker is not in place or the current auth session is still valid. But after a while, when the auth session has expired my reverse proxy redirects me correctly to my auth provider (e.g. Google).
But then, after login, the auth provider redirects to HA with all the auth headers and body. But instead this request can be process by my reverse proxy , the service worker of the browser intercepts this request and with it the possibility to get the cookies set right. The only solutions right now are to login first in another service to get a valid auth-session cookie or to empty everything for that domain (cookie, service worker, cache, localstorage, …) to force the initial flow described before.
I try to show the two flows in detail for a better understanding:
Good Flow
- Browser sends request to
https://ha.domain.com - Request is sent to the reverse-proxy which is listening for incoming requests on ha.domain.com
- Reverse-Proxy checks the auth-session (non available) and triggers the forward-auth workflow
- Reverse-Proxy sends a 301/302 to the browser with location
https://accounts.google.com/... - I do my regular Google login
- Google redirects after successful login to
https://ha.domain.com?tokens=xxx&claims=yyy(not the real query param names/values but to show the case) - Reverse-Proxy intercepts this request to evaluate the auth-arguments and if valid sets the cookie
- Reverse-Proxy forwards the request to the real HA service on
https://ha.domain.com - HA installs the service worker to listen and catch everything the browser sends to
https://ha.domain.com - I can use HA as expected, because every request contains the valid auth-session cookie, either the request origins from the service-worker or browser.
Bad Flow
- I close the browser or wait for some minutes / hours (depending on the expiration value)
- I open the browser and enter
https://ha.domain.com - Service-worker is intercepting the request
- Not pretty sure what’s really happening inside the service-worker
- My browser gets redirected to
https://accounts.google.com/... - I do my regular Google login
- Google is redirecting to
https://ha.domain.com?tokens=xxx&claims=yyy - Service worker is intercepting the request and the cookie cannot be set by the reverse-proxy
- Not pretty sure what the service-worker is doing
- The browser is displaying Error 503 without any further information and no cookies are set in the browser
What really happens is inclear at the moment, haven’t debugged the service-worker yet. But all the following request which are sent to the reverse-proxy are invalid. I guess because the necessary cookie is missing.
I also tried another forward-auth service (currently external-auth-server), but also tried traefik-forward-auth and oauth2_proxy. With the others I get an infinite redirect flow which causes the browser to stop redirecting after a while (crash prevention).
All my other services aren’t affected by that. Just HA with it’s service-worker.
Possible Solutions
- Can the service-worker be disabled?
- Can the service-worker be configured to only intercept certain paths (the ones which are really used)?
- Can the service-worker be configured to no intercept a certain path (excluding the auth-path)
- Can HA be operated on a sub-path e.g.
https://ha.domain.com/ha? - Any other configurations which solved this issue
Thank you all for feedback and suggestions.
Cheers Danny