Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Subdomain Gateway #6498

Closed
lidel opened this issue Jul 11, 2019 · 2 comments · Fixed by #6096
Closed

Subdomain Gateway #6498

lidel opened this issue Jul 11, 2019 · 2 comments · Fixed by #6096
Labels
topic/gateway Topic gateway

Comments

@lidel
Copy link
Member

lidel commented Jul 11, 2019

This is a prerequisite for #5982,
but also a very needed standalone feature.

Context

Base32-encoded CIDv1 can be used in DNS as a subdomain label:

https://<cidv1b32>.ipfs.example.com
https://<cidv1b32>.ipns.example.com

It provides unique Origin per CID and enables websites to get a valid origin-based security perimeter for free.

Examples of "Subdomain Gateways" in production:

How it works today? What is missing?

Right now HTTP Gateway exposed by go-ipfs does not support HTTP requests for hostnames that match <cidv1b32>.ipfs.* – all existing subdomain gateways implement CID conversion and path redirect in Nginx (config example) or other reverse proxy running in front of go-ipfs.

Support requests with Host: <cidv1b32>.ipfs.*

go-ipfs already supports DNSLink. We need it to also support HTTP requests for hostnames that match <cidv1b32>.ipfs.*. It would enable people to run subdomain gateways without the need for running reverse proxy.

Assuming go-ipfs is running a gateway on localhost:8080, below should work:

$ curl -v 'http://bafkreigh2akiscaildcqabsyg3dfr6chu3fgpregiymsck7e7aqa4s52zy.ipfs.localhost:8080/wiki/'
> GET /wiki/ HTTP/1.1
> Host: bafkreigh2akiscaildcqabsyg3dfr6chu3fgpregiymsck7e7aqa4s52zy.ipfs.localhost:8080

Related

@lidel
Copy link
Member Author

lidel commented Jul 15, 2019

Notes from 1:1 with @Stebalien:

  • we dont want both subdomain (http://<cidv1b32>.ipfs.example.com/) and path gw (http://example.com/ipfs/<cid>) on the same hostname
    • path gw would "own" everyone's cookies, it breaks Origin isolation introduced by custom hostname, defeating the whole purpose of CID-based Origins
  • how to handle it?
    • add a separate port for subdomain gateway?
      • 👍 creates separate Origins, but 👎 introduces THIRD port to maintain and set up, which is pushing work on people responsible for deployment
    • make it configurable and redirect to either path or subdomain based URLs
      • what about localhost node? users will want to use both
        • potential fix: redirect *localhost/ipfs/ to 127.0.0.1/ipfs/
          • it will put path-based gateway on a different Origin

Update: I proposed some solutions in #6096 (comment)
Update: Documented path vs subdomain gateways: https://docs.ipfs.io/guides/guides/addressing/
Update: Current status of *.ipfs.localhost (hostname for localhost gateway): ipfs/in-web-browsers#109 (comment)

@lanzafame lanzafame added the topic/gateway Topic gateway label Jul 15, 2019
@Stebalien
Copy link
Member

First step: libp2p/go-libp2p-core#41

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic/gateway Topic gateway
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants