-
Notifications
You must be signed in to change notification settings - Fork 115
Description
Description
In QuickBox Lite nginx app configs (e.g. /etc/nginx/apps/deluge.conf), the following directive is used:
nginx
auth_basic_user_file /etc/htpasswd.d/htpasswd.$remote_user;
This configuration causes a 403 Forbidden response before the Basic Auth challenge is shown.
Root Cause
In nginx, $remote_user is only set after successful Basic Authentication.
However, auth_basic_user_file must be resolved before authentication starts, so when a client first accesses the location:
$remote_user is empty
nginx attempts to read /etc/htpasswd.d/htpasswd.
the file does not exist
nginx returns 403 Forbidden without prompting for credentials
This creates a logical deadlock: authentication cannot start because the password file path depends on a variable that only exists after authentication.
How to Reproduce
1.Fresh QuickBox Lite install
2./etc/htpasswd.d/ contains user-specific files, e.g.:
/etc/htpasswd.d/htpasswd.
3.Access an application endpoint such as:
https:///deluge/
4.Result: 403 Forbidden instead of a 401 Basic Auth prompt
Expected Behavior
nginx should respond with 401 Unauthorized
browser should prompt for Basic Auth credentials
Actual Behavior
nginx responds with 403 Forbidden
no authentication prompt is shown
###Suggested Fix
Use a static htpasswd file path instead of $remote_user, for example:
auth_basic_user_file /etc/htpasswd.d/htpasswd;
or explicitly reference a known existing file, e.g.:
auth_basic_user_file /etc/htpasswd.d/htpasswd.;
If per-user separation is required, it should be handled via vhosts or application-level logic, not $remote_user inside auth_basic_user_file.
###Environment
OS: Ubuntu 24.04 noble
nginx: nginx/1.24.0 (Ubuntu)
QuickBox Lite: 1.5.11
###Notes
This is not a configuration mistake by the user, but a design issue caused by using an authentication-dependent variable in a pre-auth directive.