Some considerations before pushing the public subdomain gateway

[markg85]

Hi,

I've been watching the weekly videos and saw the idea to rewrite the public domain gateway redirect from:
some.long.url.<gateway>

to:
some-long-url.<gateway>

While i understand both perfectly fine (ultimately they are both to fix the domain certificate issue). Please consider this change very carefully!

You could very well mess up an administrator's time if you do a redirect to a subdomain that might (incidentally) already exist.
And even if it doesn't, there might (will!) be webserver/reverse proxy setups that will give default landing pages if you rewrite public subdomains in either format. My webserver would in fact show a default landing page, not the IPFS page.

I'd therefore like to ask to carefully consider if you actually need this feature. Or at the very least to no enable it by default on public gateway domains. I'd argue that you should whitelist domains that properly allow it and go for the path based route by default (that being /ipns/some.long.url)

Best regards,
Mark

[lidel]

The only redirect that happens is when you make a path-based request to a subdomain gateway root and your reverse proxy adds X-Forwarded-Proto: https. Then (and only then) we do a convenience conversion and redirect to a TLS-safe subdomain:

• https://dweb.link/ipns/en.wikipedia-on-ipfs.org/ → https://en-wikipedia--on--ipfs-org.ipns.dweb.link/
  • Once again: this feature is an opt-in. Redirect to single-label will happen only IF X-Forwarded-Proto: https is present (added at reverse proxy by its admin). Without the header, original FQDN is used in subdomains but you won't be able to load DNSLink names over https:// due to TLS for DNSLink websites loaded via public subdomain gateways in-web-browsers#169.

The catch-all reverse proxy for *.ipns.example.com that already works fine for single-label libp2p-key CIDs (such as k51qzi5uqu5dgutdk6i1ynyzgkqngpha5xpgia3a5qqp4jsh0u4csozksxel2r.ipns.example.com) could not return invalid response for en-wikipedia--on--ipfs-org.ipns.example.com, unless it was already broken/misconfigured somehow.

@markg85 do you mind providing an example config as a demonstration of the reverse-proxy-misconfiguration-problem you describe? I worry I did not understand your concerns fully.

[markg85]

Ah, right, it might work if - and only if - a web admin setting up the reverse proxy for an ipfs gateway sets it up in such a way that *.ipfs.<gateway> and *.ipns.<gateway> are handled by the gateway.

It's annoying that this subdomain gateway change forces a change in nginx configuration.
This is not specific to the current change but is an issue that was breathed into life when the subdomain logic was conceived.

So let me flip the question.
What is the proper configuration to have a gateway running with proper support for the subdomains on nginx.
You can assume a gateway like <subdomain stuff>.ipns.<gateway> and <subdomain stuff>.ipfs.<gateway>.

[lidel]

Introduction of subdomains was unfortunately the only way we could get proper isolation between content roots in existing web browsers. Good news is that it was one-time change.

When it comes to Nginx-based setup, you want to run a subdomain gateway on a unique domain name, so all you need is:

• Enable subdomain gateway for your domain in go-ipfs config – see the first recipe here
• In Nginx, forward all gateway requests coming for the domain name to go-ipfs backend, while preserving Host and setting X-Forwarded-Proto so TLS works:

     location / {
      proxy_set_header Host $http_host;
      proxy_set_header X-Forwarded-Proto "https";
      proxy_pass http://go-ipfs-backend;
    }

You can also forward only specific entry points by hand, those are: https://<gateway>/ipfs/*, https://<gateway>/ipns/*, https://*.ipfs.<gateway>/*, and https://*.ipns.<gateway>/*, but you need to pass mentioned headers as well.

I'm closing this as I assume your initial concerns got addressed, but lmk if anything is left unclear, or if subdomain gateway docs could be improved somehow.