Ability to exclude non-HASS URLs from Service Worker FallbackWhitelist

Feature Requests
1

I’ve set up home assistant behind nginx as a reverse proxy for external connections. I’ve been trying to add some additional services behind the same proxy, but under different sub-urls (eg, hass is at https://my-server/ - but i also want to be able to proxy https://my-server/other-service/ to a different app.

I’ve had lots of trouble getting it to work, and couldn’t get my head around it - but finally worked out that it’s the home assistant service worker intercepting the requests. I found an issue on github where @happyleaves had the same problem : https://github.com/home-assistant/home-assistant/issues/3010 (might have saved me a lot of head scratching if I’d found this earlier!)

Having spent so long on this, i didn’t want to give up at this point (and I didn’t want to just disable the service worker, as I presume it’s improving performance) - so I started taking a look at the service_worker.js file, which I think is built using https://github.com/GoogleChrome/sw-precache

I think the problem is due to the fact that this is configured to use a navigateFallback URL if the request isn’t in cache and matches a regex in navigateFallbackWhitelist. The regex is set up to match anything which isn’t in a list of specified values (static|api|local|service_worker.js|manifest.json). As my URLs aren’t in that list, the navigateFallback URL is triggered.

I’ve now added my URL to the regex, recompressed the service_worker.js file, and reloaded the service worker - and my URL is now working correctly and not being intercepted by the service worker.

Now that I’ve figured all this out, it’s not too difficult to modify the file again when I update home assistant - but my feature request is :

  • Would it be possible to add a nice configuration parameter somewhere to add custom entries to the regex of URLs for the service worker to ignore? It would be great if I could just configure this once, and then have the same behaviour continue when I upgrade Home Assistant.
2

I’d also really like to see this resolved. It sounds like you made more progress than I did. The Github issue was closed as “not a Home Assistant problem”, but arguably I think it is …

3

I have a similar problem trying to show a page using HA domain and I’ve been pulling my hair trying to find out why it doesn’t work. I agree that having it as a configurable option would be much nicer than disabling the service worker (how does a newbie quickly disable the service worker anyway?)

4

Hi. I have resolved the problem from nginx.

There are two alternatives, set your subapplication in /auth/ path, for example

	location /auth/portainer/ {
		include /config/nginx/proxy.conf;
		proxy_pass http://192.168.188.2:9000/;
	}

because auth path is not cached.

The second possibility, you can edit service_worker.js at runtime.

	location /ha-portainer/ {
		include /config/nginx/proxy.conf;
		proxy_pass http://192.168.188.2:9000/;
	}

	location /service_worker.js {
		include /config/nginx/proxy.conf;
		proxy_set_header Accept-Encoding ""; #disable gzip compression
		proxy_pass http://HA_IP:8123;
		sub_filter  'api|'  'ha-portainer|api|';
		sub_filter_once off;
		sub_filter_types text/javascript application/javascript;
	}

	location / {
		include /config/nginx/proxy.conf;
		proxy_pass http://HA_IP:8123;
	}

Bye!!!

5

I also encountered this problem recently, another option would be to use the local path, anything served under this does not use Home Assistant’s auth or managed as it is designed to be public/open access.

You could use a reverse proxy path with /local/myapp to then serve whatever required under your Home Assistant domain. You would want to ensure you enable some form of authetication or ACL however under the reverse proxy.