Can a final "Allow all"

What does "final" mean in this context?

Remember that all those SetEnvIf directives do not, by themselves, say anything about access. You're just defining an environmental variable that will be used by later Allow or Deny or Require statements. To be fully effective, they should be at the highest possible directory level -- either lying loose in a <VirtualHost> envelope or in the <Directory /> section -- so they will apply to all requests, regardless of what you plan to do with them.

It would be perfectly legimate to have
Allow from env=special_case
in one place, and
Deny from env=special_case
(referring to the very same environmental variable) in a different place. The server doesn't care.*

In general, the essence of a <Files> envelope is to make special rules, whether those are stricter or looser than your default rules. (Let everybody see robots.txt; let nobody see your admin files.) Each new envelope has the potential to override all previous envelopes, where "new" and "previous" mean "in the order that the server meets them".

Now, I know I've asked this before, but are you absolutely certain you need a <Location> envelope? It seems like borrowing trouble. If there are a few rules that are only meant to apply to specific URLs, and those URLs cannot be made to conform to anything in the (physical) directory structure, you could always do it with a RewriteRule, where the body of the rule lays out the URL.


* Can't help thinking this line belongs on a T-shirt.

I am quickly learning that the server DOESN'T care, Lucy.

"Final" means when all the directives are gathered together in a Pre VirtualHost config include file and one of the several "Allow from all" or "Deny from all" is the last one digested / iterated over by Apache / the server.

Regarding my use of <Location />, when every other attempt I made to block IP's via a Pre VirtualHost include file FAILED an admin in Servint's NOC wrapped my IP block list in a <Location /> container and voila! The server stopped complaining. (Maybe he was just taking a shortcut?) The weird thing is I haven't checked to see if those IPs ARE actually being blocked . . or if the server just . . didn't care. Argh.

I also see this (below) in Apache's documentation and it leads me to believe that "it's acceptable" (YMMV. I'm relatively new to this effort as something other than "another copy+paste webster".)

An exception is <Location "/">, which is an easy way to apply a configuration to the entire server

From here: [url] [httpd.apache.org...]

Unfortunately, I'm at the really uncomfortable stage of not knowing by reading but not by experience AND not knowing enough to know what I don't know. I've probably invested ~50+ hours in the past 3 weeks studying Regex and Apache directives.

Sigh. Head down. Soldier on. (I really appreciate all your input and guidance.)

Lucy, I'm beginning to see the light. <Location /> may not be my friend.

Sometimes a good night's sleep allows one to see things that blurry-eyed people fail to see.

Authorization / Authentication / Access Control? Who woulda thunk they're something other than "the same thing".

Oh, and that thing about directives that are only given their superpowers"in context". That reality creeps in slowly.

Machines are machines. Math is math. Some rules are cast in . . code.

Damn code! Why does it have to be so unforgiving, so demanding?!

Then again, my new friend may just be a little flexible <If> . .

WebWork;
Maybe i can help, since I publish IP blocklists, using Mod_Authz (previously Mod_Access).
When dealing with Apache 2.3 and older, I use "deny from" and "allow from" directives under the "Files" wrapper. There is a required statement called "order" which specifies the order in which the server processes the IP addresses, user agents, etc, in a blocklist. By stating the rule as "order deny,allow" one tells the server to deny from the specified deny rules first, then allow anything not listed.

For Apache 2.4 and newer the definition becomes (example):
<Files *>
<RequireAll>
Require all granted
Require not ip 000.000.000.000/12
Require ip 123.456.789.0/21
</RequireAll>
</Files>

Now the strange thing about Mod_Authz blocklists is that Mod_Rewrite rules can override them! So, to stop any of my rewrite conditions from interfering, I add thee following rewrite rule high up in the rewrite list (I am using a custom 403 page in this example):

RewriteRule ^403\.(s?html|php)$ - [L]

This tells the server to stop processing any further for any IP that has been 403'd.

The rewrites can be used to finetune an action for individual IP addresses that are in a blocklist. By placing a special action above that final [L] rule you can override the 403 response. I use this sometimes to send really unwanted (referer spam, etc) traffic into endless loops back to 127.0.0.1.

I forgot to show my use of "order deny,allow. Imagine this mini blocklist:

<Files *>
order deny,allow

# Unwanted IP addresses:
deny from {ips and cidrs}

#Poke a hole for a friendly user
allow from 123.456.789.0

</Files>

# Block world access to your .htaccess
<Files .htaccess>
deny from all
</Files>

<Files *>

PLEASE do not use this locution unless it's your own server-- and if it is your own server, why bother with a <Files> envelope at all? You can achieve the identical result by just dropping your rules loose in the config file.

The problem with <Files *> for most users (that means people on shared hosting) is that it will override any and all <Files> or <FilesMatch> rules set up at higher levels (config as opposed to your own directory) for specific filenames. So, for example: a rule in config poking a hole for "forbidden.html" (or equivalent name) will be overridden by a <Files *> in htaccess. A rule in config that comprehensively bars everyone from files in .ht (.htaccess, .htpasswd and so on) will be overridden by that same <Files *>. And then you have to make your own <Files> envelopes to restore the rules that you've just wiped out, where you could have avoided the whole problem-- and saved the server some annoyance-- by not having a * in the first place.

Lucy;
In lieu of a <Files *> wrapper for a mod_authz blocklist, what would you use instead, in a shared hosting environment?

Nothing. You don't need a wrapper at all.