You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jerry Baker <je...@attbi.com> on 2002/10/02 06:11:59 UTC
Authentication
Currently, authentication is broken with the standard Windows config
file and current HEAD. Where is the documentation on the complete
mess-up of the auth modules and how to get it working again?
Thanks.
--
Jerry Baker
Re: Authentication
Posted by Jerry Baker <je...@attbi.com>.
Joshua Slive says:
> This has the effect of leaving GET unrestricted, according to the bug
> report. Is this correct behavior? It seems like, since the other methods
> are not change by the <limitexcept>, the require should still apply to
> them.
That's what I thought at first, but there are two ways of looking at it.
At first I looked at LimitExcept as a negative declaration. Negative in
the sense that it meant "ignore GET HEAD POST for the following
directives". Instead, Apache is treating it as a positive declaration
that is saying, "do not limit GET HEAD POST". It's a fine distinction,
but one that may cause confusion.
--
Jerry Baker
Re: Authentication
Posted by Joshua Slive <jo...@slive.ca>.
On Wed, 2 Oct 2002, Jerry Baker wrote:
> Joshua Slive says:
> > This has the effect of leaving GET unrestricted, according to the bug
> > report. Is this correct behavior? It seems like, since the other methods
> > are not change by the <limitexcept>, the require should still apply to
> > them.
>
> I agree. The LimitExcept directive implies that the limit will apply to
> everything with the exception of what follows (POST, HEAD, GET, etc.).
> "Except" is negative in nature - meaning exclusion. It implies that
> nothing will be done to those requests since the directive says they are
> to be excluded. Since Apache uses the LimitExcept directive to apply
> some sort of context to the HTTP requests in that directive, it's not
> really excluding those requests from the directive. It's semantics, but
> important ones.
>
> Users get clues about how config directives work by the meaning of the
> words used. In this case, "except" is misleading. It should be changed
> to <DontLimit GET HEAD POST>. There is a difference.
No. <limitexcept> should be corrected not to touch the other methods.
Otherwise, things like this wouldn't work:
<limitexcept GET>
require valid-user
</limit>
<limit GET>
order deny,allow
deny from badguy.com
</limit>
Joshua.
Re: Authentication
Posted by Jerry Baker <je...@attbi.com>.
Joshua Slive says:
> This has the effect of leaving GET unrestricted, according to the bug
> report. Is this correct behavior? It seems like, since the other methods
> are not change by the <limitexcept>, the require should still apply to
> them.
I agree. The LimitExcept directive implies that the limit will apply to
everything with the exception of what follows (POST, HEAD, GET, etc.).
"Except" is negative in nature - meaning exclusion. It implies that
nothing will be done to those requests since the directive says they are
to be excluded. Since Apache uses the LimitExcept directive to apply
some sort of context to the HTTP requests in that directive, it's not
really excluding those requests from the directive. It's semantics, but
important ones.
Users get clues about how config directives work by the meaning of the
words used. In this case, "except" is misleading. It should be changed
to <DontLimit GET HEAD POST>. There is a difference.
--
Jerry Baker
Re: Authentication
Posted by "John K. Sterling" <jo...@sterls.com>.
On Wednesday, October 2, 2002, at 08:07 PM, Joshua Slive wrote:
>
>
> <Location />
> <limitexcept GET>
> require valid-user
> </limitexcept>
> </location>
>
> <directory />
> require valid-user
> </directory>
>
> This has the effect of leaving GET unrestricted, according to the bug
> report. Is this correct behavior? It seems like, since the other
> methods
> are not change by the <limitexcept>, the require should still apply to
> them.
>
what jerry brought up here definitely seems like a bug to me. Not sure
why folks are in such disbelief :) i'll check into it -
sterling
Re: Authentication
Posted by Joshua Slive <jo...@slive.ca>.
On Wed, 2 Oct 2002, William A. Rowe, Jr. wrote:
> YES!
All that merging stuff is true. But let's go back to the original
problem:
<Location />
<limitexcept GET>
require valid-user
</limitexcept>
</location>
<directory />
require valid-user
</directory>
This has the effect of leaving GET unrestricted, according to the bug
report. Is this correct behavior? It seems like, since the other methods
are not change by the <limitexcept>, the require should still apply to
them.
Joshua.
Re: Authentication
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
YES!
The pattern is:
<VirtualHost>
<Directory> (and .htaccess'es within those directories)
<Files>
<Location>
with the <Limit[Except]>s parsed in the appropriate container.
We repeat <Location> because the original <Location> could
have changed in translate_name, and yes, the URI permissions
or restrictions always override any file-based permissions.
E.g., you could have a
DocumentRoot /thatpath
Alias /secure-dav/ /thatpath/
<Location /secure-dav>
Dav On
</Location>
and even though DAV is OFF in the <Directory /thatpath> ...
the server will still allow a DAV view within the /secure-dav/...
namespace.
This is how 1.3 and 2.0 have always worked.
Bill
At 06:06 PM 10/2/2002, Jerry Baker wrote:
>André Malo says:
>>Sorry, I can't believe, that it worked ever before the way you
>>described. Are you sure, that you've changed nothing else?
>
>So Location matches are even more important than .htaccess matches? That doesn't make sense. I would think that a directive in .htaccess is always more specific than one in the config files.
>
>--
>Jerry Baker
Re: Authentication
Posted by Jerry Baker <je...@attbi.com>.
André Malo says:
> Sorry, I can't believe, that it worked ever before the way you
> described. Are you sure, that you've changed nothing else?
So Location matches are even more important than .htaccess matches? That
doesn't make sense. I would think that a directive in .htaccess is
always more specific than one in the config files.
--
Jerry Baker
Re: Authentication
Posted by André Malo <nd...@perlig.de>.
* André Malo wrote:
> # or: use advantages of PCRE
> <Location /(?!secret)>
which have to be turned on, of course
<Location ~ /(?!secret)>
[...]
nd
Re: Authentication
Posted by André Malo <nd...@perlig.de>.
* Jerry Baker wrote:
> If there's no way to have a LimitExcept *and* separate directories
> requiring authentication for everything, how in the world could you
> have a DAV enabled server while still being able to restrict
> directories with authentication requirements?
There are several ways. For instance:
# turn <directory> to <location>
<Location />
<LimitExcept GET HEAD POST>
Require user bob
</LimitExcept>
</Location>
...
<Alias /secret "D:/Web/www/protected">
<Location /secret>
AuthType Basic
AuthUserFile "D:/Web/htpasswd"
AuthName "Protected Area"
Require valid-user
</Location>
# or: use advantages of PCRE
<Location /(?!secret)>
<LimitExcept GET HEAD POST>
Require user bob
</LimitExcept>
</Location>
...
<Alias /secret "D:/Web/www/protected">
<Directory "D:/Web/www/protected">
AuthType Basic
AuthUserFile "D:/Web/htpasswd"
AuthName "Protected Area"
Require valid-user
</Directory>
nd
--
sub the($){+shift} sub answer (){ord q
[* It is always 42! *] }
print the answer
# André Malo # http://www.perlig.de/ #
Re: Authentication
Posted by Jerry Baker <je...@attbi.com>.
André Malo says:
> Sorry, I can't believe, that it worked ever before the way you
> described. Are you sure, that you've changed nothing else?
If there's no way to have a LimitExcept *and* separate directories
requiring authentication for everything, how in the world could you have
a DAV enabled server while still being able to restrict directories with
authentication requirements?
--
Jerry Baker
Re: Authentication
Posted by Jerry Baker <je...@attbi.com>.
André Malo says:
> * Jerry Baker wrote:
>
>> Except for that directory is configured to require authentication. See
>> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13218
>
> <Location> sections override <Directory>, see
> http://httpd.apache.org/docs-2.0/sections.html#mergin
>
> Sorry, I can't believe, that it worked ever before the way you
> described. Are you sure, that you've changed nothing else?
Absolutely. My config file backups show that before yesterday, I hadn't
changed anything in that file for 5 months.
--
Jerry Baker
Re: Authentication
Posted by André Malo <nd...@perlig.de>.
* Jerry Baker wrote:
> Except for that directory is configured to require authentication. See
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13218
<Location> sections override <Directory>, see
http://httpd.apache.org/docs-2.0/sections.html#mergin
Sorry, I can't believe, that it worked ever before the way you
described. Are you sure, that you've changed nothing else?
nd
--
Treat your password like your toothbrush. Don't let anybody else
use it, and get a new one every six months. -- Clifford Stoll
(found in ssl_engine_pphrase.c)
Re: Authentication
Posted by Jerry Baker <je...@attbi.com>.
Greg Stein says:
> On Tue, Oct 01, 2002 at 11:13:55PM -0600, Jerry Baker wrote:
>> Jerry Baker says:
>> > Jerry Baker says:
>> > > Yet, when I access that directory, I am just given an empty directory
>> > > listing. No prompt for a username or pass.
>> >
>> > Nevermind. It's just something else that DAV broke. Turning off DAV
>> > fixed the problem.
>>
>> Please accept my apologies for the spam. The problem is not with DAV,
>> but with <LimitExcept GET HEAD POST>. When I remove the LimitExcept
>> directive, basic authentication works again. Makes no difference whether
>> Dav On or Dav Off.
>
> Right. You were saying "require authentication *except* for those methods",
> so (of course) a GET request would not demand a user/pass.
Except for that directory is configured to require authentication. See
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13218
--
Jerry Baker
Re: Authentication
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Oct 01, 2002 at 11:13:55PM -0600, Jerry Baker wrote:
> Jerry Baker says:
> > Jerry Baker says:
> > > Yet, when I access that directory, I am just given an empty directory
> > > listing. No prompt for a username or pass.
> >
> > Nevermind. It's just something else that DAV broke. Turning off DAV
> > fixed the problem.
>
> Please accept my apologies for the spam. The problem is not with DAV,
> but with <LimitExcept GET HEAD POST>. When I remove the LimitExcept
> directive, basic authentication works again. Makes no difference whether
> Dav On or Dav Off.
Right. You were saying "require authentication *except* for those methods",
so (of course) a GET request would not demand a user/pass.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Authentication
Posted by Jerry Baker <je...@attbi.com>.
Jerry Baker says:
> Jerry Baker says:
> > Yet, when I access that directory, I am just given an empty directory
> > listing. No prompt for a username or pass.
>
> Nevermind. It's just something else that DAV broke. Turning off DAV
> fixed the problem.
Please accept my apologies for the spam. The problem is not with DAV,
but with <LimitExcept GET HEAD POST>. When I remove the LimitExcept
directive, basic authentication works again. Makes no difference whether
Dav On or Dav Off.
--
Jerry Baker
Re: Authentication
Posted by Jerry Baker <je...@attbi.com>.
Jerry Baker says:
> Yet, when I access that directory, I am just given an empty directory
> listing. No prompt for a username or pass.
Nevermind. It's just something else that DAV broke. Turning off DAV
fixed the problem.
--
Jerry Baker
Re: Authentication
Posted by Jerry Baker <je...@attbi.com>.
Jerry Baker says:
> Currently, authentication is broken with the standard Windows config
> file and current HEAD. Where is the documentation on the complete
> mess-up of the auth modules and how to get it working again?
Perhaps I should be more clear. I have a directory containing an
.htaccess file. The config for this directory includes "AllowOverride
All". The contents of the .htaccess are:
AuthUserFile "D:/Web Sites/www/users.pwd"
AuthName "Protected Area"
AuthType Basic
Require valid-user
I have the following modules loaded in the httpd.conf:
mod_authn_anon.so
mod_authn_dbm.so
mod_authn_default.so
mod_authn_file.so
mod_authz_dbm.so
mod_authz_default.so
mod_authz_groupfile.so
mod_authz_host.so
mod_authz_user.so
mod_auth_basic.so
mod_auth_digest.so
Yet, when I access that directory, I am just given an empty directory
listing. No prompt for a username or pass.
--
Jerry Baker
Re: Authentication
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 11:11 PM 10/1/2002, Jerry Baker wrote:
>Currently, authentication is broken with the standard Windows config file and current HEAD. Where is the documentation on the complete mess-up of the auth modules and how to get it working again?
The documentation is not complete, nor hooked up into the main
indexes and directives pages, therefore we aren't releasing the new
auth schema, and therefore little reason to worry.
Exactly the reason this aught to have been committed on a branch,
or better yet, to the 2.1 tree.
Enough ranting. 2.0.43 will be a bugfix and security release,
and doesn't include this pretty major reorganization.
Need to put the docs and reconfig front and center after .43 goes
out the door, or we should just relegate that code to it's own branch
until it's ready. I remember we talked about some reasonable time
frame (2 weeks?) that the tree could be broken. We are kind of
stretching that time table already.
Bill