httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From snyland@workfire.com (snyl...@workfire.com)
Subject Re: PR2145: win32 bypass auth for specific files
Date Mon, 13 Jul 1998 23:33:44 GMT
I have now performed this testing on WinNT 4.0 Service Pack 3.  For all 4 tests in all
6 scenarios, I had the same results as for Win95.  This is not that surprising, as I
am running the same exe & dll with the same config files, on the same machine.  If I
have time, I will look into running on NT as a service & see if this makes a
difference.  Otherwise, I suspect we are seeing lots of discussions fly by that assume
different test results are due to operating system differences between NT and 95, when
really the testers are using subtly different configurations & test cases. :-(

snyland@workfire.com wrote:

> My testing is with W95 C on FAT16 with Apache 1.3.0, no patches. This is a bit
> long.
> ...
> I've tested a number of scenarios to do with auth.  Here's what I've found.
>
> Scenario 1:    In access.conf, I started with
> <Directory "e:/Apache/htdocs/basic">
> AuthName basic_realm
> AuthType Basic
> AuthUserFile e:/apache/basic.txt
> require user joe
> </Directory>
>
> Requesting
> A) localhost/basic/  requests a password & gives me the Forbidden message.(there
> is no index.html file) even though I type the correct password.
>
> B)localhost/basic/basic.html prompts me for password if this is a new browser
> session (Netscape 4.04).  Serves up basic.html correctly iff I supply the right
> password.
>
> C)localhost/basic/testauth/ requests a password if this is new browser session &
> then gives Forbidden.  No index.html exists.  The directory does exist.  The
> password is correct.
>
> D) localhost/basic/testauth/dso.html requests a password if this is a new browser
> session & then serves up dso.html correctly if password is OK.
>
> Scenario 2:
> I changed access.conf to contain
> AccessFileName htaccess.txt
> <Directory "e:/Apache/htdocs/basic">
> #comment out the AuthName etc & see if it runs the same way in an htaccess file.
> AllowOverride All
> #AuthName basic_realm
> #AuthType Basic
> #AuthUserFile e:/apache/basic.txt
> #require user joe
> </Directory>
>
> and I had the htaccess.txt file in the <DocumentRoot>/basic/ directory, with the
> lines
> AuthName basic_realm
> AuthType Basic
> AuthUserFile e:/apache/basic.txt
> require user joe
>
> Doing the same 4 requests as in Scenario 1, I get the same results.  Access
> checking everywhere, with directory names forbidden and files correctly displayed.
>
> Scenario 3:
> I follow Brian's suggestion and get rid of the Basic Authentication stuff.  I use
> my htaccess.txt file with
>
> deny from all
>
> I do the 4 requests as in Scenario 1 and I get no prompts for passwords (good) and
> Forbidden for directories and filenames.
>
> Scenario 4:
> I follow the error discussed above and change by access.conf to have
> AllowOverride None
>
> Still using the htaccess.txt with deny from all.
>
> I do the 4 tests as in Scenario 1 and get access to files and Forbidden for
> directories.
> (I'm sure you're sick of all this by now, as am I)
>
> Scenario 5:
> I delete the htaccess.txt file to follow up on the message that says that the
> presence of the htaccess file causes the directory to be forbidden, even though we
> have AllowOverride None.
>
> I do the tests and of course get access to files and Forbidden for directories.
>
> These results cause me to question the conclusion that the presence of the
> htaccess file did something. :-)
>
> Scenario 6:
> Put back htaccess.txt with deny from all.  Have the old error AllowOverrideNone in
> access.conf. Try adding index.html to the /basic/directory.
>
> Requesting /localhost/basic/ now displays the index.html.
>
> Very simple & straight-forward.
>
> Question:
>
> Why does Apache tell me a directory is Forbidden, even if I give it the proper
> authorization?  Will this change if I activate something to auto generate the
> directory listing?  It's pretty disconcerting because when we first started
> testing Basic Authentication, we made the mistake of trying to access the
> directory name, rather than a file inside the directory.  We kept getting
> forbidden, and jumped to the wild conclusion that the Authentication wasn't
> working. Now we know better, but it was a bit nasty there for a while. :-)
>
> Thanks for your patience if you're still reading this!




Mime
View raw message