Use Web UI version from IPFS Node #736
Assignees
Labels
area/webui
Issues related to interactions with Web UI
kind/bug
A bug in existing code (including security flaws)
P0
Critical: Tackled by core team ASAP
status/in-progress
In progress
topic/security
Work related to security
Comments
olizilla
added a commit
to ipfs/kubo
that referenced
this issue
Jul 18, 2019
We want to allow user to try out the latest versions of the webui before they are officially released with go-ipfs. Right now ipfs-companion includes a workaround to strip the origin header from blessed, new versions of webui, to allow this, but it causes other issues, so we'd like to replace that hack, with this feature. see: ipfs/ipfs-companion#736
|
PR to go-ipfs to allow /ipns/webui.ipfs.io is go! ipfs/kubo#6530 |
lidel
added a commit
that referenced
this issue
Jul 18, 2019
This changes the way "Open Web UI" menu option works. Before: we kept CID of latest version and opened it from gateway port + executed a lot of magic to ensure it can talk to api port in secure way. After: we removed all the magic and just open the version provided on api port. Details: #736
lidel
added a commit
that referenced
this issue
Jul 18, 2019
Adds an opt-in toggle (disabled by default) to Preferences
which changes the URL of Web UI opened via Browser Action menu
from {API}/webui to {API}/ipns/webui.ipfs.io
This enables user to load the latest webui via DNSLink.
Note that go-ipfs and js-ipfs do not whitelist /ipns/webui.ipfs.io on
the API port yet, so there is a fallback in place that detects HTTP 404
and redirects user to {API}/webui.
Closes: #736
lidel
added a commit
to ipfs/js-ipfs
that referenced
this issue
Jul 19, 2019
We want to allow user to try out the latest versions of the webui before they are officially released with js-ipfs. Context: ipfs/ipfs-companion#736 go-ipfs counterpart: ipfs/kubo#6530 License: MIT Signed-off-by: Marcin Rataj <lidel@lidel.org>
|
|
Should IPFS Desktop do the same too? |
|
Actually we can't. Many IPFS Desktop settings depend on the Web UI settings page. So, if the Web UI is only available when the daemon is on, then we can't access the settings. Unless we move Desktop specific options to the menubar itself as we're planning initially. It's basically a bunch of checkboxes. |
10 tasks
20 tasks
lidel
added
kind/bug
|
Update:
|
lidel
added a commit
that referenced
this issue
Apr 3, 2020
This restores the proper way of opening webui in version provided by IPFS node. Context: Before subdomain gateway support was added, we loaded webui from gateway port. Why? API port has a hardcoded list of whitelisted webui versions and it is not possible to load non-whitelisted CID when new webui was released. To enable API access from webui loaded via Gateway port, the Companion extension removed Origin header for requests coming from its background page. This let us avoid the need for manual CORS setup, but was seen in the diff, was pretty complex process. Webui is stable now, so to decrease maintenance burden we move away from that complexity and just load version whitelisted on API port. What if someone wants to run newest webui? They can now load it from webui.ipfs.io.ipns.localhost:8080 (whitelist API access from that specific Origin by appending it to API.HTTPHeaders.Access-Control-Allow-Origin in go-ipfs config) Closes #736
lidel
added a commit
that referenced
this issue
Apr 5, 2020
This restores the proper way of opening webui in version provided by IPFS node. Context: Before subdomain gateway support was added, we loaded webui from gateway port. Why? API port has a hardcoded list of whitelisted webui versions and it is not possible to load non-whitelisted CID when new webui was released. To enable API access from webui loaded via Gateway port, the Companion extension removed Origin header for requests coming from its background page. This let us avoid the need for manual CORS setup, but was seen in the diff, was pretty complex process. Webui is stable now, so to decrease maintenance burden we move away from that complexity and just load version whitelisted on API port. What if someone wants to run newest webui? They can now load it from webui.ipfs.io.ipns.localhost:8080 (whitelist API access from that specific Origin by appending it to API.HTTPHeaders.Access-Control-Allow-Origin in go-ipfs config) Closes #736
lidel
added a commit
that referenced
this issue
Apr 5, 2020
This restores the proper way of opening webui in version provided by IPFS node. Context: Before subdomain gateway support was added, we loaded webui from gateway port. Why? API port has a hardcoded list of whitelisted webui versions and it is not possible to load non-whitelisted CID when new webui was released. To enable API access from webui loaded via Gateway port, the Companion extension removed Origin header for requests coming from its background page. This let us avoid the need for manual CORS setup, but was seen in the diff, was pretty complex process. Webui is stable now, so to decrease maintenance burden we move away from that complexity and just load version whitelisted on API port. What if someone wants to run newest webui? They can now load it from webui.ipfs.io.ipns.localhost:8080 (whitelist API access from that specific Origin by appending it to API.HTTPHeaders.Access-Control-Allow-Origin in go-ipfs config) Closes #736
lidel
added a commit
that referenced
this issue
Apr 5, 2020
This restores the proper way of opening webui in version provided by IPFS node. Context: Before subdomain gateway support was added, we loaded webui from gateway port. Why? API port has a hardcoded list of whitelisted webui versions and it is not possible to load non-whitelisted CID when new webui was released. To enable API access from webui loaded via Gateway port, the Companion extension removed Origin header for requests coming from its background page. This let us avoid the need for manual CORS setup, but was seen in the diff, was pretty complex process. Webui is stable now, so to decrease maintenance burden we move away from that complexity and just load version whitelisted on API port. What if someone wants to run newest webui? They can now load it from webui.ipfs.io.ipns.localhost:8080 (whitelist API access from that specific Origin by appending it to API.HTTPHeaders.Access-Control-Allow-Origin in go-ipfs config) Closes #736
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Context
Every IPFS Node provides
:5001/webuiendpoint on the API port. It redirects to the latest 'blessed' CID that can be loaded from:5001/ipfs/{cid}. For security reasons only hardcoded CIDs can be loaded from API port.Right now IPFS Companion ships with hardcoded version of Web UI, and that version can be bigger than the one at
:5001/webui.Companion can't load it from API port as it is not on the whitelist, so it loads it from the Gateway instead. That comes at a price of having two separate Origins and falling under CORS limitations. We don't want people to add CORS headers, as it would allow allow any website loaded from Gateway port to execute arbitrary requests on API port. Instead, we remove CORS check on webui path by supressing
Originheader in requests made from:8080/ipfs/{blessed_webui_cid}(Gateway) to:5001(API).That way we keep CORS check from anything else on Gateway port.
Why we did this? It made it possible for us to iterate and ship new Web UI without waiting for new go-ipfs release (which took multiple months at the time).
Proposed change
We are now in maintenance mode where regular go-ipfs releases are expected and webui itself is much more stable now.
It is time to:
/webuiprovided by go-ipfs (or js-ipfs) as the new default in Companion:5001/ipns/webui.ipfs.io(requires ipns path to be added to API port whitelist in GO and JS)cc @olizilla (ipfs/ipfs-webui#1038 (comment))
The text was updated successfully, but these errors were encountered: