.htaccess IP-based restriction not working

issue with .htaccess failing to function as expected...

[bailywolf]

This is a sticky one... I've searched and beaten my head against it.

I need to restrict access to a certain folder based on IP.

Our server is a little wonky in terms of congig though. It serves on port 801, and uses ProxyPass between a front-end http server and a back-end Apache/PhP/Zend application server.

It's an IBM iSeries... if that matters.

I want to drop an .htaccess into my folder with something like this in it:

<Limit GET>
order deny,allow
deny from all
allow from #*$!.#*$!.#*$!.#*$!
</Limit>

I've tried about a dozen variations on this theme.

I can either completely block access to the folder, or completely allow it, with no middle ground. If there is ANY "allow from" it allows from all. Without one, it denies from all.

All the places I've checked tell me this should be working fine... yet, it's isn't.

Anyone have any idea what might be happening here.

Thanks,

-B

[wilderness]

try the following (note where I have inserted "allow_in" you may use most any term you desire) :

<Limit GET>
order deny,allow
allow from #*$!.#*$!.#*$!.#*$!
deny from all
allow from env=allow_in
</Limit>

[bailywolf]

Still no-go.... wouldn't I need to set allow_in to something with SetEnvIf?

This has me totally stumped... for some reason the 'allow/deny from all' either blocks or permits everyone, and exceptions are ignored.

-B

[wilderness]

SetEnvIf is for User-Agents

In you example; allow from is an IP range (at least I hope).

I've been using an opposite configuration of the example I provided to you for more than seven years.

[jdMorgan]

One thing to check is to make sure you've only got one "Order" directive that applies to the directory/subdirectories in question. If you have multiple Order directives whose scopes are not mutually-exclusive, then only the last Order directive encountered will apply.

So check the <Directory> and <Location> containers in httpd.conf, conf.d, etc, and the <Limit> and <Files> containers in the .htaccess file itself for conflicting/overlapping Order directives. Of course, Order directives not enclosed in *any* container are globally-scoped and can cause problems as well.

Also, if you're using authentication (mod_auth), look for conflicts with the "Satisfy any/all" setting.

Jim

[bailywolf]

Here's an odd bit of additional trivia on this.

I can password protect the folder via .htaccess no-prob.

So I figured, "heck with this IP thing."

Buuuuut... I just found out that the users want to run some kind of shared document authoring application based on 'mod_dav' so I need to secure the hell out of the folder.

No, I nix the casual security of IP restriction and start on a basic .htaccess password auth combined with SSL.

BUT

For some damn reason, ever Mod_Rewrite I try (or have googled up) to flip the URL from "http://www.subdom.dom.com/folder/" to "https://www.subdom.dom.folder/" breaks the whole world. It made Internet Explorer cry, and Firefox leaned out of the screen and smacked me in the mouth. Its ring cut my cheek too.

I have a root-level .htaccess which does some URL tweaking (adding WWW and whatnot)... could this be mucking up my folder-level .htaccess rewrite?

-B

[jdMorgan]

See RewriteOptions Inherit

Jim

[bailywolf]

I'm not sure how Inherit will fix this for me...

With this code in the .htaccess:

RewriteEngine On
RewriteOptions inherit
RewriteCond %{SERVER_PORT} 80
RewriteCond %{REQUEST_URI} /folder/
RewriteRule ^(.*)$ [subdom.dom.edu...] [R,L]

Firefox gives me this error:

The page isn't redirecting properly

Firefox has detected that the server is redirecting the request for this address in a way that will never complete.

*This problem can sometimes be caused by disabling or refusing to accept cookies.

IE just chokes on it.

-B

[jdMorgan]

> I have a root-level .htaccess which does some URL tweaking (adding WWW and whatnot)... could this be mucking up my folder-level .htaccess rewrite?

Yes, certainly, and therefore you may wish to disable RewriteOptions inherit (if enabled) and/or take a comprehensive look at *all* of the rules that will be applied to each of the various secure and non-secure requests, and take steps to eliminate the conflict.

For an "outside in" view of your infinite redirection loop problem, use the "Live HTTP Headers" extension for Firefox and Mozilla browsers -- You'll be able to see each browser request and each server response.

It is very likely that another rule is redirecting your https requests back to http, so they'll then get redirected to https again, back to http, ad infintum... till the client or server gives up, as you see.

Jim

[bailywolf]

Ah, that makes sense- thanks. I'll check out those extensions ASAP.

-B