Another v2 BasicAuth Bug?

[Brando56894 (Brandon Golway)]

Edit: It’s a problem with compose itself and I haven’t found a fix for it, but a workaround is to just put something like “123” in value for the caddy.basicauth.username key and once the container is created you can edit the label via portainer to enter in the real hash and recreate the container which will allow it to work properly.

1. The problem I’m having:

I’m trying to use the caddy.basicauth.username label to set my password but it keeps interpreting part of the hash as a variable.

2. Error messages and/or full log output:

 [bran@server admin]$ docker compose up -d
WARN[0000] The "P16" variable is not set. Defaulting to a blank string. 

3. Caddy version:

v2.7.6 h1:w0NymbG2m9PcvKWsrXO6EEkY9Ru4FJK8uQbYcev1p3A=

4. How I installed and ran Caddy:

a. System environment:

Arch Linux x86_64 via docker-compose 2.27.0

b. Command:

not sure if this is relevant since it’s docker, but I’m leaving everything in place as requested

docker-proxy

c. Service/unit/compose file:

include:
  - ../networks.yml

services:
  caddy:
    image: 'homeall/caddy-reverse-proxy-cloudflare:latest'
    container_name: caddy
    ports:
      - '192.168.1.7:80:80'
      - '192.168.1.7:443:443'
    environment:
      - TZ=America/New_York
      - CLOUDFLARE_EMAIL=my-email@igetenoughspam.com
      - CLOUDFLARE_API_TOKEN=<redacted>
      - ACME_TRUE=true
    labels:
      caddy.log.output: file /logs/caddy.log
    networks:
      - web
    restart: always
    cap_add:
      - NET_ADMIN
    volumes:
      - '/var/run/docker.sock:/var/run/docker.sock'
      - '/opt/docker-data/caddy/data:/data/caddy'
      - '/opt/docker-data/caddy/config:/config/caddy'
      - '/opt/docker-data/caddy/logs:/logs'

d. My complete Caddy config:

{
        log {
                output file /logs/caddy.log
        }
}

netdata.mydomain.us {
        basicauth * {
                bran $2a$14.pEbSLwIQYr7p0TAKQJZebe9XopaJrPG
        }
        reverse_proxy 172.20.0.4:19999
        tls {
                dns cloudflare <redacted>
                resolvers 1.1.1.1
        }
}

I think it may be an issue with CDP parsing the labels because if I just use the regular Caddy container with the following config it works as expected.

netdata.brandongolway.us {
        basicauth * {
                bran $2a$14$q/SP77544d8N0YdwQ6eue.F8Reyq66HS/cKWkOlF6BafbD9IX22eO
        }
        reverse_proxy netdata:19999
}

5. Links to relevant resources:

homeall/caddy-reverse-proxy-cloudflare (it’s CDP built with the Cloudflare DNS module)

lucaslorentz/caddy-docker-proxy

[francislavoie]

@Brando56894

I think it may be an issue with CDP parsing the labels

Yep, you probably need to escape the $ with \ because those are parsed as being variables otherwise, by the Docker stuff. Not a Caddy bug.

Notice in the hash, you have $q. You’d need to change it to \$q probably.

[Brando56894 (Brandon Golway)]

Thanks, I figured it was probably an issue with escaping

edit: Apparently escape sequences aren’t defined in YAML but they are in JSON…but $ isn’t one of them…so I’m back at square one since this a problem with JSON itself. Netdata can just be internal then since there seems to be no way around this except for attempting to get a hash which doesn’t contain $. I found a site that produces escaped JSON for you, it put a \ before the $p16…but compose still parses it as a variable!

Edit 2: It appears that Portainer has gotten around it somehow because if I paste the hash into the proper field and recreate the container I have no issues bringing up the container or logging in, so that’s a nice workaround.

It turns out that error in the Caddy log about a / was unrelated to netdata, I had a syntax error in my Plex directive for caddy.reverseproxy I set the value to {{ upstreams 32400/web }} and it didn’t like the /web portion. I actually just removed the Caddy labels for Plex, since it doesn’t really need to be exposed to the web anyway since it phones home and you can access it from plex.tv