Your message dated Tue, 25 Aug 2015 18:52:30 +0300
with message-id <[email protected]>
and subject line Re: Bug#792466: nginx-extras: auth_pam fails to require
authentication
has caused the Debian Bug report #792466,
regarding nginx-extras: auth_pam fails to require authentication
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
792466: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792466
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: nginx-extras
Version: 1.6.2-5
Severity: normal
Dear Maintainer,
* What led up to the situation?
I recently upgraded to debian 8 and, after doing so, realized that auth_pam in
nginx no longer
prompted me for a password to edit my internal wiki. I noticed that auth_pam
appears to have
been moved to nginx-extras, so I installed that (replacing nginx-full) but the
problem persists.
* What exactly did you do (or not do) that was effective (or
ineffective)?
I've checked my config, and can't find anything wrong with it. I've added
allow/deny rules for
the time being, and those have successfully isolated access to my IP for now.
I thought that perhaps the default for auth_pam_service_name had changed, so I
set it explicitly,
but to no avail.
ldd reveals that nginx *is* linked against pam. nginx -V reveals
--add-module=/tmp/buildd/nginx-1.6.2/debian/modules/nginx-auth-pam
* What was the outcome of this action?
Navigating to a path protected by this config:
location /auth
{
auth_pam "example.net";
auth_pam_service_name "nginx";
include fastcgi_params;
fastcgi_pass unix:/var/run/fcgiwrap.socket;
fastcgi_index ikiwiki.cgi;
fastcgi_param REMOTE_USER $remote_user;
}
Does not prompt for any username or password.
* What outcome did you expect instead?
I expect it to prompt for a username and password.
-- System Information:
Debian Release: 8.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.0.1-x86_64-linode55 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages nginx-extras depends on:
ii libc6 2.19-18
ii libexpat1 2.1.0-6+b3
ii libgd3 2.1.0-5
ii libgeoip1 1.6.2-4
ii libluajit-5.1-2 2.0.3+dfsg-3
ii libpam0g 1.1.8-3.1
ii libpcre3 2:8.35-3.3
ii libperl5.20 5.20.2-3+deb8u1
ii libssl1.0.0 1.0.1k-3+deb8u1
ii libxml2 2.9.1+dfsg1-5
ii libxslt1.1 1.1.28-2+b2
ii nginx-common 1.6.2-5
ii perl 5.20.2-3+deb8u1
ii perl-base [perlapi-5.20.1] 5.20.2-3+deb8u1
ii zlib1g 1:1.2.8.dfsg-2+b1
nginx-extras recommends no packages.
Versions of packages nginx-extras suggests:
pn nginx-doc <none>
-- no debconf information
--- End Message ---
--- Begin Message ---
On Sun, Jul 26, 2015 at 12:29:34AM -0600, Jonathon Anderson wrote:
I owe you guys an apology. Turns out that Apple Safari, when a basic
auth password is saved in the keychain, doesn't even prompt you to
send your saved password; it just sends it automatically. So I didn't
see an authentication prompt because safari was silently
authenticating on my behalf. :/
Your advice to check auth.log was spot on, and I don't know how I
missed it before. (It was pretty late, so I'll blame it on lack of
sleep.) Seeing that successful authentication was happening
behind-the-scenes led me to track down where the invisible
authentication credentials were coming from.
Thanks for your help.
~jonathon
No problem :)
Closing the bug.
--- End Message ---
