Pluggable Registration - Requirements

Motivation

Registration for a TWiki is the step where someone previously unknown to the TWiki gets his identity - his TWikiName, his personal home page, and his entry in TWikiUsers. In the terminology used in security textbooks registration is the authorisation to use a TWiki. The owner of the TWiki defines the policy (set of rules) which has to be obeyed by those who which to use the resource (the TWiki).

All TWikis are different, and so are the requirements which TWiki admins have regarding the set of rules. Plain WikiCulture suggests that everybody should be able to use a Wiki to read and write. However, in many environments, this is not considered appropriate. ApprovingRegistrations lists quite a few of the scenarios we have to keep in mind, so I'll just summarize:

1. fill registration form, answer an email with a code, receive TWikiName.
2. fill registration form, show me your ID, receive TWikiname.
3. fill registration form, registration manager validates somehow, receive TWikiName.
4. fill registration form, entities in %APPROVEREGISTRATION% approve registration , receive TWikiName.
5. fill registration form, answer an email with a code, entities in %APPROVERGISTRATION% approve registration , receive TWikiName.
6. fill registration form, mail address must be subscribed to a list, receive TWikiName.
7. fill registration form, get checked against a spammer blacklist, receive TWikiName.
   and, last not least, my own hobby horse,
   
8. start editing a page being authenticated but registered, TWiki collects the data it needs, receive TWikiName.

Discussion has been very active in 2002, then again in 2004, when MartinCleaver started his work on RegisterCgiScriptRewrite, but somehow always managed to die away as soon as a release date approached. I don't know what has been achieved in the Cairo release. In DakarRelease, Martin managed to reorganize the code so that it could be understood by newcomers (like me), and incorporated KevinAtkinson's patch for email verification. It's about time to go the next steps: Let the administrators choose how registering new users should take place. Let them select from a predefined set of validation steps, and let them encode their own policy in Perl if they want.

User / Administrator Requirements - Request for Comments

This should be a request for comments for TWiki administrators. Probably the Codev web is the wrong place because this is the home of TWiki developers, who currently are all busy with DakarRelease. Unfortunately I don't know a better place, so here you are.

1. It MUST be possible to plug in any of the validation methods mentioned above, plus a few I've probably never heard of. This does not mean that the code needs to be provided by the TWiki core - doing the validation code might be left as an exercise to the reader.
2. The API for registration plugins MUST be upward compatible so that conforming registration plugins work with newer versions of TWiki without changes.
3. On TWiki upgrade, registered users of previous TWiki releases MUST be included seamlessly in case the format of users' homepages changes.
4. If another instance is in charge for the next step, they MUST be actively informed by mail. Waiting until they eventually read a TWiki topic to take action is not sufficient.
5. Registration MUST support any authentication scheme.
6. A TWiki installation MUST NOT be forced to install CPAN modules for validation procedures they do not use.
7. A reasonable subset of validation procedures SHOULD be included in the TWiki core:
   1. Verification of a user's email address
   2. Approval by a named entity (webmaster or member of Main.TWikiAdminGroup or...)
   3. Check the presence of certain information (e.g. first and last name)
   4. Check against a spammer blacklist of IP addresses / domains
8. It SHOULD be possible to have more than one validation method applied in succession.
9. The TWiki administration SHOULD be allowed to register a bulk of users in one step. (Maybe this should be a MUST because DakarRelease supports it)
10. Bulk registration by the administrators SHOULD be allowed to skip validation steps.
11. Web interfaces showing all open registrations SHOULD be provided.

Feedback about functions you would like to see is encouraged.

-- HaraldJoerg - 16 Nov 2005

This looks good, one thing, looking at #7, I'd like to see is some form of validation based upon e-mailing a site admin, or group of admins, and any of them being able to "click the link" to approve the registration, the process can require more than one admin approve, or any admin approve.

-- ToddGrayson - 25 Nov 2005

Taking #7 and #8: my thoughts are that this should be somewhat like the PAM mechansim in Linux and Solaris, where the order can be specified, parameters can be specified and necessary/sufficient can be specified.

I strongly sugest looking into the PAM model.

-- AntonAylward - 27 Nov 2005