Incorrect Content Security Directive

[jsemrau]

Observed behaviour:

When running a bitclout node on a custom domain with a custom Caddyfile the wrong content security is propagated to the front end. That leads to the front-end site not being able to access the API even though API access without the front-end is possible.
The error message in the browser reads "Refused to connect to "" because it violates the following Content Security Policy directive: "connect-src 'self' [...several URLs's listed - origin of the URLs is not from my Caddyfile ...]

Expected behaviour:

The front-end uses the URLs listed in the Caddyfile on the server and gives access to resources in the backend.

[tijno]

Could you show an example of whats in your caddy file and how it comes through in browser? Ive not seen this in my node with custom domain.

[jsemrau]

Mine looks like this
{
admin off
auto_https off
}

:8080 {
file_server
try_files {path} index.html

header Access-Control-Allow-Methods "GET, PUT, POST, DELETE, OPTIONS"
header Access-Control-Allow-Origin "*"
header Content-Security-Policy "
  default-src 'self';
  connect-src 'self'
    api.finclout.io:*
    finclout.io:*
    localhost:*
    api.bitclout.com bitclout.com:*
    explorer.bitclout.com:*
    https://blockchain.info/ticker
    api.blockchain.info/mempool/fees
    https://ka-f.fontawesome.com/
    bitcoinfees.earn.com
    api.blockcypher.com
    amp.bitclout.com
    api.bitclout.green api.bitclout.blue
    api.bitclout.navy;
  script-src 'self' https://cdn.jsdelivr.net/npm/sweetalert2@10
    https://kit.fontawesome.com/070ca4195b.js https://ka-f.fontawesome.com/;
  style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;
  img-src 'self' data: i.imgur.com images.bitclout.com;
  font-src 'self' https://fonts.googleapis.com
    https://fonts.gstatic.com https://ka-f.fontawesome.com;
  frame-src 'self' localhost:*
    identity.bitclout.com identity.bitclout.blue identity.bitclout.green;"

}

[jsemrau]

Yet, this is the list that I get . It's quite different.

refused to connect to '' because it violates the following Content Security Policy directive: "connect-src 'self' api.bitclout.com api.bitpop.dev bitpop.cash:* bitclout.fun:* api.bitclout.me:* bitclout.me:* localhost:* bitclout.com:* 192.168.0.176:*
megamoons.com:* explorer.bitclout.com:*
imgur-apiv3.p.rapidapi.com api.imgur.com bitcoinfees.earn.com api.blockchain.info/mempool/fees api.blockcypher.com amp.bitclout.com api.bitclout.green api.bitclout.blue api.bitclout.navy youtube.com".

[tijno]

Actually I just noticed mine has the issue now too.

I pulled the latest images and seems there is a massive variance between the Caddy file and whats shown in the browser.

[tijno]

Looks like the Caddyfile in the container is called Caddyfile instead of Caddyfile.dev

Logs show Loading Caddy config from file: /app/Caddyfile.dev

[tijno]

Ok so adding your domain to Caddyfile.dev is in the HTTP header, but not in the HTML meta tag. I guess the html meta tags takes priority. If I manually edit the index.html file in the container and add my domain to the html meta tag it all works fine.

Also removing the whole <meta http-equiv="Content-Security-Policy" content="*"> tag from the container index.html fixes it - as the header provided by Caddy (and the Caddyfile.dev) takes over,

[jsemrau]

The proposed work-around from my side is to edit the docker-compose.dev.yml
and replace ghcr.io/bitclout/frontend:latest with ghcr.io/bitclout/frontend:9f196757557ac9c1eb696cb3d471c12a1d5a9e40
like this :

frontend:
container_name: frontend
image: ghcr.io/bitclout/frontend:9f196757557ac9c1eb696cb3d471c12a1d5a9e40

Then refresh docker:
sudo docker-compose -f docker-compose.dev.yml up -d

[maebeam]

Hey all, apologies, a merge conflict re-added the CSP to the HTML when it should only exist in the Caddyfile. If you pull the latest frontend image the HTML CSP will no longer be an issue.

Thanks for reporting!