Forum Moderators: phranque
To start with, is it better to use the Example #1 <Files> directive over the <Files> directive in Example #2?
Or, do I need the <Files> directive at all or can I just use as in Example #3
Example #1:
SetEnvIf Remote_Addr ^#*$!\.xx\.1(2[89]¦[3-8][0-9]¦9[01])\. ban
<Files ~ "^.*$">
order allow,deny
allow from all
deny from env=ban
</Files>
Example #2:
SetEnvIf Remote_Addr ^#*$!\.xx\.1(2[89]¦[3-8][0-9]¦9[01])\. ban
<Files *>
order allow,deny
allow from all
deny from env=ban
</Files>
Example #3:
SetEnvIf Remote_Addr ^#*$!\.xx\.1(2[89]¦[3-8][0-9]¦9[01])\. ban
order allow,deny
allow from all
deny from env=ban
Next question:
I found some posts that said to prevent scammers, rippers, etc. from seeing your .htaccess rules you need to use:
<Files .htaccess>
order allow,deny
deny from all
</Files>
If I use the <Files> directive as in Example #1 or #2, will that automatically prevent anyone seeing .htaccess?
All this searching and learning came about because I had trouble trying to password protect a sub directory of cgi-bin. After the password was added I could no longer use the application that accessed that sub directory. The password just wasn't accepted. Tech support took a look and told me the application wasn't recognizing the password. They said the problem was my .htacces and I needed to get rid of the code I was using which is what is in Example #1.
Doesn't make sense to me, but I can't seem to get any further help from tech support on this.
I want to use that app in the cgi-bin folder, but I don't understand enough to figure out what is causing the problem.
SetEnvIf Remote_Addr ^***\.**\.1(2[89]¦[3-8][0-9]¦9[01])\. ban
SetEnvIf Request_URI \.htaccess$ ban
SetEnvIf Request_URI \.htpasswd$ ban
<Files *>
Order Allow,Deny
Allow from all
Deny from env=ban
</Files>
Jim
<Files *> is the 'simple' format for specifying all files.
So they are entirely equivalent.
For help with regular expressions, see the tutorial cited in the Apache forum charter.
Jim
SetEnvIf Remote_Addr ^***\.**\.1(2[89]¦[3-8][0-9]¦9[01])\. ban
SetEnvIf Request_URI \.htaccess$ ban
SetEnvIf Request_URI \.htpasswd$ ban
<Files *>
Order Allow,Deny
Allow from all
Deny from env=ban
</Files>
Seems a bit much in my case, but what I have below appears not to be working? Do you see an issue with this?
AddType text/html .shtml .html .htm
AddHandler server-parsed .shtml .html .htm
ErrorDocument 404 /404page.shtml
<Files *>
order deny,allow
deny from 71.96.36.8
allow from all
</Files>
my friend at 71.96.36.8 says he is able to access the site with this .htaccess file just fine? He should not be able to?
1) Thoroughly review the meaning of the "Order" directive here: [httpd.apache.org...]
2) Tell your friend to flush his browser cache (Temporary internet files) *after* you corrrect your code. Otherwise, he'll probably see an old cached copy of your page, and report to you that your code does not work.
Jim
This does not work
<Files *>
order deny,allow
deny from 71.96.36.8
allow from all
</Files>
this does
<Files *>
order allow,deny
allow from all
deny from 71.96.36.8
</Files>
then what i really wanted messed it up even more
Tried adding both of these, so I could deny the hacker AND allow only my IP to access the secret directory.
<Files *>
order allow,deny
allow from all
deny from 71.96.36.8
</Files>
# now that the hacker is denied successfully, tighten
# down and allow ONLY me access to the secrect
# directory
<Directory /secretadmindirectory*>
order deny,allow
deny from all
allow from xx.xx.xx.x
</Directory>
so how do you combine these guys?
The easiest solution is to put the restriction on the "secret directory" into an .htaccess file *in* that directory.
For more complex mod_access constructs, you can extend its functionality by using the SetEnvIf directive (mod_setenvif). This allows Allow from and Deny from to act based on more than hostnames and IP addresses, allowing you to control access by User-agent, Remote-Host, Request-URI, and a bunch of other server variables.
Also, mod_rewrite may prove to be more flexible for your needs -- See the documentation cited in our forum charter [webmasterworld.com].
Jim