On Sat, 19 Apr 1997, Rob Hartill wrote:
> * access from *.x.y allowed, except that
> * access from specific (public-access) systems in *.x.y should be forbidden
> * access from outside *.x.y should be forbidden
>
> With the facilities as currently documented - i.e. with initial state
> unspecified, there would be no way to achieve the required access controls:
> it would be necessary to "allow from .x.y" but also to be able to "deny from
> all" (to block general access) and "deny from a.x.y b.x.y".
The answer is simply to use 'mutual-failure' on the allow line. Note I
*haven't* mailed the user.
> PS While attempting to check the above with the source code (couldn't see how
> it worked...), I noticed that
>
> allow from user-agents Lynx
>
> (for example) is supported by the code but undocumented. Also some sort of
> test on environment variables, though that either doesn't work or didn't test
> what I thought it was testing... Out of curiosity, are these new features
My _dim_ recollection of this they we were going to get rid of this and
use BrowserMatch x/allow from env=x instead. This is one of the things I
noted needed documenting (and possible FAQing). I think "allow from
user-agents" is too specific.
Anyone remember my mod_setenvif module? It sets env-vars based on
arbitrary regular expression matching against incoming headers and other
values (e.g. the remote host) (its a generic BrowserMatch). This can be
used to implement the reg-exp matching he wants, with the advantage of
being pretty generic for other uses. For example - to allow from hosts in
the x.y domain _except_ those which match public.*.x.y:
SetEnvIf remote_host /.*\.x\.y/ isprivate=1
SetEnvIf remote_host /^public\..*\.x\.y$/ isprivate=0
...
order allow,deny
deny from all
allow from env=ispublic
I think (actually this doesn't quite work since the env=X checking looks
to see if the envvar has a value, not whether the value is zero. Shame).
//pcs