On 29/12/13 14:10, Kevin O'Gorman wrote: > On Sat, Dec 28, 2013 at 4:28 PM, > <[email protected]> wrote: > >> Date: Sun, 29 Dec 2013 06:36:23 +1100 >> From: Scott Ferguson <[email protected]> >> To: [email protected] >> Subject: Re: Upgraded apache 2.2 -> 2.4 and cannot get passwords to work >> Message-ID: <[email protected]> >> Content-Type: text/plain; charset=UTF-8 >> Content-Transfer-Encoding: 7bit >> >> On 29/12/13 03:52, Dave Woyciesjes wrote: >>> On 12/28/2013 11:09 AM, Kevin O'Gorman wrote: >>>> My modest-sized web server was recently upgraded. There were problems >>>> with access control, fairly well documented and fairly easily fixed. >>>> >>>> Authentication, on the other hand, acts as if it's not there -- anyone >>>> and everyone is let into the few parts that used to be controlled. So >>>> I have them offline for now. I don't see any writeups of problems >>>> with this, so perhaps the way I solved access control borked the >>>> authentication. >>>> >>>> I have everything in /var/www and /www, and the authenticated parts >>>> are in /www, with a Directory stanza containing authentication info >>>> for each of the two (but apache is apparently ignoring them). I don't >>>> have /srv.
>>>> Authentication is by a simple text file with less than 100 entries. Handy because mod_auth_file usually dies before it'll process more than 100 users in a file (that's what the auth_db mods are for) <snipped> >> >> Please expand on your authentication system and the problems plus error >> messages. Your authentication scheme seems to be .htaccess, type=basic, provider=file, authorization=unknown Please post the output of:- $ dpkg --get-selections | grep _mod >> >> Kind regards >> > > There are about a dozen directories, I won't mention them all, but > here's the general pattern. > Consider these aliases > > #Alias /theory /www/theory > Alias /hex /www/web > Alias /Chocoholic /www/Chocoholic > Alias /Games /www/Games > (and more in a similar vein) > > The theory one is commented out for now because the authentication > does not work: it's as if the authentication is not even mentioned and > access goes smoothly for everyone. The uncommented ones do not have > authentication, so they work as-is. > > /www contains the stuff where the problem is. It's enabled by this stanza: > <Directory /www> > AllowOverride FileInfo AuthConfig Limit Indexes > Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec > <Limit GET POST OPTIONS> > Require all granted > </Limit> > <LimitExcept GET POST OPTIONS> > Require all denied > </LimitExcept> > </Directory> > > It has a subdirectory where I share stuff with some collaborators, and > where I want to authenticate those collaborators: > <Directory /www/theory> > AuthType Basic NOTE: Basic sends passwds *un*encrypted. I'm assuming you have mod_ssl installed and configured. mod_digest doesn't have that problem. basic also dies a slow death if fed more than a hundred or so users in a file. Check that you have the following installed and enabled:- mod_auth_basic mod_authn_file an authorization module (i.e. mod_authnz_ldap or mod_authz_$something) > AuthName "OHex Advanced" > AuthBasicProvider file > AuthUserFile /etc/apache2/hextheory-passwords I'm guessing the path and permissions are correct for the users file. Check the format is correct. Each line has:- $username; $encrypted password. NOTES:- ;mod_authn_file will use the first instance of a given username's password (this prevents realm insanity) ;use htpasswd to encrypt the passwords if you are *not* using mod_auth_basic, if you are using mod_auth_digest instead you'll need to reflect it in authentication and use htdigest to encrypt the passwords instead. (I've not tried to use both). ;AuthUserFile is overridden by AuthConfig > AuthGroupFile /dev/null Huh? I thought anyone in the groupfile had to also be in the password file or auth would fail. With nothing in the group file..... :/ You'll also need mod_authz_groupfile installed and enabled. > Require valid-user This line makes the preceding line redundant. If you are *not* using groups I'd suggest you comment out AuthGroupFile > AllowOverride FileInfo AuthConfig Limit Indexes > Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec > <Limit GET POST OPTIONS> > Require all granted The above lines stop POST but allow everything else ( GET, POST, PUT, DELETE, CONNECT, PATCH, PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, and UNLOCK). Is that what you wanted? > </Limit> > <LimitExcept GET POST OPTIONS> > Require all denied I suspect that directive won't work.... > </LimitExcept> > </Directory> > > > So: what can I do to have authentication work again as it did in apache 2.4? > > > Hmm, that was poorly put. Let's try this: > So: what can I do to have authentication work in apache 2.4 as it once > did in apache 2.2? /var/log/apache2/error.log could be helpful - you should have got some errors when you were trying to use .htaccess authentication, if not set loglevel to alert and renable authentication. If you enable mod_dumpio (and set the directive "DumpIOOutput On") you can get everything after between browser and server (bar SSL). Kind regards -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
