search

ipfs / kubo

An IPFS implementation in Go
https://docs.ipfs.tech/how-to/command-line-quick-start/
Other
16.03k stars 3k forks source link

/ipfs/ and /ipns/ links don't work from a dnslink hosted web space #3902

Open dustin opened 7 years ago

dustin commented 7 years ago

Version information:

go-ipfs version: 0.4.9-rc1- Repo version: 5 System version: amd64/darwin Golang version: go1.8

Type: Bug

Severity: Medium

Description:

When accessing IPFS via a dnslink-serviced host (e.g. ipfs.sallings.org), /ipfs/ and /ipns/ links don't work.

e.g.,:

http://ipfs.sallings.org/ipns/QmP8uqUuowHdixyFASba87ABgVxfoKGj8NyrTH2VLLTFkZ

yields:

ipfs resolve -r /ipns/ipfs.sallings.org/ipns/QmP8uqUuowHdixyFASba87ABgVxfoKGj8NyrTH2VLLTFkZ: no link named "ipns" under QmaYYjrg1rEYddWYLcR96uc9jGLA9cuHkUiCqQYLwbKDnx

I would expect either ipfs or ipns to be handled in this case when it can't be resolved directly (or just always).

This seems minor, but I considered it "medium" severity as it means you can't link to separately managed pages within IPFS from such a host. In the above case, I worked around this by linking to //gateway.ipfs.io/ipns/... -- but this is quite undesirable for a variety of reasons (e.g., can't just browse stuff at localhost).

whyrusleeping commented 7 years ago

@lgierth thoughts here?

arfonzocoward commented 5 years ago

Hi all, I'm seeing this issue with ipfs 0.4.18.

As soon as I remove the TXT record for dnslink, /ipns and /ipfs paths work again on my gateway services. I can reproduce this consistently on multiple nodes.

It's kind of annoying because it then becomes either/or: either you use dnslink to provide a nice non-hash URL-based page, OR you can use /ipns and /ipfs. But not both.

Thanks, keep up the great work!

Stebalien commented 5 years ago

Are you trying to run a public gateway? Personally, I recommend using a separate domain for security/pain reasons.

If you're curious, we handle this by sticking an nginx reverse proxy out in front of our gateway and clearing the Host header for /ipfs, /ipns, etc.

ghost commented 5 years ago

The current behaviour is as expected, but there have been discussions in the past to allow /ipns and /ipfs within dnslink+Host websites, just so that you can reference stuff without a domain.

However, the IPFS Companion browser extension picks up /ipfs and /ipns paths on any domain, so that's not really a problem anymore.

arfonzocoward commented 5 years ago

Thanks guys. In the end we've gone the separate domain route, so I'm relieved to hear that seems to be a suggested solution. Thanks for the tip regarding the reverse proxies, I will keep this in mind, it's good to know how to achieve that functionality (we use varnish, but I think header stripping can be done there if needed).

As for the behaviour being expected: perhaps it bears making this clear(er) in the documentation, I'm not sure I found this anywhere. The docs are otherwise very clear and concise. I guess I was looking at the public gateway(s), thinking my private gateway should operate similarly.

Thanks again for the assistance!

LeDechaine commented 1 year ago

Apparently when an IPFS server (somehow) sees a DNSLink, it caches it for a while / forever (?). How to clear a "DNSLink" from the "cache" after it's deleted from the DNS servers? I don't know. So I got stuck there too.

If it can help anyone, setting "NoDNSLink": true instead of false in the ipfs/config file fixed the problem for me. Otherwise your personal IPFS server (already programmed to redirect everything to /ipns/your-website, for example) just becomes a webpage saying ipfs resolve -r /ipns/dnslink/ipns/your-website: no link named "ipns" under (cid). or something similar.