-
-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HTTP API: Disallow GET requests #7097
Conversation
This might break tests, not sure, I will fix those on another day. |
I have a test failure that seems unrelated:
|
@lidel can you help with the webui test failure (I have the feeling it will take you way shorter than me to figure out the place to fix it). |
I will take a look as soon I get back home (eta 1h) Update: see ipfs/ipfs-webui#1429 |
Ok:
Pending:
|
ipfs/kubo#7097 will block `GET` commands on API port, switching everything to POST. This breaks Files screen in ipfs-webui as noted in ipfs/ipfs-webui#1429 ipfs-webui is using older version of js-ipfs-http-client, one before huge refactor into async iterables, which means switching to the latest version won't be a trivial task. For now, we just apply simple patch on top of ipfs-http-client v39.0.2 to ensure it sends commands as POST. Proper fix will land when ipfs-webui is refactored to work with ipfs-http-client >41.x Closes #1429
ipfs/kubo#7097 will block `GET` commands on API port, switching everything to POST. This breaks Files screen in ipfs-webui as noted in #1429 ipfs-webui is using older version of js-ipfs-http-client, one before huge refactor into async iterables, which means switching to the latest version won't be a trivial task. For now, we just apply simple patch on top of ipfs-http-client v39.0.2 to ensure it sends commands as POST. Proper fix will land when ipfs-webui is refactored to work with ipfs-http-client >41.x Closes #1429
* fix: support POST-only HTTP API ipfs/kubo#7097 will block `GET` commands on API port, switching everything to POST. This breaks Files screen in ipfs-webui as noted in #1429 ipfs-webui is using older version of js-ipfs-http-client, one before huge refactor into async iterables, which means switching to the latest version won't be a trivial task. For now, we just apply simple patch on top of ipfs-http-client v39.0.2 to ensure it sends commands as POST. Proper fix will land when ipfs-webui is refactored to work with ipfs-http-client >41.x Closes #1429 * docs: remove GET from CORS setup for API
This commit upgrades go-ipfs-cmds and configures the commands HTTP API Handler to only allow POST/OPTIONS, disallowing GET and others in the handling of command requests in the IPFS HTTP API (where before every type of request method was handled, with GET/POST/PUT/PATCH being equivalent). The Read-Only commands that the HTTP API attaches to the gateway endpoint will additional handled GET as they did before (but stop handling PUT,DELETEs). By limiting the request types we address the possibility that a website accessed by a browser abuses the IPFS API by issuing GET requests to it which have no Origin or Referrer set, and are thus bypass CORS and CSRF protections. This is a breaking change for clients that relay on GET requests against the HTTP endpoint (usually :5001). Applications integrating on top of the gateway-read-only API should still work (including cross-domain access). Co-Authored-By: Steven Allen <steven@stebalien.com> Co-Authored-By: Marcin Rataj <lidel@lidel.org>
…Allowed Spec says that response with 405 must set Allow headers.
PSA: this will require IPFS Companion v2.11.x or later (shipped a Beta for testing: v2.11.0.904) |
Of course I'll adapt to this in py-ipfs-http-client, but may I ask what the rationale is/was for blocking GET on idempotent & read-only API endpoints? Why can't things like |
Basically, the HTTP API is not a REST API, it's a simple RPC API. In go-ipfs, at least, it's defined as a set of transport agnostic commands, then exposed through an HTTP API. Note: You can continue to use GET requests against the read-only API on the gateway. |
Too bad 🙁… I have some code deployed that uses the HTTP API as read-only API since its port is stable (5001) while the gateway port is unusable (8080 is way to generic). The decision to also enforce this for the read-only parts of the API parts that are also exposed via the gateway is final, I suppose? Does the read-only API exposed via the gateway support using POST or does it only support GET instead? |
I think both. |
We have no intention of changing this as it simplifies reasoning about the system. Is it not possible for you to use POST? |
@Alexander255 @hsanjuan 👉 A subset of $ curl -X GET http://127.0.0.1:5001/api/v0/dns/ipfs.io
405 - Method Not Allowed
$ curl -X GET http://127.0.0.1:8080/api/v0/dns/ipfs.io
{"Path":"/ipfs/bafybeibdwwmb725qy4yph56jg4bs6uimcst5hnvuraarowgdaytzmgsw24"} |
With the read-only API on gateway supporting POST, I can still pretend they are the same so no problem for me then. I just feels weird to use POST there, but if it makes stuff easier for you so be it. 👍 |
HTTP API: Only allow POST requests (plus OPTIONS) This commit was moved from ipfs/kubo@3304c28
Better security by limiting the HTTP API to POST requests. (see commit descriptions).