Mixed Content https error

[TadeSF]

Hey there,

I wanted to configure this very nice app for my non-profit as a way of sharing data in order to achieve the EUs DSGVO requirements and everything looked very promising.

However, I stumbled across an issue that I could not solve yet – and I was wondering if you could help. The main page is working in order, but when I click on "Create a new upload bundle", I get this Mixed Content error:

Mixed Content: The page at 'https://files.redacted.de/' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://files.redacted.de/new'. This request has been blocked; the content must be served over HTTPS.

I configured the container with a traefik proxy. My docker-compose.yml looks like this:

version: '3'
services:
  app:
    image: axeloz/filesharing:latest
    environment:
      APP_NAME: "redacted Filesharing"
      APP_URL: "https://files.redacted.de"
      UPLOAD_MAX_FILESIZE: "1G"
      UPLOAD_MAX_FILES: "100"
      HASH_MAX_FILESIZE: "1G"
      LIMIT_DOWNLOAD_RATE: "1M"
    volumes:
      - ${PERSISTED}:/app/storage/content
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.filesharing.rule=Host(`files.redacted.de`)"
      - "traefik.http.routers.filesharing.entrypoints=websecure"
      - "traefik.http.routers.filesharing.tls.certresolver=myresolver"

      - "traefik.http.routers.filesharing-upload.rule=Host(`files.redacted.de`) && (PathPrefix(`/new`) || PathPrefix(`/upload`))"
      - "traefik.http.routers.filesharing-upload.entrypoints=websecure"
      - "traefik.http.routers.filesharing-upload.tls.certresolver=myresolver"
      - "traefik.http.routers.filesharing-upload.middlewares=redacted@docker"

    networks:
      - traefik

networks:
  traefik:
    external: true

Do you have any Idea what could be causing this? I already skimmed through the codebase and did not find any hardcoded http links, that could cause this – and it seems to work very well in your demo app...

Note: The extra traefik auth middleware for the /new and /upload is not causing this to happen, I already tried with having it removed.

All the best and many thanks, Tade

[axeloz]

Hi @TadeSF,

I committed two days ago this fix: https://github.com/axeloz/filesharing/commit/2fdca6b0c730c0ea8f0f6ebe5d8e2b55a7392e02 I don't know traefik but your proxy must send the HTTP_X_FORWARDED_PROTO=https header to the Docker. I use this value to make sure that SSL is used internally.

https://doc.traefik.io/traefik/middlewares/http/headers/

Let me know

Axel

[TadeSF]

Hmm, thanks first of all for the input, this seems to be the right track. But I have been trying and bugfixing for the last hour and I still get the error, even with different approaches telling traefik to send add the header. In the end, I configured a whoami container to give me exact response what the filesharing app is recieving and I must say I am a little confused by the output, because judging from the whoami output everything seems in order.

Here is my new docker-compose configuration with the /whoami path:

version: '3'
services:
  app:
    image: axeloz/filesharing:latest
    environment:
      APP_NAME: "redacted Filesharing"
      APP_URL: "https://files.redacted.de"
      UPLOAD_MAX_FILESIZE: "1G"
      UPLOAD_MAX_FILES: "100"
      HASH_MAX_FILESIZE: "1G"
      LIMIT_DOWNLOAD_RATE: "1M"
    volumes:
      - ${PERSISTED}:/app/storage/content
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.filesharing.rule=Host(`files.redacted.de`)"
      - "traefik.http.routers.filesharing.entrypoints=websecure"
      - "traefik.http.routers.filesharing.tls.certresolver=myresolver"
      - "traefik.http.routers.filesharing.middlewares=sslheader@docker"

      - "traefik.http.routers.filesharing-upload.rule=Host(`files.redacted.de`) && (PathPrefix(`/new`) || PathPrefix(`/upload`))"
      - "traefik.http.routers.filesharing-upload.entrypoints=websecure"
      - "traefik.http.routers.filesharing-upload.tls.certresolver=myresolver"
      - "traefik.http.routers.filesharing-upload.middlewares=redacted@docker, sslheader@docker"

      - "traefik.http.middlewares.sslheader.headers.sslProxyHeaders.X-Forwarded-Proto=https"

    networks:
      - traefik

  whoami:
    image: traefik/whoami

    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.files-whoami.rule=Host(`files.redacted.de`) && Path(`/whoami`)"
      - "traefik.http.routers.files-whoami.entrypoints=websecure"
      - "traefik.http.routers.files-whoami.tls.certresolver=myresolver"
      - "traefik.http.routers.files-whoami.middlewares=sslheader@docker"

    networks:
      - traefik

networks:
  traefik:
    external: true

And here is the important part of the whoami file:

GET /whoami HTTP/1.1
Host: files.redacted.de
[...]
Cf-Visitor: {"scheme":"https"}
[...]
X-Forwarded-For: x.x.x.x (redacted)
X-Forwarded-Host: files.redacted.de
X-Forwarded-Port: 443
X-Forwarded-Proto: https
X-Forwarded-Server: fdc551514f42
X-Real-Ip: x.x.x.x (redacted)

Seeing this, I suspect the fileshare app is not processing the X-Forwarded-Proto: https correctly, even though traefik is supplying it.

---

To be fair, we are now on territory that is far out of my comfort-zone, since neither proxies and their header configuration nor php-apps are in any way my area of expertise. But looking at the commit you mentioned, is it at all possible that this is just a simple capslock-comparison issue? Traefik seems to provide the Header always like this X-Forwarded-Proto and it does not seem to make a difference if I edit the docker-compose file with caps in the middleware line. Maybe that causes the php-app to not recognize the header as present?

[axeloz]

Ok, I'm gonna have to do some testing then. The demo here https://filesharing.box.webinno.fr/ is powered by Docker and I'm using the latest version. SSL is enabled, my Nginx proxy sends the X-Forwarded-Proto among the request and I don't have mixed content issues.

But actually, you shouldn't have to add your own header as traefik does it for your : https://doc.traefik.io/traefik/getting-started/faq/#what-are-the-forwarded-headers-when-proxying-http-requests

Are you sure you pulled the latest version of Filesharing from Docker hub? https://hub.docker.com/r/axeloz/filesharing

[TadeSF]

Yeah thats why I was confused, I didn't have any proxy header issues with any other selfhosted app before...

I set the services up yesterday (Wednesday, Jan 11) and the :latest image from docker hub is from 5 days ago (06d6a917ec63). So unless smth funny happened to the tags, I should have pulled the image that you are referring to.

If I can help/assist in any way or if you need more specific information, please let me know!