I did a bit of work and rewrote some things I realized I wasn't liking.
One of them is minor; the GLOBAL list is stored and accessed just like any
other list, which makes a lot of code simpler. This makes it easy for the
parser to validate the correctness of a list and to accept extra meta-lists
like 'ALL' and 'GLOBAL'.
The biggie is that I put together all of the feedback I got on a password
system (thanks, folks), nuked everything that I had written and came up
with this:
Each list (including GLOBAL) has a master password (master_password) that
can do anything. It also has an array (passwords) that let the list owner
create and assign as many passwords as they choose. Each password has a
list of things that it will authorize a user to do. Note that users can
ignore the passwords array completely and run things as they always have
done.
I have yet to decide just what it is that a user can do (moderate, approve
subscriptions, whatever). I'll fill in that list as I add password
checking to the operations. One thing I have done is to tie the concept of
groups of config variables to passwords, so you can have a password that is
only authorized to change digest variables by authorizing a password with
config_digest. config_ALL works too, as does just plain ALL to make
another master password. (I haven't decided if this password should be
able to change passwords or master_password, though.)
Global passwords work on all lists (for the things they are authorized to
do). The global master_password can do anything to any list.
The passwords variable looks like this:
configset list passwords <<END
password1 : action1, action2, action3
password2 : blah, urgh, hurl
END
I wrote a nifty table parser to handle these kinds of things, since I plan
on using this format for several complex variables. It supports much more
than this basic format, though.
The password table is parsed into a big multidimensional hash and stored
away. If the table is later rebuilt (say, when a user updates the password
variables) the old data sticks around for the duration of the run in
addition to the new data.
I mention this last point because it conveniently solves the problem of
what to do when the user changes his password in the middle of a pile of
configset statements. Both the new and old passwords stay active while the
message is parsed.
I will do some more testing, then cut a snapshot in
ftp://ftp.hpc.uh.edu/pub/majordomo/, then move on to archive/file storage
and access, welcome messages, and confirmation tokens.
- J<
Follow-Ups:
|
|
