[pmwiki-users] Self registration

The Editor editor at fast.st
Wed Jan 21 16:15:20 CST 2009


On Wed, Jan 21, 2009 at 4:09 PM, Swift, Chris <Chris.Swift at eu.dodea.edu> wrote:
> I highly appreciate everyone's comments on self-registration as that was one
> of my greatest hurdles in the wiki world.  I've found a great number of
> people turned off by the idea that there were many extras needed in order to
> incorporate a self-registration.
>
> Having said that, I think a self-registration should have:
>
> 1.  Complete security and privacy for both the person that is signing up and
> for the administrator
> 2.  A function that would allow for the administrator to accept or deny the
> signup (this would be either enabled or disabled by the admin)
> 3.  An ability to allow you to ask whatever information deemed necessary for
> the person signing up (e-mail, phone number, first name, last name, etc.)
> 4.  A way that all of this could be automated so that the admin has the
> least amount of work (which is the point of the wiki anyway since its author
> driven)
> 5.  There should also be a way that all of this stored information would be
> available to create list groups, etc.
>
> Anyway, so far I have found only 2 recipes that will do all of these (and
> more):
>
> http://www.pmwiki.org/wiki/Cookbook/AuthUserSignup
>
> and
>
> ZAP
>
> Maybe both of these recipes could be building blocks for a
> self-registration.


Since ZAP was mentioned I thought I'd chime in...  First, all of these
things people are asking are certainly doable. They've been part of
BoltWire from the start. And when still supporting ZAP, all these
things were doable in PmWiki, and probably fixable if somehow the code
has been outdated. However I'd recommend a different direction for
several reasons:

1) You already have the htpasswordform recipe which is quite good,
mature, and has certain built in security advantages.  In my
experience, PmWiki admin's place an especially high value on security.
2) PmWiki's structure does not lend itself to the kind of form's
processing ZAP uses, hurdles not easily solvable without a paradigm
shift in PmWiki. The htpasswordform recipe fits more closely into the
existing paradigm.

Having said all this, BoltWire stores login password information on
profile pages and it works very well (to keep all account info
centralized in one user page), but because of two slightly different
features:

1) The data fields are not visible in the source code of the page, but
in a part of the page that is only available via a form. This could be
done however in PmWiki if the passwords were stored as a page
attribute, and not in the page content.
2) BoltWire has a different authorization system which allows admins
to contral which users/groups can view specific data fields, so access
to fields like passwords and emails can be easily limited to owners.
Doable in PmWiki, I'm sure, but it's not there now.

There are other differences, but to just be realistic--htpasswdform is
a much better fit with PmWiki than the ZAP approach, as much as I
prefer and use it myself.  Being familiar with both approaches (my
first PmWiki recipe was a hack of htpasswdform to allow
self-registration--before it was possible), I think it would be wise
to go with the system that matches the code best.

Granted, htpasswdform won't do everything Christ wanted, but it would
probably make a better building block than ZAP for developing whatever
is lacking.

Cheers,
Dan



More information about the pmwiki-users mailing list