Safari Support

[Gozala]

https://webui.ipfs.io is unable to use IPFS HTTP API, because all requests are blocked as it is considered mixed content.

There is a known Safari bug report to allow requests to looback addresses https://bugs.webkit.org/show_bug.cgi?id=171934

I'm not sure if we can do much until that bug is resolved, but want to have issue so we can at least track this

[Gozala]

Do we know if this works in default windows browser ? Can anyone with the windows machine try this ?

[akimoto72738]

You need build a reverse proxy and enable https for api url

just likes below

in my case,I created a reverse proxy by nginx and my selfsign cert

[kallisti5]

The issue here is https://webui.ipfs.io needs to be offered over http as well as https.

If http://webui.ipfs.io was available, users could bypass the https loading http blocks.

since webui.ipfs.io is run in browser, there aren't any security issues?

My NAS runs my IPFS API server, and since 5001 is http, I see these kinds of issues.

Pretty much webui.ipfs.io only works with "127.0.0.1" or "localhost" in Firefox as well due to the above issue.

[lidel]

• API port lacks access controls (API Tokens kubo#1532) which makes it too sensitive to be exposed on external interfaces.
  SSH tunnel or reverse proxy with TLS + basic auth or self-signed two-way certs are how you can access it without compromising security.

• The mixed content problem is limited to Safari. AFAIK all the other browsers (Chromium, Firefox) mark 127.0.0.1:5001 as Secure Context. This is part of W3C's Secure Context spec which Safari is not following on purpose.

[kallisti5]

however, that means webui is only useful for ipfs nodes running on the localhost. How is that useful when the desktop client exists?

At minimum webui.ipfs.io needs to document this... given the language nothing really says it's limited to 127.0.0.1 and it lets you put in arbitrary ip addresses, which are guaranteed to not work.

This kind of stuff is what causes all the complaints about folks being confused using ipfs. Look at the ipfs reddit for pages and pages of people going "how does this stuff actually work?"

[kallisti5]

[Gozala]

@kallisti5 that's a fare point and we could improve the language there indeed. I have submitted #1553 to that end. Any help would be welcome.

[Gozala]

One thing we could (although not sure about effort / impact ratio) is to allow running an HTTP API over HTTPS with self signed certificate. On mac you can install those certificates to keychain (programatically) which would allow Safari to access HTTP API.

However there are lot of moving pieces:

1. Generate certificate on device (which go-ipfs would have to do)
2. Install that certificate on device (which go-ipfs would probably have to do if some config is set, that would prompt user and would require them to accept)
3. Run HTTP API over https with that certificate
4. WebUI will have to intelligently detect Safari and dial https instead

It is worth pointing out that this would probably enable accessing HTTP APIs on other devices as well although not on Firefox because it does not regard certificates in keychain. And I have no idea if Windows or Linux would have anything like it.

[kallisti5]

having the api secured via a randomly generated self-signed cert by default would be positive... technically the api could contain sensitive information? The gateway port might benefit as well (securing access from clients through the gateway)

Is there a way to specify https though in the quic address?

At minimum, some feedback / alerting when the API endpoint is unreachable in webui would help a lot.. it took me an hour or two to trace down why it wasn't working.. a lot of folks might give up entirely on ipfs here.

[lidel]

• Some improvements landed in feat: improved support for remote API #1613
• There is also open PR for visual feedback (feat: add visual feedback on API address change #1671) which should improve UX on Safari

[lidel]

This is blocked by work happening in https://bugs.webkit.org/show_bug.cgi?id=171934#c70

[kallisti5]

This issue likely needs rebranded a bit. "Support for Safari and non-localhost API servers" would describe the issue a bit better.

Here's a random screenshot of Firefox running into a similar issue:

Solutions:

• API server begins always presenting over HTTPS via a self-generated SSL certificate
• webui.ipfs.io , dev.webui.ipfs.io start presenting over HTTP and HTTPS (instead of redirecting to HTTPS)