search

ipfs / js-ipfs

IPFS implementation in JavaScript
https://js.ipfs.tech
Other
7.44k stars 1.25k forks source link

POST-only HTTP API #2971

Closed lidel closed 4 years ago

lidel commented 4 years ago

Problem

go-ipfs 0.5 will block GET commands on the API port (https://github.com/ipfs/go-ipfs/pull/7097), requiring every command to be sent as HTTP POST request (makes it a true RPC + solves some security issues).

:mag: Ensure ipfs-http-client works with API without GET

:sweat_smile: Ship a patch release for old JS API?

Blocking GET broke Files screen in ipfs-webui as noted in https://github.com/ipfs-shipyard/ipfs-webui/issues/1429#issuecomment-609071306

ipfs-webui is using older version of ipfs-http-client, one before huge refactor into async iterables, which means switching to the latest version won't be a quick task.

I suspect there are third party projects which use older version of ipfs-http-client but have no time to refactor entire codebase to work with the latest version. We could make it easier if we shipped a patch release with literally 7 line diff (ky.get → ky.post, as seen in seen in ipfs-http-client@39.0.2.patch)

I am unsure how to do this given we moved to monorepo recently. I think v41.0.0 of ipfs-http-client was the last release before Async Await and Async Iterables.

@achingbrain is it possible to release something like ipfs-http-client@41.0.1? Any way I can help?

Update: ipfs-http-client@41.0.1 is ok for use (if you are stuck at old API)

bluelovers commented 4 years ago

this? https://github.com/lerna/lerna/tree/master/commands/version#--allow-branch-glob

achingbrain commented 4 years ago

I am unsure how to do this given we moved to monorepo recently.

The history from merged repos has been maintained so it should just be a case of making a branch from the last ipfs-http-client release commit, making the changes, doing the release and pushing the updated branch back to the repo.

lidel commented 4 years ago

Good news: turns out ipfs-http-client@41.0.1 exists – it was the last version which provided the old JS API, but on the backend was refactored to use new one, and in the process all ky.get calls were replaced to ky.post (I checked all 7 problematic ones).

This means we don't need to make any patch releases – ipfs-http-client@41.0.1 is POST-only already.

What remains to be done is to convert API exposed by js-ipfs to match behavior of go-ipfs more closely (POST-only, additional Origin/Referer check, load webui from API port instead of gateway).

@achingbrain my plan is to implement the above before I jump into https://github.com/ipfs/js-ipfs/issues/1877, if that is okay with you?

achingbrain commented 4 years ago

Sounds good, thanks @lidel

achingbrain commented 4 years ago

This has been fixed in js-ipfs by #2977

achingbrain commented 4 years ago

..and released in js-ipfs@0.43.0 and js-ipfs-http-client@44.0.0

lidel commented 4 years ago

Thank you! Continued in: