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

[DK]

Vance,

You have obviously made a significant effort into the development of
your MediaWiki extension, and I applaud you for that.  However, I did
alittle research into stable MediaWiki extensions, specifically any
related to controlling access to a page or pages based on user
account.  The PublicCat,
http://www.mediawiki.org/wiki/Extension:PublicCat, extension caught my
interest for this purpose.  What concerns me is the disclaimer stating
that MediaWiki in general is not designed for per page access
restriction and could "easily" be compromised.

I propose a different approach to this effort.

Select an open source membership database application such as:
http://sourceforge.net/projects/clubdata/
http://sourceforge.net/projects/klub/
http://sourceforge.net/projects/zebraz/

Run the selected membership application along side MediaWiki at
www.wplug.org.  Provide authentication to both applications using
OpenID, http://openid.net/.

Comments?

David Kraus


On Sun, Jan 9, 2011 at 1:47 AM, Vance Kochenderfer <vkochend at nyx.net> wrote:
> 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
>
> _______________________________________________
> wplug-internet mailing list
> wplug-internet at wplug.org
> http://www.wplug.org/mailman/listinfo/wplug-internet
>
>