This one slipped between our fingers:
Problem
Gateway.APICommands is ignored, go-ipfs 0.8.0 uses hardcoded list of commands:
(cmd/ipfs/daemon.go#L669 → core/commands/root.go#L166-L198
Why this matters
This is blocking our users from running their own delegated routing service without additional nginx magic as noted in libp2p/js-libp2p#371:
We were trying to use Gateway.APICommands in context of ipfs/js-ipfs#2155 (comment) but it did not work, and @mburns had to redirect to API port at Nginx level.
How to fix it?
Unsure, needs more analysis.
I see two ways to resolve this:
(A) keep implicit safelist, extend it with values added to APICommands
A backward-compatible way to fix this is to keep current implicit defaults from core/commands/root.go#L166-L198 when Gateway.APICommands is empty, but if we do this, how can gateway operator disable /api/v0 entierely if they wish to do so?
(B) no /api/v0 by default, only explicit opt-in safelist via APICommands
Perhaps we should make a breaking change and disable /api/v0 by default on Gateways, unless user explicitly safelisted commands via Gateway.APICommands ? This feels like a way safer default. We have some features that depend on /api/v0 and /ipfs/ endpoint does not provide replacement for them yet, so better to avoid this (eg. we don't want user to safelist dht/put but break refs as a side effect)
It always felt to me like something that should be opt-in, but would appreciate feedback if someone thinks otherwise.
This one slipped between our fingers:
Problem
Gateway.APICommandsis ignored, go-ipfs 0.8.0 uses hardcoded list of commands:(cmd/ipfs/daemon.go#L669 → core/commands/root.go#L166-L198
Why this matters
This is blocking our users from running their own delegated routing service without additional nginx magic as noted in libp2p/js-libp2p#371:
How to fix it?
Unsure, needs more analysis.
I see two ways to resolve this:
(A) keep implicit safelist, extend it with values added to
APICommandsA backward-compatible way to fix this is to keep current implicit defaults from core/commands/root.go#L166-L198 when
Gateway.APICommandsis empty, but if we do this, how can gateway operator disable/api/v0entierely if they wish to do so?(B) no
/api/v0by default, only explicit opt-in safelist viaAPICommandsPerhaps we should make a breaking change and disable
/api/v0by default on Gateways, unless user explicitly safelisted commands viaGateway.APICommands?This feels like a way safer default.We have some features that depend on/api/v0and/ipfs/endpoint does not provide replacement for them yet, so better to avoid this (eg. we don't want user to safelistdht/putbut breakrefsas a side effect)It always felt to me like something that should be opt-in, but would appreciate feedback if someone thinks otherwise.