The new workbox service worker implementation uses UrlHelper.absolute. Since this is a compiled asset, it stores the full URL, containing the full hostname of the primary host in a multisite environment.
Yes, importScripts and modulePathPrefix, on lines 3 and 6 of that ERB file.
But you are not understanding me completely. The issues are happening where there is no CDN on a multisite cluster.
Both UrlHelper.absolute and UrlHelper.local_cdn_url can handle situations with and without CDN.
absolute:
no cdn: https://primarysite.ofmultisitecluster.com/javascripts/workbox/workbox-sw.js **bad - remote origin for all sites but the primary, exposing primary cluster hostname **
cdn: //cdnurl/javascripts/workbox/workbox-sw.js
local_cdn_url:
no cdn:/javascripts/workbox/workbox-sw.jsgood - relative url
cdn: //cdnurl/javascripts/workbox/workbox-sw.js
The problem is that those lines (3 ad 6) are not about the service worker file.
The service worker comes from the base domain (as it can’t be served from a CDN) but this service worker lazily imports scripts at runtime (in this case the workbox library files) and those can be served from a CDN.
So the problem is that your multisite cluster doesn’t have a CDN configured so that is what exposes this bug, which is masked when DISCOURSE_CDN is set. Just wanted to know why it doesn’t affect us.
Looking elsewhere, this route gained some special sauce because browsers love to hammer it HARD, and we aren’t allowed to put it on a CDN and make it someone else problem. While doing this, we had a bug involving a multisite leak, which was fixed by @sam one year ago:
No, the problem is that it does that when precompiling assets, and that becomes an issue on multisite.
So the solution is to not include the hostname in the assets ever (except for an asset CDN if it happens to be set since that is always shared between the multisite hosts anyway)
But… just to make sure… I’m not sure how you guys are handling assets on a CDN in combination with a subfolder, but if you use Discourse.asset_host, do you still prefix all paths on the asset host with the subfolder path as well? Because that is what the code is doing now.
If that is what you’re doing then you can completely ignore this paragraph
This whole subfolder + CDN thing caused use plenty of problems indeed. @featheredtoast did some work streamlining this and we spent a lot of time ensuring all our asset serving code can properly work on those weird combinations of buckets, subfolders, etc.
I think we are safe , but if needed we can reopen this.