search

ipfs / ipfs-companion

Browser extension that simplifies access to IPFS resources on the web
https://docs.ipfs.tech/install/ipfs-companion/
Creative Commons Zero v1.0 Universal
2.07k stars 324 forks source link

Origin set to extension when username/password provided in API URL. #919

Open MicahZoltu opened 4 years ago

MicahZoltu commented 4 years ago

Describe the bug When trying to use the new ipfs-shipyard/ipfs-webui#836 Protected APIs feature, the requests sent by the extension appear to have the Origin set to Origin: moz-extension://2a708cae-2cdd-45f2-83ff-2d7e331e4a6f. When I remove the username/password from the URL, the origin is not set. This results in the request with the origin failing with a 403, while the request without the origin succeeds with a 200. All other headers appear to be the same between the requests (including Authorization and Host headers).

To Reproduce Steps to reproduce the behavior:

  1. Install IPFS Companion
  2. Set the API URL to a remote server with https://user:pass@domain format.
  3. Debug the extension.
  4. Notice that the Origin is set on all outgoing requests from the extension.
  5. Change to an API URL with https://domain format.
  6. Notice that the Origin is header is left off of the request.

Expected behavior Adding a username/password doesn't result in a new Origin header being added to the request.

Desktop (please complete the following information):

Additional context I have not been able to figure out why the request returns a 403 when the Origin header is present, it could be CloudFlare, it could be my reverse proxy, or it could be IPFS server. I strongly suspect it is a CORS thing though. I'm hoping that extensions have the ability to override the automatic origin header addition. If not, I'll probably have to dig a bit and figure out how to prevent CORS from blocking requests with an origin of moz-extension://....

lidel commented 4 years ago

Thank you for reporting this @MicahZoltu, this slipped between cracks, but I've moved it to the correct repo, sorry the delay!

https://github.com/ipfs-shipyard/ipfs-webui/pull/1613 adds support for APIs protected with HTTP Basic Auth and it would be good to ensure ipfs-companion can do the same.

TODO:

lidel commented 4 years ago
mdonoughe commented 2 years ago

I'm seeing a different behavior. When I set the API URL to a remote server with basic authentication parameters embedded in the same format, the URL is passed as-is to js-ipfs/ipfs-http-client, which passes it to the Fetch API. The Fetch API does not allow credentials to be specified in this way. Firefox prohibits it since version 43 (2015). The request does not get made to the server so the origin doesn't get sent. Was something previously extracting the credentials from the URI and convert them into an Authorization header?

Is there a workaround for this? It looks like ipfs-http-client accepts a URL or an options object and it looks like the options object accepts HTTP headers, similar to (the same as?) Web UI, but IPFS companion restricts the input to URIs.

ghost commented 2 years ago

The Cli for IPFS desktop completely Effed me since I am so so new at this.