Remove the need for setting CORS headers

[lidel]

Issue extracted from #722 (review)

Summary

Right now IPFS Desktop is automatically adding CORS headers to $IPFS_PATH/config:

https://github.com/ipfs-shipyard/ipfs-desktop/blob/8f912ce816e2cd2e1c634fe8cdab54e2eb37cedf/src/utils/daemon.js#L59-L64

Without the above, Web UI won't load.
We should look into ways we can make it work without the need for touching API.HTTPHeaders, eg. see how IPFS Companion deals with the same problem.

Background Discussion

@olizilla asked:

I wonder how this could be abused. A fake scheme is a neat trick, but I don't know enough to reason about how it could be exploited if we added it to the list of allowed origins. I guess a site would have have been loaded from the webui:// scheme. What happens if a web-ext is allowed to registered itself as handling that scheme?

What are our other options here?
My main concern is about updating the users config for an external daemon. @lidel what do you think?

@lidel suggested:

Actually.. we have a lot of control over the browser (request headers etc) in IPFS Desktop, just like we do in IPFS Companion. This means we should not need to set the CORS header in daemon.

Electron (Chromium engine) is adding Origin: null to fetch requests made from webui:// and internal contexts to HTTP API which acts as a sort-of-false-positive trigger for CORS validation, resulting in 403 Forbidden:

Note: IPFS Companion works around this by removing Origin header from requests sent to the API from js-ipfs-http-client running in its background page:

• https://github.com/ipfs-shipyard/ipfs-companion/blob/v2.6.2/add-on/src/lib/ipfs-request.js#L107-L144

This makes those requests "no longer CORS" in view of go-ipfs.
I believe if we add similar fix to IPFS Desktop the need for origins.push(...) will disappear.

[olizilla]

I think the issue here is that we're using the js-ipfs-http-client code from the webui to make the http requests, rather than passing in a proxy for an ipfs instances as companion does

https://github.com/ipfs-shipyard/ipfs-desktop/blob/f06cc5919682ba80009bceb07c39a210dfd63e66/src/hooks/webui/preload.js#L34

This technique is nice and simple, but we may have to switch it out for an injected proxy object if we want to avoid CORS dancing.

[hacdias]

@olizilla perhaps we could make a proxy to communicate directly with the API on the main process and take advantage of the fact that IPFS Redux Bundle can use an window.ipfs object. Although, right now, it is disabled in Web UI.

Edit: I can find some issues of making a proxy between the main and renderer processes: there are some values returned by the API that aren't serializable such as Big.js numbers, file uploads, etc...

[lidel]

AFAIK Electron is using postMessage-like interface for communication between processes.
Take a look at ipfs-postmsg-proxy, it solves serialization issues in ipfs-companion around window.ipfs in page context talking to API running in separate webextension process.

[hacdias]

Although our solution might not be considered perfect, we don't need to set the CORS headers anymore. I'm closing this!