1) Create directory off root of server 2) Put in following .htaccess AuthType Basic AuthName Restricted Satisfy Any AuthDBMUserFile /local/server/.htpasswd <Limit GET POST> order deny,allow deny from all allow from 216.231.111.17 allow from 64.21.99.146 require valid-user </Limit> 3) Access from 216.231.111.17, requests a password 4) Access from 64.21.99.146, doesn't request a password 5) Put change statement to "allow from 216.231.111.17/32" 6) Access from 216.231.111.17 no longer asks for password 7) Add "Allow from 204.107.90.128" (Out of the /19 that the server and 216.231.111.17 are in, but still advertised via BGP locally) and can't access. Use "Allow from 204.107.90.128/32", can. Why does it seem like if the IP is in a network local we have to put /32 on it, and if its remote it works ok?
I'm very skeptical you've identified a bug here for several reasons: 1. I've never heard of any problem remotely like this before, and these features are used frequently. 2. The fact that you are using <Limit GET POST> shows that you are not following recommended practices for apache configuration, and therefore there could be many other things wrong with your config. I suggest you start with an absolutely default install of apache with no extra modules and no config modifications except the ones you suggest below. If it still doesn't work, you can reopen this bug, but be sure to provide more details about what is in your logs, the exact OS version, etc. Thanks for using Apache!
Hi, Ok, we did some investigation. 1) Download/uncompress/untar source 2) Compile with gcc 3.2.3 with just ./configure;make;make install 3) Create a directory under htdocs called testing, put in an .htaccess of : AuthDBMUserFile /local/wwwcust/passes/sample AuthDBMGroupFile /dev/null AuthName Members_Only AuthType Basic Satisfy Any order deny,allow deny from all allow from 24.193.48.116 allow from 202.139.152 allow from 210.80.149 allow from 216.183.31.224/27 allow from 209.88.233.224/27 allow from 209.88.69.192/27 allow from 209.135.126 allow from 64.8.218 allow from 63.201.23 allow from 217.145.67.0/25 allow from 62.39.85 allow from 216.231.111.14 require valid-user 4) Edit the stock httpd.conf where it depicts the default document root like <Directory /usr/local/etc/httpd/htdocs> and change the "AllowOverride None" to "AllowOverride All". Start server 5) From 216.231.111.14 attempt to access the directory, it will ask for an id/pass 6) Change it to 216.231.111.14/32, it works. Delete all directories and configs. Start the instructions again, except in step 2 , change it to "CC=gcc -m32" infront of the ./configure;make;make install At step 5, it will let you in immediately. So, it seems, in 64 bit mode it has issues, but not 32 bit. We can reproduce this on mutiple machine that we own, and others own.
Interesting. I assume that it doesn't matter if you remove the Auth*/Require/Satisfy directives and just test mod_access? I don't have a solaris system handy to test on, but if someone does, I'm sure they'd be interested in your exact OS/patch level.
With only the following in .htaccess: order deny,allow deny from all allow from 216.231.113.11 allow from 24.193.48.116 I see the same symptoms, coming from the 24.* address I get in (Outside our network) , from 216.* (local subnet) I get forbidden, if I add the /32 it works fine. This server is running Solaris 9, kernel patch level 112233-07, apache 1.3.28 compiled with 64-bit gcc3.2.3 with a standard build , using gnu make 3.80 (also built 64-bit).
What's the result of running: $ cd srclib/apr/test $ make testall $ ./testall -v testipsub from the 64-bit build tree?
Hi, I find no "apr" directory anywhere in the Apache 1.3.X tree when I untar it. Thanks, Tuc/TTSG Internet Services, Inc.
This was found and fixed independently by Henning Brauer from the OpenBSD team; the fix is checked in here for the next 1.3 release; thanks for the report. http://cvs.apache.org/viewcvs.cgi/apache-1.3/src/modules/standard/mod_access.c?r1=1.46&r2=1.47