[wplug-board] WPLUG's information assets (membership rolls - part 2 of 3)

[Vance Kochenderfer]

My plan to upgrade our membership tracking system was to develop
a web interface (or reuse someone else's) that would fulfil the
following design goals:

A. Give members access to view their own information, and permit
people to sign up online or make changes to their information.

B. Restrict access to other members' information only to trusted
individuals designated as admins (at least the Secretary).

C. Following on A and B, integrate authentication with MediaWiki
to avoid forcing members to create Yet Another Username and
Password to gain access.

D. Centralize the location of the canonical membership rolls so
that the Secretary is not a single point of failure.  Others can
be granted admin status.

E. Require approval by an admin for new signups and changes to
take effect.  This is to permit the Secretary to coordinate with
the Treasurer for renewals, new applications, etc.  It is also to
deter shenanigans.

F. Maintain a complete history of changes.  This will permit the
rollback of erroneous entries made accidentally or maliciously.

G. Automatically give people a 90-day and 30-day notice that their
memberships are expiring.

H. Automatically manage subscriptions to the wplug-members mailing
list based on the latest data in the system.

I could not find an existing extension for MediaWiki which
accomplishes or even closely approximates these goals, so I
started work on developing one.  It is possible that one has
appeared since I last worked on this (about two years ago).
Attached is what I have so far.  It should be considered pre-alpha
stage code.

Currently, it does not address goals G and H.  I had planned to
write a separate script to be run by cron which would accomplish
those.  While the code is basically feature-complete for goals A
through F, it is still untested.  I know that some additional work
is needed to integrate it properly into MediaWiki as an extension.

To avoid making this message any longer, I have separated out the
technical discussion of how the system works to a separate readme
file that is also attached.  Please have a look at it.

Of course, placing this data on the web raises additional attack
vectors.  The full member rolls are stored in a database table, as
well as historical data.  Again, anyone with root access on the
server can get them.  Access via the new interface page is limited
to users in a special wiki user group called "memxadmin" (note
that this is for wiki accounts, not login accounts on the server).
Those admins added to this group will have full access, as well
any wiki user in the "Sysop" group (because they can add
themselves to any group).

There is also the possibility of sniffing the unencrypted HTTP
traffic of an admin while he's accessing the site.  In addition,
anyone with a login account on the server who can obtain the
database credentials will be able to access the table holding
member information.  These are stored in the MediaWiki config
file AdminSettings.php.  It is currently readable by any login
account, though I believe it would be a simple matter to make it
readable only to the apache user.

My personal view is that we already invest a high level of trust
in those individuals who have "Sysop" access to the wiki and root
access to the server.  I am comfortable with the possibility that
they may also access member information.  We only require that
members provide their name and e-mail address in order to join.
If they have specific privacy concerns, they are free to decline
to provide other information.  (It is also possible to remove
historical information from the database should an individual's
situation so require.  This is a manual process, though.)

The benefits gained are:

1. Greater transparency to members as to their current details and
expiration date.  Currently, they have to request this information
from the Secretary.

2. Ability to designate more than one person to approve new
members or changes to existing member information.  Currently, the
Secretary is a single point of failure on updating the membership
rolls.  As an example, two members joined on Saturday but I have
not updated the rolls yet.

3. Following on point 2, give others the ability to generate an
up-to-date membership list if one is necessary for conducting
WPLUG business.  Currently, the Secretary is the sole repository
for the authoritative list, at least until he uploads it to the
server.

4. Automatic notification of expiration dates to members.  Under
the current system, the Secretary must remember to manually send
out notices.

5. Requiring members to have a wiki account may encourage them to
participate more in editing the wiki.

I believe that these benefits weigh in favor of implementing my
proposed system.  I recognize that it does create an increased
risk of information leakage.  However, I think the risk is not out
of balance with the sensitivity of the information.

Please reply with your comments on the validity of the approach
and any alternative proposals you may have.  Also, comments on the
specific code itself are welcome, if we decide this is the correct
path.

Vance Kochenderfer        |  "Get me out of these ropes and into a
vkochend at nyx.net          |   good belt of Scotch"    -Nick Danger
-------------- next part --------------
A non-text attachment was scrubbed...
Name: memx.zip
Type: application/octet-stream
Size: 9806 bytes
Desc: ZIP archive
Url : http://www.wplug.org/pipermail/wplug-board/attachments/20110108/7e932552/attachment.obj 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: memx_readme.txt
Url: http://www.wplug.org/pipermail/wplug-board/attachments/20110108/7e932552/attachment.txt