search

ipfs / infra

Tools and systems for the IPFS community
MIT License
133 stars 41 forks source link

Force HTTPS for path-based requests to dweb.link #479

Closed lidel closed 4 years ago

lidel commented 5 years ago

Background

I believe that if dweb.link aims to replace ipfs.io as the default gateway, we should also support path-based addressing.

Problem

Right now unencrypted requests for dweb.link/ipfs/* work, but do not redirect to HTTPS:

Explicit request over HTTPS produces certificate error:

Fix

This looks like a bug, so I think we want to redirect to HTTPS and add HSTS header. (Possibly reusing fixes from https://github.com/ipfs/infra/issues/391 & https://github.com/ipfs/infra/issues/477 to dweb.link itself).

lidel commented 5 years ago

Update:

I think what we want for dweb.link is to always redirect to subdomain version.

That removes the risk of website under /ipfs/<cid-A> accessing cookies and localStorage of website under <cid-B>.ipfs.dweb.link

So we want http://dweb.link/ipfs/bafybeiemxf5abjwjbikoz4mc3a3dla6ual3jsgpdr4cjr3oz3evfyavhwq/wiki/Vincent_van_Gogh.html to return HTTP 301 to https://bafybeiemxf5abjwjbikoz4mc3a3dla6ual3jsgpdr4cjr3oz3evfyavhwq.ipfs.dweb.link/wiki/Vincent_van_Gogh.html

mburns commented 4 years ago

New CIDs are correctly being redirected: https://dweb.link/ipfs/bafybeiemxf5abjwjbikoz4mc3a3dla6ual3jsgpdr4cjr3oz3evfyavhwq/wiki/Vincent_van_Gogh.html

It doesn't work with legacy (Qm...) CIDs (example: https://dweb.link/ipfs/QmczMzVBGXmUeyUprcGnac63gKDfMVNUY4cQ8V6xQEBN52/ )

lidel commented 4 years ago

@mburns but it can be fixed, right? (https://github.com/protocol/bifrost-infra/issues/572#issuecomment-622374027) Update: nvm, just seen you are already on this in https://github.com/protocol/bifrost-infra/pull/722#issuecomment-622587035 :heart: