[ Alan Millar writes: ]
>
> Here are some ramblings about the private options. Somebody kick me
> if this is already in 1.94a3
>
> The current "private" options (private_who, private_get, etc) are
> inadequate as they are.
Wilson Chan's thoughts on revamping the entire access interface to
be more coherent hold a lot of appeal, but I doubt that anything all
encompassing as the Netscape server uses will be simpler and easier for
the clueless to configure. Allow/deny probably stretches the limits of
comprehension of a lot of folks I've seen asking for help. I'd like to
see an allow/deny scheme that uses regexps like [no]advertise (and makes
better, if not complete, use of Perl's regexps), but that's probably
also too much unless the regexps were in addition to lists of simple
text strings.
> The solution, from my point of view, is to make them work
> like "restrict_post". Give a list of files instead of a yes/no
> option.
When I needed better control of 'who' on one list I run, that's exactly
the solution I chose.
> There are three cases: (1) no access at all (anonymous), (2) access
> to list members only (those in the files specified), or (3) wide-open
> access (open to non-members). How do you simply, cleanly specify
> all three possible answers in a config file entry?
>
> You could do it with "yes", "no", or a file list, but that would then
> preclude naming a list "yes" or "no". Anyone have a list named "No"?
>
> restrict_post does it by using a blank entry for (3), a list of files
> for (2), and the separate "moderated" config entry for (1).
I did the obvious thing: rather than a separate "moderated" config entry
for case (1), I simply pointed the file list to /dev/null. No one's on
that list so no one gets access (an empty file, named appropriately,
would do as well). Since that's the least useful case (at least the
admin should be able to get access), that's the simplest way to handle
that degenerate case.
I implemented it by making a slight modification to the 'grab_restrict_post'
subroutine, gave it a more fitting name of 'grab_file_list', and pointed
the 'private_who' action to it. In majordomo I replaced the 'cf_ck_bool'
call with a loop to grep the listed files for the 'addr_match'. If there
were no matches, then it returns a polite message denying access. It
could probably even be cleaned up a little to make the grep loop a
common subroutine for use by all the private options.
--
Dave Wolfe *Not a spokesman for Motorola*
Motorola MMTG 6501 Wm. Cannon Dr. W. OE112 Austin TX 78735-8598
Follow-Ups:
|
|
