Improve Kubo - Companion Docs
whizzzkid opened this issue · 2 comments
Checklist
- I am reporting a documentation issue in this repo, not https://docs.ipfs.tech.
- I have searched on the issue tracker for my issue.
Location
No response
Description
A few interesting points came up: https://www.reddit.com/r/ipfs/comments/145inx4/just_tried_ipfs_a_few_thoughts/
I believe we should cover possible scenarios and setup guides to make pairing companion with kubo easy.
- cover different setup types.
- cover a few possible scenarios.
- issues around CORS issue.
relates to:
I'm moving this back to ipfs-companion, as it does not seem to be actionable from the perspective of Kubo repository
(imo Kubo repo should not have documentation related to companion, just like we don't have anything about ipfs-desktop, ipfsd-ctl, ipfs-cluster or any other project that uses Kubo – such docs belong to repo of respective project)
As for configuring Companion to work with non-localhost node, my suggestion is to be conservative:
- Companion is a GUI application that should "just work"
- We should NOT ask people to set CORS headers for ipfs-companion to function correctly
- Setting CORS to safelist RPC port access is hard for a reason: this is a power user feature that comes with security risk, VERY easy to give admin access to RPC port to every website on the internet.
- Kubo has no access control mechanism beyond CORS atm, and until some way of guarding it like ipfs/kubo#1532 is resolved, using RPC outside a controlled environment of localhost is considered a power user feature, aka "use at your own risk".
- Setting CORS to safelist RPC port access is hard for a reason: this is a power user feature that comes with security risk, VERY easy to give admin access to RPC port to every website on the internet.
👉 By looking at the reddit post, it sounds like what IPFS Companion could do, is to have more meaningful error message when non-localhost RPC or Gateway is used. It should explain security (CORS giving admin access to RPC API) and/or interop ramifications (non-localhost cleartext http:// gateway causing mixed-content errors IF subresources are redirected).
[..] shows ipfs not running even though I am using a kubo rpc install on the local network. #
This sounds like a bug?
- in Chromium, this should be handled by either safe listing extension ID (already done in ipfs/kubo#8690),
- in Firefox the code for adjusting the Origin HTTP header takes care of it, already in ipfs-companion/../ipfs-request.js#L227-L260
How about add virtual network for API isolation. like through zerotier-like intranet for using api remotely, while local computer at same network, then put the other ports public if one-self wanted, which like gateway, swarm etc,.?
maybe this way should link the cluster together in more safe way?