Great Circle Associates Majordomo-Workers
(January 1997)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Re: More musings on a general access restriction mechanism
From: Michael Alan Dorman <mdorman @ calder . med . miami . edu>
Date: 06 Jan 1997 09:23:54 -0500
To: majordomo-workers @ GreatCircle . COM
In-reply-to: Jason L Tibbitts III's message of 01 Jan 1997 23:47:33 -0600
References: <199701012226.QAA11113@miaow.risc.sps.mot.com><ufavi9gljbe.fsf@sina.hpc.uh.edu>

Jason L Tibbitts III <tibbs@hpc.uh.edu> writes:
> subscribe
> consult
> ADDRESS_MISMATCH
> 
> subscribe
> allow
> /sps\.mot\.com$/i
> /mcu\.mot\.com$/i
> 
> subscribe
> consult
> ALL

I don't know if this is more powerful or more intiutive, but I like
the way NCSA-derived http servers do this, in that they allow you to
establish your default behavior explicitly and then modify that:

order deny, allow
allow from /(sps|mcu)\.mot\.com$/i

or:

order allow, deny
deny from ADDRESS_MISMATCH

I, at least, find this much more intuitive than the above, which
reminds me of the hosts.allow/hosts.deny stuff, the order of
processing of which I always have to look up.  With the http servers,
I can glance at the config file and know if I'm being paranoid or not
right off the bat.

> As for storing these expressions, I'm not quite sure of how to do
> it.

Maybe you could create a reference to an eval which creates a
subroutine which does the regex---I think that might do what you want,
I'm not sure.

Mike.



Follow-Ups:
References:
Indexed By Date Previous: More open+confirm
From: Oliver Xymoron <oxymoron@waste.org>
Next: Re: More musings on a general access restriction mechanism
From: Jason L Tibbitts III <tibbs@hpc.uh.edu>
Indexed By Thread Previous: Re: More musings on a general access restriction mechanism
From: Brock Rozen <brozen@webdreams.com>
Next: Re: More musings on a general access restriction mechanism
From: Jason L Tibbitts III <tibbs@hpc.uh.edu>

Google
 
Search Internet Search www.greatcircle.com