search

ipfs / in-web-browsers

Tracking the endeavor towards getting web browsers to natively support IPFS and content-addressing
https://docs.ipfs.tech/how-to/address-ipfs-on-web/
MIT License
349 stars 29 forks source link

Hostnames for localhost HTTP gateway #109

Closed lidel closed 1 year ago

lidel commented 6 years ago

Motivation

Requirements

I wonder if there is a way of generating vanity hostnames pointing at localhost that:

If anyone has unconventional ideas, feel free to comment.

Candidates

*.localhost

Current status

:lock: – window.isSecureContext === true :anger: – window.isSecureContext === false

Status Firefox Chrome
127.0.0.1 :lock: :lock:
localhost :lock: :lock:
foo.bar.localhost :anger: :lock:

References

lidel commented 6 years ago

Candidate: http://{fqdn}.ipns.localhost Test URL: http://docs.ipfs.io.ipns.localhost:8080/ipns/docs.ipfs.io Result:

olizilla commented 6 years ago

There are some occult tricks for browsers on mac and windows; you can do some automagic with this https://en.wikipedia.org/wiki/Proxy_auto-config

I found it via https://github.com/KishanBagaria/frwrd

lidel commented 6 years ago

[..] you can do some automagic with this https://en.wikipedia.org/wiki/Proxy_auto-config

Changing proxy setting globally is not a good idea, however Firefox provides browser.proxy API with a very interesting property:

use the proxy.onRequest event listener to intercept web requests, and return an object that describes whether and how to proxy them.

This would enable us to use PAC-like processing only for IPFS requests. (Right now we just redirect them)

lockedshadow commented 5 years ago

Linux -1 (Works on a box with unbound, does not resolve on stock Debian)

Seems like that it also depends on myhostname plugin for /etc/nsswtich.conf, which is not installed by default in Debian. With this plugin installed and activated, the test URL actually redirects to http://{local_gateway}/ipns/docs.ipfs.io/ when IPFS integrations and DNSLink support is enabled in IPFS Companion, and just open as is when IPFS integrations disabled in add-on.

From man nss-myhostname:

The hostnames "localhost" and "localhost.localdomain" (as well as any hostname ending in ".localhost" or ".localhost.localdomain") are resolved to the IP addresses 127.0.0.1 and ::1.

lidel commented 5 years ago

I think switching from 127.0.0.1 to ::1 where possible is the best we can do right now, given cross-platform constraints.

Having local gateway at ::1 looks less intimidating:

2019-01-08-125329_758x575_scrot

For now, this can be enabled manually via:

$ ipfs config --json Addresses.Gateway '["/ip4/127.0.0.1/tcp/8080","/ip6/::1/tcp/8080"]'

A proposal to extend default Addresses.Gateway with /ip6/::1/tcp/8080 is at https://github.com/ipfs/go-ipfs/issues/5905

lidel commented 5 years ago

Update: there may be a way to support http://<cidv1b32>.ipfs.localhost on every platform supporting HTTP Proxies – see proposal in https://github.com/ipfs/go-ipfs/issues/5982

lidel commented 5 years ago

Notes on Secure Context and .ipfs.localhost – https://github.com/ipfs-shipyard/ipfs-companion/issues/667#issuecomment-467669949

lidel commented 5 years ago

The ".dweb" Special-Use Domain Name: https://github.com/arewedistributedyet/arewedistributedyet/issues/34

lidel commented 5 years ago

Interesting development: As of 2019-10 localhost (hostname) is a secure context in both Firefox and Chrome.

Caveat: Firefox does not include subdomains (foo.bar.localhost is not a secure context), but I posted our use case in related bug to match behavior from Chrome: https://bugzilla.mozilla.org/show_bug.cgi?id=1433933#c6

There is also a discussion to skip DNS lookup for *.localhost (https://bugzilla.mozilla.org/show_bug.cgi?id=1220810) and hardcode it to loopback, which would make it work on all platforms, regardless of local DNS setup.

This makes *.localhost nearly ready for use (waiting for Firefox to match Chrome). I updated the first post in this issue to reflect current status.

Demo

Loaded http://en.wikipedia-on-ipfs.org.ipfs.localhost:8080/ipns/en.wikipedia-on-ipfs.org/wiki/ today and Chrome marks it as secure context:

Firefox 69 Chrome 78
isSecureContext: false isSecureContext: true
secure-context-firefox-2019-10-01--15-30-25 secure-context-chrome-2019-10-01--15-30-25
lidel commented 4 years ago

Quick update (in the context of https://github.com/ipfs/go-ipfs/issues/7527):

Since go-ipfs 0.5, when user runs local IPFS node, they can load websites and content via subdomains like this:

http://bafybeiemxf5abjwjbikoz4mc3a3dla6ual3jsgpdr4cjr3oz3evfyavhwq.ipfs.localhost:8080/wiki/ http://bafybeid6grcjmnvsdaeklremt2lcqk7jevbjtwrerzgq46nzxfgn5isrne.ipfs.localhost:8080/images/ipfs-logo.svg

There are two known problems with *.localhost at the moment:

  1. If browser vendor does not hardcode localhost to point at loopback, then it is resolved by OS DNS resolver, and on some platforms that can produce error. Fix here is to implement section 6.3.3 from https://tools.ietf.org/html/rfc6761#section-6.3 (Chromium-based browsers already do this)

  2. Content at *.localhost should be marked as Secure Context. Right now some vendors such as Firefox handle localhost and *.localhost differently, partially due to legacy code, partially due to my previous point.

Implementing "let localhost be localhost" (6.3.3 from rfc6761) would ensure localhost can resolve on every platform and can be marked as secure context – very likely solving both issues.

Vendors are mostly ok with this change:

Unfortunately the movement on Safari and Firefox fronts to resolve it turned out to be slower than we expected. Looking into ways we can accelerate that.

lidel commented 4 years ago

Good news: Chromium officially locked *.localhost to loopback as per https://tools.ietf.org/html/draft-ietf-dnsop-let-localhost-be-localhost-02 :partying_face:

Details from https://bugs.chromium.org/p/chromium/issues/detail?id=589141#c15:

We addressed this in https://bugs.chromium.org/p/chromium/issues/detail?id=691930 but didn't close this bug. There, we locked *.localhost to loopback as per https://tools.ietf.org/html/draft-ietf-dnsop-let-localhost-be-localhost-02 (see https://source.chromium.org/chromium/chromium/src/+/master:net/dns/host_resolver_manager.cc;drc=25292af6cee762330490f47e79e09a071dc4b5a9;l=3091). This means that we also consider *.localhost secure (see https://source.chromium.org/chromium/chromium/src/+/master:services/network/public/cpp/is_potentially_trustworthy.cc;drc=c70af83bc44f6829277cdc3621e7015d6e0d7530;l=228).

This increases likelihood of other vendors to follow.

ianopolous commented 4 years ago

https://bugzilla.mozilla.org/show_bug.cgi?id=1220810#c89

autonome commented 4 years ago

merges to mozilla-central - can't trust them until 24hrs old ;)

lidel commented 4 years ago

Some updates and reading for anyone interested in following *.localhost space :-)

The best support can be found in Chromium (no need for HTTP proxy, local DNS resolver is ignored) Firefox will soon catch up thanks to our partnership with Igalia, we are also reaching out to Webkit to follow.

montanaflynn commented 3 years ago

I get this error: I can access it from chrome but not my Golang program:

"http://zzz.ipfs.localhost:8080/1": dial tcp: lookup zzz.ipfs.localhost: no such host

lidel commented 1 year ago

This was resolved in https://github.com/ipfs/kubo/pull/6096

We went with *.ipfs.localhost and *.ipns.localhost, as it works nearly everywhere: thanks to collaboration with Igalia we now have secure context on subdomains (window.isSecureContext) n both Chromium-based browsers (Edge, Chrome, Brave, Opera), and Firefox.