SteveLTN / https-portal

A fully automated HTTPS server powered by Nginx, Let's Encrypt and Docker.
MIT License
4.41k stars 295 forks source link

Problem enabling basic auth. permission issue in default config? #348

Open cocoonkid opened 5 months ago

cocoonkid commented 5 months ago

gitlab-https-portal-1 | 2024/01/16 14:04:27 [crit] 319#319: *14 open() "/var/lib/https-portal/git.mypage.com/production/htaccess" failed (13: Permission denied), client: xxx.xxx.xxx, server: git.mypage.com, request: "GET / HTTP/2.0", host: "git.mypage.com"

Running into this as soon as I enable basic auth.

here is my compose:


    image: steveltn/https-portal
    restart: unless-stopped
    networks:
      - https-portal
    ports:
      - 0.0.0.0:80:80
      - 0.0.0.0:443:443
    environment:
      - 'DOMAINS=admin:abbbcccddF$*2T@git.mypage.com-> http://gitlab:80'
      - 'STAGE=production'
      - 'NUMBITS=4096'```

When I disable basic auth I can access the site.
SteveLTN commented 5 months ago

Hi!

I looked into it. There were 2 causes actually:

  1. docker-compose interpolates $variable. And you $ in your password triggers it.
  2. The internal command I use in HTTPS-PORTAL also does the interpolation. I released 1.23.1 to fix it.

In order to make it work, you need to:

  1. Update to HTTPS-PORTAL 1.23.1
  2. Use $$ instead of $ in your password to skip interpolation. (There will be still only one $ in your password). Or just don't use $ in password.

Thanks!

cocoonkid commented 5 months ago

Thanks so much for the swift response. Yes of course the damn $. Forgot that one hehe. And in my template it's already taken care of. Copy Paste is a skill lol

Just tested and works like a charm now!

I am just using a bind mount in the ./ so what permission would now be necessary to fix this following ?:

var/lib/https-portal/git.website.com/production/htaccess" failed (13: Permission denied)

Thanks so much for taking the time !

cocoonkid commented 5 months ago

Inside the https-portal container I tried in /var/lib/https-portal/git.website.com/production/ chown -R 13.13 htaccess # proxy chown -R 101.101 htaccess # nginx chown -R 0.0 htaccess #root

but for some reason I still get the permission denied. I restarted the container everytime as well to be sure.

Also tried to create it manually with htpasswd -c htaccess admin

https-portal:  
    image: steveltn/https-portal
    restart: unless-stopped
    networks:
      - https-portal
    ports:
      - 0.0.0.0:80:80
      - 0.0.0.0:443:443
    environment:
      - 'DOMAINS=admin:Carrf@git.website.com-> http://gitlab:80'
      - 'STAGE=production'
      - 'NUMBITS=4096'
    volumes:
      - ./certs:/var/lib/https-portal
      - ./htaccess:/var/lib/https-portal/git.website.com/production/

image

cocoonkid commented 5 months ago

@SteveLTN I have over the the last week configured multiple containers but none of them works with basic auth.

I get the permission denied on all of them and I really tried a lot :-)

I am quite an experienced docker user but I am not able to solve this so far.

 https-portal:
    image: steveltn/https-portal:latest
    ports:
      - '80:80'
      - '443:443'
    environment:
      DOMAINS: 'user:Carraf@recon.fun.lol-> http://web:8000'
      STAGE: production
      NUMBITS: 4096
      CUSTOM_NGINX_SERVER_CONFIG_BLOCK: |
        location /staticfiles/ {
          alias /usr/src/app/staticfiles/;
        }
    volumes:
      - ./certs:/var/lib/https-portal
      - ./vhosts:/var/www/vhosts
      - ./static_volume:/usr/src/app/staticfiles/

I also tried just not mounting the htaccess at all which should work immediately.

The file exists, the basic auth login appears but as soon as I enter the correct credentials the "permission denied" happens serverside in the logs.

I also checked the content and it looks ok.

chmod 644 on the htaccess and 755 on the folder itself did not help either.

SteveLTN commented 5 months ago

I think the .htaccess permission is somewhat related to mounting the external file. You probably need to play around with the file permissions.

For when you do not do not mount external .htaccess, it is likely due to some interpolation. Try to add environment variable DEBUG=true, and look at the logs. It should print what password was extracted from ENV.

cocoonkid commented 3 months ago

I have added

environment:
  DEBUG: true

  nothing changed in the output  of  the  https-portal  log. 

I tried chmod 777 on htaccess and the production folder.

also chown 33:33 (www-data) chown 101:101 (nginx) chown 13:13 (proxy)

still :

https-portal-1 | 2024/03/17 20:10:12 [crit] 322#322: *2 open() "/var/lib/https-portal/oob.example.lol/production/htaccess" failed (13: Permission denied), client: 146.70.117.214, server: oob.example.lol, request: "GET / HTTP/2.0", host: "oob.example.lol", referrer: "https://oob.example.lol/"

I made sure to recreate the container everytime.

This issues persists and I beg you to take another look.

Usually these permission issues are really easy to fix. I never encountered such hardship before (in dockerland.)

Thanks so much for taking the time @SteveLTN

cocoonkid commented 3 months ago

I went with a named volume now and it works.
checked the permissions -> -rw-r--r-- 1 root root 44 Mar 17 20:25 htaccess

this is really the weirdest issue I've encountered in a while :-)

Can you even reproduce it when using a bind mount?