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

[MicahZoltu]

Describe the bug
When trying to use the new ipfs/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):

• OS: Windows 10
• Browser: Firefox
• Version: 2.9.0

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]

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

ipfs/ipfs-webui#1613 adds support for APIs protected with HTTP Basic Auth and it would be good to ensure ipfs-companion can do the same.

TODO:

• see if the problem still occurs

[lidel]

• confirmed problem occurs in latest beta
• fix: support API on ipv6 with go-ipfs 0.8+ #931 will remove custom fixup we did for ipv6 in paste and will pass original URL to HTTP Client directly.
• while that will be enough for basic status check and redirect, I suspect opening WebUI and quick upload may require additional work.

[mdonoughe]

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]

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