Re: htpasswd weirdness - SOLVED
On Sun, 2023-04-30 at 06:10 +0930, Tim via users wrote:
On Sat, 2023-04-29 at 17:39 +0100, Patrick O'Callaghan wrote:
> In *some" cases, usernames are added to the password file, and the
> password verifies correctly (using 'htppasswd -v ...'), but Apache
> still throws an error, e.g.:
>
> [Sat Apr 29 17:12:10.790251 2023] [authz_core:error] [pid 17622:tid
> 17769] [client 82.69.61.82:40716] AH01631: user notatest:
> authorization failure for "/":
>
> (NB: "authorization failure", not "authentication failure" as
with
> a
> password mismatch.)
Further thoughts... That error sound backwards.
I figured it out, see below.
A password mismatch ought to be authorisation failure (you are not
authorised). An authentication failure would be some other problem
(it
can't do the authentication).
I don't think so. Authentication is about identifying the user,
authorisation is deciding what they can do.
Are all the failures for trying to access the same thing?
Yes, and so are the successes.
The .htpasswd file should be outside of the webserving tree. Are
you
sure you're only using one file, or are correctly specifying the
right one?
Yes and yes.
The .htaccess files which mention which .htpasswd file to use should
use the full filepath to the .htpasswd file. And mention the correct
type of authentication being used (bearing in mind that only some
methods are actually usable). And you have to use the same scheme
when
creating the passwords.
AuthType Basic
AuthName "Secure space"
AuthUserFile /var/www/.htpasswd
Require valid-user
Satisfy All
The problem is that I was specifying a Group file and had Require
Group. Any user not in the Group file would fail. I've removed that
requirement and it works now.
Frankly, the Apache error log could be more informative ...
(BTW "Satisfy All" is no longer necessary. It's supported for backward
compatibility.)
Thanks again.
poc