Issue http auth when using new CTFd version

[tnmch]

When you configure apache or nginx as a reverse proxy and configure http authentication, the pop-up window will be asked again each time the full path changes.

Exp: after having already passed http authentication and connected to CTFd

• 127.0.0.1/ : no new http authentication appears
• 127.0.0.1/admin : display again and request the login / password (http auth)

probably the CTFd is cleaning up the request somewhere and the HTTP authorization has just been removed from path request to another new path

Config :

• REVERSE_PROXY=true
• Nginx is running on the host ( removed Nginx container from docker-compose.yml)

[ColdHeat]

Basic auth isn't built into CTFd unless you're referring to something else? There hasn't been much changes to how CTFd processes requests but perhaps there is an upstream change in Flask that changed something.

You'll need to provide more details since this sounds like a feature that's not built into CTFd and seems like it's more related to your custom code/deployment.

Also if basic auth is configured at the reverse proxy level, CTFd shouldn't even get the request.

[tnmch]

There is no much code/deployment difference comparing to the main code

server {
    listen 80 default_server;
    server_name example.com;
    return 301 https://$host$request_uri;
}

server {
       server_name example.com;

       location / {
          auth_basic           “Authentication”;
          auth_basic_user_file /etc/apache2/.htpasswd;
          proxy_pass http://127.0.0.1:8000/;
          proxy_set_header X-Real-IP $remote_addr;
          proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
          proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto;
          proxy_set_header Host $host;
       }

       listen [::]:443 ssl ipv6only=on;
       listen 443 ssl;
       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

}

Where certbot certonly --nginx is used to setup HTTPS certificate

[ColdHeat]

So what's implementing basic auth here? Or am I misunderstanding the issue?

[tnmch]

Sorry, I did not notice that I just copied the wrong configuration file, I just updated my comment

[tnmch]

Any update on this ?

[ColdHeat]

I don't really think this is a CTFd issue. Can you root cause what the issue is? Perhaps it's related to configuration on your reverse proxy.

[packetgeek]

Solved this for my Apache2 reverse proxy by adding the following to the Directory statement which protects the folder declared as DocumentRoot:

AllowOverride AuthConfig
Order allow,deny
Allow from all
Options -Indexes

This allows for a single authentication for the entire site. This doesn't provide authentication to CTFd, but does prevent having to re-authenticate to the reverse proxy when changing paths in CTFd (still on my wish list: CTFd authentication tied to external authentication). Of course, you have to explicitly prevent users from accessing parts of the site they shouldn't be allowed, but you should be doing that already ("require user bob", etc.). Adding the AuthConfig override also appears to clear up my issue with the commercial plugins from CTFd.io.

Not sure what the Nginx equivalent is, but it shouldn't require much research. Note: I'm using CTFd v2.5.0.

[tnmch]

Thank you @packetgeek , should you use .htaccess file which does not work with apache as proxy when using ProxyPass ?

   ProxyPass / http://127.0.0.1:8000/
   ProxyPassReverse / http://127.0.0.1:8000/

[packetgeek]

@tmnch - Unknown. I use the ProxyPass statements in the "Location" directives, all of which are in the Apache vhosts configuration file. It routes to a number of services (VMs and Docker containers) which aren't local to the reverse proxy, including CTFd.

I actually "borrowed" the "AllowOverride AuthConfig" line from a post where it was used in an .htaccess file.