Images not showing when IPFS Companion is activated in Firefox

[erik-ros-devilsberg]

When the IPFS Companion plug-in is installed and active in Firefox. The IPFS images do not show on pool.pm. After disabling the plugin, the images do appear. I've reported this behavior with IPFS as well. Not sure if the plugin or the website is ultimately responsible for the behavior.

[lidel]

@SmaugPool is it possible to get code snippet responsible for lazy-loading images from IPFS gateway, or the name of the library you use? See ipfs/ipfs-companion#1032 (comment)

[SmaugPool]

@SmaugPool is it possible to get code snippet responsible for lazy-loading images from IPFS gateway, or the name of the library you use? See ipfs/ipfs-companion#1032 (comment)

Sorry @lidel I missed your question all this long. There is no specific library used, it's some custom Elm code.
Happy to provide more information if needed.

Note that the problem does not occur anymore on pool.pm/tokens or wallet pages, likely because the way images are loaded has changed, but it can still be reproduced on specific asset pages. For example this random one:

https://pool.pm/asset10j5esgthve8k8axyx2krjhe749r9h9547rrpxf

How does the companion work by the way? Pool.pm does not use ipfs:// URLs so why would the companion try to change them?

[lidel]

@SmaugPool when you open https://pool.pm/asset10j5esgthve8k8axyx2krjhe749r9h9547rrpxf

1. it tries to load image from https://ipfs.poolpm.nftcdn.io/ipfs/QmZ3ScknPbRunbLdHZ4Dsiy1SLV6t5KCf7PT9wLJt7YTSt?tk=HCoKSGPWwh9raJtiKyCmqkQ6LQviJsLG-N3CuEi5sao
2. /ipfs/QmZ3ScknPbRunbLdHZ4Dsiy1SLV6t5KCf7PT9wLJt7YTSt is detected in the image URL
3. ipfs-companion modifies request and redirects to local IPFS gateway, if user has one running (usually http://127.0.0.1:8080)

In the last case, image loads gets blocked by CSP your website has set:

content-security-policy: default-src https://fonts.googleapis.com https://*.poolpm.nftcdn.io https://ipfs.blockfrost.dev https://ipfs.fleek.co https://gw3.easy-ipfs.com https://nftstorage.link https://*.nftstorage.link https://*.ipfs.dweb.link https://cloudflare-ipfs.com https://arweave.net https://*.arweave.net data:; connect-src 'self' https://www.google-analytics.com https://region1.google-analytics.com https://api.pool.pm data: blob: https://*.poolpm.nftcdn.io https://ipfs.blockfrost.dev https://ipfs.fleek.co https://gw3.easy-i…ftcdn.io https://ipfs.blockfrost.dev https://ipfs.fleek.co https://gw3.easy-ipfs.com https://nftstorage.link https://*.nftstorage.link https://*.ipfs.dweb.link https://cloudflare-ipfs.com https://arweave.net https://*.arweave.net; img-src 'self' data: blob: https://*; media-src https://* data:; script-src 'self' blob: 'unsafe-inline' 'unsafe-eval' https://www.googletagmanager.com https://www.google-analytics.com https://unpkg.com/@google/model-viewer/; style-src 'unsafe-inline' https://fonts.googleapis.com/

The quick fix you can do is to update your content-security-policy and allow loading images (img-src) from http://127.0.0.1* and http://localhost* if that is acceptable for now.

A proper upstream fix is to update ipfs-companion to not redirect when CSP header is present and does not allow loading image– I've filled ipfs/ipfs-companion#1241 for that.

[SmaugPool]

Thank you very much @lidel, I added http://localhost:* and http://127.0.0.1:* in CSP rules and it seems to work fine now.