Gateway.APICommands configuration is ignored

[lidel]

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.

[aschmahmann]

We're going to go with option A here.

[BigLep]

@lidel : is this a good candidate for @schomatis ?

[schomatis]

Yes, assigning.

[schomatis]

@lidel Working on this, do we want an extra config for

how can gateway operator disable /api/v0 entierely if they wish to do so?

?

[schomatis]

@lidel Looking at APICommands, this option is an array of strings. How should they work? Do we expect the user to provide the name of ipfs subcommands (which we would search by reflection I imagine), would they provide more specialized subcommands, like block.get or block.stat, for example, to only select the read variants of a subcommand?

I'm temporarily blocking this issue on getting some simple and concrete examples since I don't see any documentation around the option that we need to implement.

[lidel]

@schomatis

• yes, we want to allow safelisting of a specific subcomand so people don't expose too much.
  • Cosmetic note: using / as a separator may be a better idea, as cmd/subcmd maps to /api/v0/cmd/subcmd URL paths better than .
• re "how can gateway operator disable /api/v0 entierely if they wish to do so?" – what we want is to remove all implicitly exposed /api/v0 endpoints from the gateway port, and expose only things that user explicitly added to the APICommands array.
  • Rationale: most of the gateway operators don't need anything from /api/v0 and exposing it only opens them to expensive preload calls like /api/v0/refs?r=true (which are inexpensive for person sending the request)

[schomatis]

We're definitely not prepared to select only a subset of subcommands. This will likely require some reworking of the commands library.

[schomatis]

The simplest approach seems to add a function to prune the commands root given a list of whitelisted commands. The code would use similar logic to the subcommand resolution.

We should use a single hardcoded "master" root:

https://github.com/ipfs/go-ipfs/blob/25cc85fa9359f907f348e0c2139f2b535313c56c/core/commands/root.go#L122-L126

from which all the other subsets like the hardcoded read-only variant

https://github.com/ipfs/go-ipfs/blob/25cc85fa9359f907f348e0c2139f2b535313c56c/core/commands/root.go#L174-L182

would instead be generated on-the-fly through a list of strings (just as the APICommands one the user would provide in its config file) using this new logic.

---

re "how can gateway operator disable /api/v0 entierely if they wish to do so?" – what we want is to remove all implicitly exposed /api/v0 endpoints from the gateway port, and expose only things that user explicitly added to the APICommands array.

I still can't detect a clear answer to this. When APICommands is empty do we want to use the read-only list (shown above) or nothing (allow no command)?

---

@lidel Blocking until getting confirmation on the proposed approach.

[lidel]

@schomatis Generating gateway subset on the fly based on APICommands sgtm.

When APICommands is empty do we want to use the read-only list (shown above) or nothing (allow no command)?

We want nothing – exposing /api/v0 on Gateway should be a conscious opt-in.

[schomatis]

Blocked on landing ipfs/go-ipfs-cmds#231.

[hacdias]

@lidel considering the current goal of removing /api/v0 from the gateway port completely, I would suggest just removing the configuration.

[lidel]

@hacdias yep, it is not even documented at docs/config.md, let's remove it.

[hacdias]

@lidel there you have it #10309