1. Increase broadcast timeout.
2. Fix use of sessions when pinning.
This also includes some bitswap changes to reduce some memory allocations and
optimize some hot spots.
1. Enable AutoNATService on _all_ nodes by default. If it's an issue, we can
disable it in RC3 but this will give us the best testing results.
2. Expose options to configure AutoNAT rate limiting.
And remove retry logic. This was flatfs specific and we've moved the logic down
into flatfs itself.
This update:
* Retries in more cases when we run out of file descriptors.
* Ensures we don't leak temporary files on batch put.
This still works over "loosely defined" .car files
Please refer to the sharness tests for extra info
We can tighten this up if the sentiment is "Postel was wrong"
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>
This logic collects a list of known relays by testing every new connection.
It exists so we can dial /p2p-circuit/p2p/QmFoobar addresses (circuit addresses
that don't specify the relay). However, this kind of address is useless outside
of basic demos as a random relay is practically guaranteed to not be connected
to the target peer. Picking a random relay to connect to some peer is almost
_never_ the desired behavior.
Instead of feeding through the top-level context, feed through a cancel-free
context (that still carries the same context values). Then, when the top-level
context is canceled, call `stop` to shut everything down in-order. Finally,
cancel the inner context to make sure everything has been cleaned up.
Ideally, we just wouldn't use contexts for this. But this is strictly better
than what we have.
When request is sent to http://localhost:8080/ipfs/$cid response has
HTTP 301 status code and "Location" header with redirect destination at
$cid.ipfs.localhost:8080
Redirect is followed by browsersi, but not by commandline tools.
Status 301 is ignored by curl in default mode: it will print response
and won't follow redirect, user needs to add -L for that.
To fix curl, we return correct payload in body of HTTP 301 response,
but set Clear-Site-Data header to ensure Origin sandbox can't be abused.
This requires a surgical workaround:
If Location header is present in ResponseWriter's Header map,
we ensure http.ServeContent() returns HTTP 301
Context: https://github.com/ipfs/go-ipfs/pull/6982
License: MIT
Signed-off-by: Marcin Rataj <lidel@lidel.org>
Instead of adding a new fake header (that could be spoofed by the client...),
just read the original request URI from the request object.
This also removes support for suborigins. They have never been implemented in
browsers and it looks like efforts have stalled. We can add support back if we
need it but, well, maintaining support was going to be more trouble than it was
worth.
License: MIT
Signed-off-by: Steven Allen <steven@stebalien.com>
