Updating global config on root domain doesn't affect subdomain urls once SW is installed

[2color]

Summary

Our current implementation of global configuration has a bug where updating the config on the root origin will not affect the configuration of a subdomain once the SW is installed.

This means that it's only possible to customise the configuration for a subdomain before the service worker is installed.

Reproduction

(Make sure you haven't loaded this CID prior. If you have, clear your browser storage for the origin)

1. Load a subdomain url: https://bafybeiedlhslivmuj2iinnpd24ulx3fyd7cjenddbkeoxbf3snjiz3npda.ipfs.inbrowser.link
2. Look at the configuration (should be default)
3. Click "Load content"
4. Go to inbrowser.link and change the gateway configuration
5. Load the same subdomain url https://bafybeiedlhslivmuj2iinnpd24ulx3fyd7cjenddbkeoxbf3snjiz3npda.ipfs.inbrowser.link and you will see that the config changes are not affecting the service worker

Cause

The main cause for this seem to be the way that we pass config across subdomain origins, namely the postMessage call from the config iframe with the root url that is initially loaded on the subdomain.

After the SW is installed, there's no way for config updates to be passed to the subdomain origin.

Potential solution

We may want to introduce a special path for loading the config page, that can be detected by the SW and handled as a special case. For example /sw-config would render the config page even when loaded on the subdomain origin with the SW installed. This isn't optimal, given that there's no way for us to communicate it to users. Additionally there's a low risk of path collision if the CID also has a path /sw-config.

Besides this, I can't think of any other way to allow changing configuration once the SW is installed.

Side note

The main reason for the message passing is to enable global configuration on the root domain that when updated, impacts every CID loaded via subdomains. However, this approach has a several disadvantages:

• inherent complexity making the code harder to reason about
• iframes are blocked by brave

[2color]

@lidel @SgtPooki Any thoughts on this?

[lidel]

For the problem at hand, mix of cookie + "magic path" might work and make sense.
There is standard for doing them: https://en.wikipedia.org/wiki/Well-known_URI

/.well-known/ipfs/sw-config-{uuid}

(but we should get correctness and caching first, global config is nice-to-have)

[SgtPooki]

another potential solution:

• config flag via cookie that triggers subdomains to reload iframe
• fetch to root service worker for config? (will SW on root actually get the fetch request from the subdomain...?)
• timeout or getting service worker to unregister itself (which will cause config page to reload with iframe message passing solution)

[SgtPooki]

@2color i believe this is partially resolved by #96

[SgtPooki]

FYI we can't access cookies from firefox: https://caniuse.com/?search=cookie

so we should probably do some type of fetch from root domain at #/sw-config-json

[SgtPooki]

I think maybe we can mark this as resolved for now because you can currently access config for a subdomain at https://specs-ipfs-tech.ipns.inbrowser.dev/#/ipfs-sw-config, and we also implode service-workers after 24 hours.

[SgtPooki]

So, to clarify how this config feature works for users:

1. global config is "extended" or inherited from when a new subdomain is loaded.
2. that config can be customized before attempting to load the site
3. that config can be customized later (even from subdomain urls) by accessing /#/ipfs-sw-config