Caddy basicauth behaving differently than nginx. Any pointers?

Help
1

1. The problem I’m having:

Hi. So this is my first time messing around with both Nginx and Caddy so please forgive me if this is a dumb question.

I have a supabase setup that uses docker with multiple containers and an webpage that allows me to view my database. I want this page to have basicauth. The nginx config that I have works fine in terms of requiring a password when visiting the site. Caddy requires a password but it also blocks request between the site and the server even though the site is hosted from the server.

Can anyone explain where my logic is flawed or point me in the right direction? I want to understand what’s going on. I’m guessing there’s something extra Caddy or Nginx is doing behind the scenes like blocking or allowing internal requests with basicauth?

Caddyfile

https://example.com {
        reverse_proxy /rest/v1/* localhost:8000
        reverse_proxy /auth/v1/* localhost:8000
        reverse_proxy /realtime/v1/* localhost:8000
        reverse_proxy /storage/v1/* localhost:8000
        reverse_proxy * localhost:3000

        basicauth /* {
               admin <HASH generated from caddy hash-passwrd>
        }
}

Nginx config

map $http_upgrade $connection_upgrade {
    default upgrade;
    '' close;
}

upstream supabase {
    server localhost:3000;
}

upstream kong {
    server localhost:8000;
}

server {
    server_name example.com;

    # REST
    location ~ ^/rest/v1/(.*)$ {
        proxy_set_header Host $host;
        proxy_pass http://kong;
        proxy_redirect off;
    }

    # AUTH
    location ~ ^/auth/v1/(.*)$ {
        proxy_set_header Host $host;
        proxy_pass http://kong;
        proxy_redirect off;
    }

    # REALTIME
    location ~ ^/realtime/v1/(.*)$ {
        proxy_redirect off;
        proxy_pass http://kong;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Host $host;
    }

    # STORAGE
    location ~ ^/storage/v1/(.*)$ {
        proxy_set_header Host $host;
        proxy_pass http://kong;
        proxy_redirect off;
    }

    # STUDIO
    location / {
        proxy_set_header Host $host;
        proxy_pass http://supabase;
        proxy_redirect off;
        proxy_set_header Upgrade $http_upgrade;

        auth_basic           "Administrator’s Area";
        auth_basic_user_file /etc/apache2/.htpasswd;
    }

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}



server {
    if ($host = example.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    listen 80;
    server_name example.com;
    return 404; # managed by Certbot


}

2. Error messages and/or full log output:

Requests made to /rest/v1/ come back with 401 error. If I turn off basicauth, all is fine.

3. Caddy version:

2.6.4

4. How I installed and ran Caddy:

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

a. System environment:

Unbuntu 22.04

b. Command to start caddy:

sudo systemctl restart caddy

5. Links to relevant resources:

2

I don’t understand what you mean here. What’s your evidence that Caddy is “blocking” the request?

Can you rephrase this? What’s your evidence? What does it look like when you make a request with curl -v -u'admin:password' https://example.com?

Oh, do you mean that you want basicauth to happen only for paths that aren’t configured with reverse_proxy?

What you’d want to do then is use handle blocks to set up mutually exclusive routes, similar to your nginx config.

example.com {
	@api path /rest/v1/* /auth/v1/* /realtime/v1/* /storage/v1/*
	handle @api {
		reverse_proxy localhost:8000
	}

	handle {
		basicauth {
			admin <hash>
		}
		reverse_proxy localhost:3000
	}
}

Refer to the docs to learn how that works. Read about request matchers, and the handle directive.

3

Thanks Francis! This is exactly what I was trying to achieve. I tried putting basicauth under localhost:3000 and got a unrecognized subdirective basicauth error but using handle blocks makes a ton of sense. Caddy’s pretty clean! I appreciate your help. Have a great week!

1 Like
4

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.