Share Link incorrectly gives path routed instead of subdomain routed URL.

[MicahZoltu]

• OS: Windows
• Version of IPFS Desktop: 0.32.0

Describe the bug
When you right click on a file in Files and choose "Share Link" you are given a URL like https://<host>/ipfs/<cid>. This should be of the form https://<cid>.ipfs.<host> for security reasons.

To Reproduce
Steps to reproduce the behavior:

1. Go to Files tab.
2. Right click on any file.
3. Choose "Share Link"
4. Notice the link provided uses path routing.

Expected behavior
Subdomain routing is always used.

Additional context
Path routing is known to be insecure for websites that use cookies, local storage, etc. This is well documented in the IPFS documentation and the documentation and security experts all recommend using subdomain routing whenever possible (which is almost always possible). These share links are encouraging people to share URLs that are insecure by default, and we should instead be using subdomain by default.

[whizzzkid]

Thanks @milahu this sounds like a good feature to have, the reason it doesn't have it today is because not all gateways support subdomain gateways. The default gateway does, but that's not the norm. I think we can implement a simple check to validate if the server supports subdomain gatways and then generate those links.

I'll mark this as a backlog item.

[acul71]

I'm working on fixing this issue

I'm currently working on a fork of ipfs-webui https://github.com/ipfs/ipfs-webui at https://github.com/acul71/ipfs-webui-fork.

• I've implemented a checkGateway(gatewayUrl) function to verify if a gateway supports Subdomain URLs. I adapted the code from https://github.com/ipfs/public-gateway-checker.

• I also modified getShareableLink in files.js (https://github.com/ipfs/ipfs-webui/blob/main/src/lib/files.js) so it can return either a Path gateway URL or a Subdomain gateway URL, depending on the gateway's capabilities.

• Now, I'm working on the preferences page.
  I'm undecided about where to place the checkGateway test. My current idea is to run this test whenever the Public Gateway in preferences is modified and save the result, so it can determine which type of Gateway URL to use in getShareableLink.

Should there be a preference setting to enable or disable Subdomain Gateway URLs?
Should this be shown as a preference info item?
Thanks!

[lidel]

@acul71 thank you for looking into this.

Note that sending https://<host>/ipfs/<cid> to subdomain gw like dweb.link returns HTTP 301 to correct URL at https://<cid>.ipfs.<host>, there is no security issue, and user always ends up in unique origin based on root CID.

Is your intention to avoid this redirect when default is changed to subdomain gateway like dweb.link?
If so, you need to check that <cid> is no longer than 63 characters (reason below).

Note that the current default in ipfs-webui is still ipfs.io (path gw):

ipfs-webui/src/bundles/gateway.js

Line 3 in 27bea32

export const DEFAULT_GATEWAY = 'https://ipfs.io' // TODO: switch to dweb.link when https://github.com/ipfs/kubo/issues/7318

So the users by default will not benefit from your check. Changing the default here would do the trick.

But, there is a problem with using dweb.link by default: we did not switch default to subdomain gateways because not every asset is website, not everything needs origin isolation, and some long CIDs/hashes are not compatible with DNS label length (ipfs/kubo#7318).

As prior art, IPFS Companion is bit further in the migration, and has two settings:

Perhaps ipfs-webui should have something similar, with extra check to decide which one to use, based on shared CID:

dweb.link (subdomain isolation) being listed first, and being the new default, but ipfs.io (path gateway fallback) being listed also, used for CIDs that can't be represented in 63 character DNS label.
This way user can adjust both subdomain and path gateway they use, but by default we use subdomain whenever possible.

Thoughts?

[acul71]

@lidel Thank you for your detailed response.

I agree with your suggestion that "ipfs-webui should have something similar, with an extra check to decide which gateway to use based on the shared CID." I'll proceed in this direction.

Thanks for the guidance!

[acul71]

@lidel

Hello there.
I've modified the setting page like this:

Are the labels ok?
Should I add some tests, which ones do you suggest?
In this case how do I get a CID v1 with lengh > 63 chars?
Thanks.

[SgtPooki]

Are the labels ok?

I think the labels are decent, but they feel a little too similar. Maybe we need a disclaimer saying that certain content that doesn't need origin-isolation for the subdomain gateway input.

Should I add some tests, which ones do you suggest?

I think a simple test on the use of those config items would be most important. Then two basic tests ensuring the reset and submit buttons work.

In this case how do I get a CID v1 with lengh > 63 chars? Thanks.

Here is a very long CID v1 (using sha3-512): https://explore.ipld.io/#/explore/bagaaifcavabu6fzheerrmtxbbwv7jjhc3kaldmm7lbnvfopyrthcvod4m6ygpj3unrcggkzhvcwv5wnhc5ufkgzlsji7agnmofovc2g4a3ui7ja

[acul71]

@lidel @SgtPooki
acul71#1

[lidel]

@acul71 are you using AI or some GUI tools? That PR makes no sense (it merges from main in this repo to a branch in your repo, and changes described in PR description are not in git).

What you want to do is to open PR from your form into this repository.

[acul71]

@lidel
Sorry did submit too late in the night....
Thanks, is this ok:
#2255