Hi,
Using Caddy as a reverse proxy with the following config
ha.redacted.com {
proxy / 192.168.67.11:8123 {
transparent
websocket
}
gzip
basicauth / X X
log /dev/stdout
tls [email protected]
}
Going to this URL from remote i just get a Connecting screen, and then a login. (i do not use HA password, only basic auth):
From the network inspector i can see i get several 401 Unauthorized from /api/websocket.
It might help if you deleted all content (cookies and site data) under your HA URL within your browser.
I am currently using Apache as reverse proxy with basic authentication, and need to perform the above every couple of days or so. The symptoms are the same - long loading time, ending up with the login screen, and plenty of unauthorised requests.
I can get it working in Firefox actually. Chrome does only work in Incognito. On my mobile where i need it the most it doesnt work in either Safari or Chrome (iOS)
This surely has to be a bug?
Are you running latest version with the websocket fix? I admittedly don’t use basic authentication and instead use HA password but there was a recent fix for websockets so worth a check.
Yeah im running the 0.10.6 with the defer websocket close fix. Works great without basic auth for sure 
Out of interest why use basic authentication instead of api password?
In case of a serious vuln i dont want to expose HA directly. May be paranoid but i still think its needed.
Alright, so when it works in Incognito mode then you are effectively starting a clean session without any previously stored data.
I am not sure if it’s a bug. It certainly looks like an incompatibility between HA and basic authentication through a reverse proxy. But HA’s solution for authenticated access is the API password.
There was a discussion recently about a more advanced authentication and authorisation model. Not sure if that has gone anywhere, but that may be the right way to go as a long-term goal.
Hass does a truckload of caching which is great for performance but not-so-great if the client device is roaming between different authentication realms. I had to back off some of my more aggressive authentication profiles on my reverse proxy (Netscaler) due to this. In my situation, devices on my local network would not require special authentication while devices coming in from the internet would be kicked over to an authentication portal for user/pass/OTP. This worked great until a device that was used internally then tried to access Hass coming from the internet or vice-versa. Similar to you, opening a new session in incognito mode resolved the issue but didn’t seem practical. From what I can piece together, the majority of the actual UI is cached at the client with state moving back and forth via websockets, which unfortunately doesn’t trigger the authentication process on my Netscalers (and probably your reverse proxy too) so everything just times out.
Found these related issues:
I may try some of those dirtyhax or just setup VPN.
Luma, I’m trying to set up HA behind my netscaler and I’m running into an issue. I can log in, but then I’m getting “Unable to connect to Home Assistant” with a retry link. So far I’ve tried enabling HTTP/2 in my HTTP Profile, adding two rewrite policies to add “Upgrade” and “Connection” HTTP headers, as well as adding the x-forwarded-for header. I’ve modified my configuration.yaml to trust the netscaler’s IP and to use the x-forwarded-for header. Any ideas?
Anyhing new regarding this topic? I’ve run into the same problem…
