znc
znc copied to clipboard
HTTP Basic Auth & Webadmin & Reverse proxy
OS: Debian Jessie (8.5) ZNC: v1.6.3
When access to the Webadmin interface is restricted using HTTP Basic Auth (BA), a successful sign in with credentials matching those for a user account in Webadmin results in bypassing of the normal username and password login required by the interface. Use of BA credentials that don't match any credentials of those in the Webadmin module results in a failed login.
In the event that the BA credentials are incorrect, the 401 page is handled by the webserver (e.g. nginx). If the credentials are correct but don't match any Webadmin credentials, the 401 Unauthorized page is presented by ZNC, which suggests that this might be an intended feature. I've included screenshots below simply for illustration's sake.
Incorrect BA credentials
Correct BA credentials that don't match any Webadmin credentials
I'm not certain whether this qualifies as a bug or not but this doesn't seem like the intended outcome. Perhaps there should be explicit entry in the ZNC configuration file that enables Webadmin's handling of BA headers, as it should be possible to use different credentials for the BA login and the Webadmin login.
Call me lazy, but can't you somehow tell nginx not to pass in the BA headers?
Logging in in this way is helpful e.g. for scripts trying to access the web interface (and no, I don't think that the current state of webadmin makes this easy, something a bit more RESTy might be needed).
I hadn't considered that. Added proxy_set_header Authorization "";
to the nginx config. That's solved the issue at least.
Thanks for the advice.
I didn't have time to properly test this before I closed the issue. It turns out stripping the Authorization header makes it impossible to log into the ZNC webadmin interface; which I suppose it to be expected. For now, I've just disabled the use of Basic Auth. It seems like separating the handling of BA credentials from ZNC would be the best solution but that would obviously impair scripting unless a RESTful option appears.
Just stumbled on this issue. I'm using basic authentication (BA) with nginx as well, with webadmin as a subdirectory as described here. If the BA user/password match a user in ZNC, no problem; if I declare
proxy_set_header Authorization "";
as part of the ZNC webadmin location block in the nginx configuration no problem as well. However, neither is the "normal" use case. ZNC has a user which is discrete from the BA dictionary; as such, I get lots of 401 and 009 lines in the access log (and eventually a timeout).
Any thoughts on improving how webadmin handles BA, or a more secure approach than disabling authentication for that location block?
I did not have any problem logging into webadmin with the Authorization header blanked out. The issue may have been fixed by now.
Here's my full server block config:
# ZNC is running in a docker container with port 6697 attached to 26697 on host machine.
# Webadmin will be accessible on https://znc.example.com
server {
listen 443 ssl;
server_name znc.example.com;
ssl_certificate fullchain.pem;
ssl_certificate_key privkey.pem;
ssl_protocols TLSv1.2;
ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
client_max_body_size 0;
chunked_transfer_encoding on;
location / {
auth_basic "ZNC reverse proxy";
auth_basic_user_file znc.htpasswd;
proxy_set_header Authorization "";
proxy_pass https://[::1]:26697;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
For the ZNC config, I used makeconfig with the following options and did not change any config files after:
[ ** ] -- Global settings --
[ ?? ] Listen on port (1025 to 65534): 6697
[ ?? ] Proceed anyway? (yes/no) [yes]: yes
[ ?? ] Listen using SSL (yes/no) [no]: yes
[ ?? ] Listen using both IPv4 and IPv6 (yes/no) [yes]: yes
[ ?? ] Set up a network? (yes/no) [yes]: no
Hope this helped.