.htaccess

Allow from multiple IPs

[dadpups]

Here is a thing that works:

AuthUserFile /home/bbbbb/.htpasswd
AuthGroupFile /dev/null
AuthName "Hello!"
AuthType Basic

<limit GET>
satisfy any
order deny,allow
deny from all
allow from xx.xx.xx.xx
require valid-user
</limit>

This .htaccess file allows access to the one IP address and to my list of usernames/passwords.

Here is the problem....

If I add another IP, like this:

AuthUserFile /home/bbbbb/.htpasswd
AuthGroupFile /dev/null
AuthName "Hello!"
AuthType Basic

<limit GET>
satisfy any
order deny,allow
deny from all
allow from xx.xx.xx.xx
allow from xxx.xx.xx.
require valid-user
</limit>

Neither IP access works. The username/password still works.

Any ideas on why the .htaccess file no longer allows access from either of the IPs? Is my "satisfy any" statement in the wrong place?

Thanks,

dadpups

[jdMorgan]

dadpups,

Welcome to WebmasterWorld [webmasterworld.com]!

Your directives look OK to me, although I'm no expert in this area. A couple of observations, though. First, the access control will affect only GET requests - Is that what you want? Also, you can simplify it a little, since you wish to deny all except those IP addresses or authorized users:

<limit GET>
satisfy any
order allow,deny
allow from xx.xx.xx.xx
allow from xxx.xx.xx.
require valid-user
</limit>

Other than those comments, perhaps this will serve to bump your post up on the active list. <bump>

Jim

[dadpups]

Jim,

Thanks. I use GET because I am giving access to subscribers (access to pdf files in the htaccess directory).

Can you explain why your recommended "script" does not let everyone in? It would seem that, if you don't specify any "denies" (like all), then no one would be denied.

Does the "satisfy any" have something to do with it?

I have been searching everywhere for a comprehensive explanation of this .htaccess thing, with plenty of examples, that a person who has not learned Apache can use. Odd but it is impossible to find.

Example are some say use GET, some say don't use PUT as it is not widely implemented (same for POST). Some examples have <limit PUT GET>, for their specific servers.

Thanks again for your patience.

dadpups

[jdMorgan]

dadpups,

The <Limit> restrictions only apply to the nominated method(s). As written, anyone -- password or not -- can POST to your site. That's why I asked about that. You could wrap the restrictions in a <Files *> container instead, so that the restrictions apply by file rather that HTTP request method. Or, use <LimitExcept> to cover all methods. I don't know if any one of these will work better; As I said, I haven't played with password/IP restriction combinations before.

As to why you don't need an explicit deny, it's because using Order Allow,Deny specifies that access is denied by default.

Ref: Apache mod_access [httpd.apache.org]

Satisfy any simply means that if the password requirement is satified OR the IP address is satisfied, then access will be permitted. Contrast to Satisfy all where access would only be permitted for users from the allowed IP addresses who also authenticated with a valid password - In other words, password AND IP would have to be satisfied for Satisfy all.

Please post if you get this sorted out - it's an interesting problem.

Jim

[dadpups]

A couple of minor points.

I am working with the .htaccess file using a product called Textpad (excellent by the way).

It allows me the options of saving the "text" file as File Format UNIX or PC. Encoding ANSI. Would the UNIX or PC save make any difference to the Apache server?

Also the IP addresses have a following ".", like 111.222.333. - not 111.222.333 when I want to give access to 111.222.333.1-255. I think that is correct. Can you confirm that for me?

So although all looks OK, the outfit I am trying to give access to (using several IPs) still complains that it isn't working.

here is the exact .htaccess file:

AuthUserFile /home/hydroweb/.htpasswd
AuthGroupFile /dev/null
AuthName "Journal of Environmental Hydrology"
AuthType Basic

<limit GET>
satisfy any
order allow,deny
allow from 63.76.22.2
allow from 130.116.16.
allow from 130.116.17.
allow from 130.116.18.
allow from 130.116.19.
allow from 144.110.16.
require valid-user
</limit>

Thanks in advance!

dadpups

[jdMorgan]

dadpups,

I was hoping someone else might stop in and offer some help - someone who has done this before. I've only got one suggestion left, and that is to try the following structure -- it's more like what you started with as far as the satisfy any logic goes. Basically, we separate the acceptable-IP-address evaluation from the satisfy any evaluation using SetEnvIf:

AuthUserFile /home/hydroweb/.htpasswd
AuthGroupFile /dev/null
AuthName "Journal of Environmental Hydrology"
AuthType Basic

SetEnvIf Remote_Addr ^63\.76\.22\.2$ ipaok
SetEnvIf Remote_Addr ^130\.116\.1[6-9]\. ipaok
SetEnvIf Remote_Addr ^144\.110\.16\. ipaok

<limit GET>
satisfy any
order allow,deny
allow from ipaok
require valid-user
</limit>

Note that the variable name ipaok is arbitrary - you can call it whatever you want as long as all references are consistent and you don't try to re-use a pre-defined server variable name. I picked it to mean "IP address OK."

Also, the notation of the valid IP addresses here uses regular expressions [etext.lib.virginia.edu], and as such, is much more precise that the prefix-matching of IP addresses used directly in allow or deny directives. It allows precise single-address specification, as in the first IP address, and also allows character-range specification as in the second line. That "character-range" phrase is important; this is a character compare, not a numeric range compare. Periods and other special characters must be escaped to maintain their meaning as literal characters - that's what the "\" characters are for.

HTH,
Jim

[dadpups]

Jim,

First and most obvious is a great big thanks for your time. I will try your suggestion.

One last question. I am uploading .htaccess by FTP. Should I be doing the Telnet thing instead?

Cheers,

dadpups

[dadpups]

Jim,

I tried your recommended configuration. It does not appear to work. The IP that is testing it, 63.76.22.2 (outtask.com), gets a request for user name and password. They get in without UN/PW in my original config.

Could there be a problem with firewalls and caches on proxy servers? Now I sound like I know what I am talking about, but I really don't. If a person had once used UN/PW access, and now they are supposed to get the IP thing, could the server cache keep feeding them the UN/PW page?

By the way, do you have a static IP? I could add you to my list and have you test it. I am sure this idea excites you beyond belief.

I will keep working on this and may some day find the truth.

Thanks again!

dadpups

[jdMorgan]

dadpups,

Well, rats. I don't use code like this myself, so I really can't tell what is going on. I suppose it could be a caching issue, so have the "tester" set his browser preferences to reload the page from the server every time it is requested. Also, if the tester comes into the site through a proxy, then you will see the proxy's address, not the tester's.

Also, the code I posted is "from the book", not from a real working site. It could very well be wrong.

A good look at your raw logs files while testing might help.

Jim

[wkitty42]

dadpups,

the "satisfy any" is what's allowing them in without a username and password... "satisfy all" would require them to pass the address restriction and the username/password validation...

what you've got right now allows anyone in if they know a valid username/password combination /OR/ if they are in one of the allowed IP ranges... if they are in one of the allowed ip ranges, they will not be asked for a username/password...

that's my understanding, anyway... its been a while since i played with passworded stuffs like this... i had to go refresh my memory on what satisfy actually did...

HTH

[jdMorgan]

wkitty42,

Yes, that what dadpups wants to do... Require a username/password unless the request comes from a small set of recognized IP addresses. If the request comes from one of those, just let it in without authentication.

Do you see anything else possibly wrong here? - I don't use this method myself, but I'm trying to help out, and I'm in over head as far as actual user-experience goes...

Thanks,
Jim

[wkitty42]

jdMorgan,

i put his stuff on my test server almost exactly like it was... just modified it a bit for my setup... it worked as it was supposed to... in the ip range got in with no password prompting... outside the ip range was asked for the password...

another thing to note is that once one is authenticated, one is not reauthenticated until one closes one's browser and it flushes that authentication info from its memory... in the case of netscape and mozilla, this means that one must close the browser AND the email AND the composer... IOW, all parts must be closed... not just the browser part... i'm not sure about IE in this respect... i suspect that it'll drop the authentication once all of its windows are closed... actually, hang on a sec... just did a quick test with IE6 and simply closing the window removes the cached authentication info... it appears that one also only need to close the one window that was authenticated...

[wkitty42]

dadpups,

this is the .htaccess file from your earlier message... this is the one that i based my testing on...

AuthUserFile /home/hydroweb/.htpasswd
AuthGroupFile /dev/null
AuthName "Journal of Environmental Hydrology"
AuthType Basic
<limit GET>
satisfy any
order allow,deny
allow from 63.76.22.2
allow from 130.116.16.
allow from 130.116.17.
allow from 130.116.18.
allow from 130.116.19.
allow from 144.110.16.
require valid-user
</limit>

what does this party that says its not working mean when they say "its not working"... that's really too general to troubleshoot from...

what http server software and version are you running on? what operating system?

you may want to try using

allow from 63.76.22.2/255.255.255.255

and see if that does the trick...

actually, i should ask you what does your errorlog and accesslog show when they try to get in? are they really coming from that ip number?

[dadpups]

Hey guys thanks for the help!

The IPs I am trying to give access to are an outfit called outtask.com (63) and the rest are the CSIRO in Australia, a research organization.

I will be getting back to the CSIRO to ask to deal with an IT person. If IP works for outtask, they should all work. So the difficulty they have may be their issue.

I am at a host called phpwebhosting.com. I think they run Apache 1.3.

I will look at the error log and "weblog" tomorrow and let you know what I find that might be interesting.

More later and thanks again!

Dadpups

[wkitty42]

dadpups,

what did you find in those logs?

[dadpups]

Error log is empty. Access log has a bunch of accesses but my host converts IPs to URLs at the "end of the day" so I cannot be sure that an IP has not come in under a URL "alias."

I am trying to figure out subnet masks, maybe that has something to do with it. But I don't really think so because I think my host looks for an IP address and doesn't care about network addresses or masks. That is, when the aussies ask for an .htaccess protected file, the host sees the aussie IP and it could care less what they have done on their network to to set up masks.

I think I now have 2 truly static IPs. One can get in, I am waiting for word from the other. And I will soon double check the rest of the addresses that you see in my post.

Thanks for your continued interest. Really appreciated.

dadpups

[jdMorgan]

dadpups,

> That is, when the aussies ask for an .htaccess protected file, the host sees the aussie IP and it could care less what they have done on their network to to set up masks.

That is correct. Your server gets the requestor's IP address, or possibly the IP address of a proxy that the request is coming through. At the end of the day, your ISP processes these IP addresses by doing "reverse DNS" to convert them to hostnames. This "feature" is pretty worthless when you are trying to develop IP-based access control, as in your current project. I actually managed to get one of my hosts to STOP doing this, and I have been much happier.

Please do let us know how it goes.

Jim

[claus]

Sorry i didn't see this sooner, all examples posted ought to work, including the first - that is, if you remove the trailing dot in the three-quarter IP (the IP that is added as #2 in post 1).

allow from xx.xx.xx.xx 
allow from xxx.xx.xx. 

Jim, you even linked to this in post 2:

A partial IP address
Example: Allow from 10.1
The first 1 to 3 bytes of an IP address, for subnet restriction

;)

[jdMorgan]

claus,

Well-spotted! If that fixes the problem, it'll be great. I had assumed - possibly incorrectly - that Allow and Deny used simple prefix-matching a la Redirect, but the mod_access documentation does not mention the matching method at all; it only gives examples.

If this works, I'll have to add a note to my copy of the mod_access documentation for future reference!

Thanks,
Jim