Registration As a Plugin.

MartinCleaver was heard to say in 2004:

I've now done enough RegisterCgiScriptRewrite to believe that registration should be a pluggable system. However, it would be foolish of me to write all the code only for someone to later point out a flaw in my thinking or for the CoreTeam to reject my efforts. Therefore, I'd like some:

1. feedback
2. endorsement

I want pluggable registration, and I want it soon, and others have collected some requirements which would fit. Many thanks, Martin, for doing RegisterCgiScriptRewrite for DakarRelease. This sorted out registration code to an extent where an old Perl programmer but TWiki newbie (like me) has a chance to step in. This topic about pluggable registration, together with RegisterCgiScriptRewrite, gives a lot of technical insight, though some issues may be obsolete now that DakarRelease is about to be finished. I doubt that I'd manage to update it. For the next release, let me step back a little and consider what should be done from an administrators point of view in RegistrationAsPluginRequirements.

-- HaraldJoerg - 12 Nov 2005

Proposal

I propose:

1. Registration information (i.e. TWikiRegistration ) should fill meta data, not content data
   • For registration data to be searchable it must have a recognisable format. I've noticed users either (1) reorder the "fields" on a content-based table or (2) not edit the text on their topics because they thought they would break something. Neither situation is acceptable when you want people (especially new ones) engaged in an intuitive and robust system.
     • I have one install using SEARCHes where user's name, tel, email, messenger address as pulled out of home topics. Really, nearly no one updates their home pages and of those who do, some put HTML and all sorts around the field data and thus don't appear in the SEARCH summary result.
     • Maybe it is possible to write a SEARCH to extract fields from an InTopicTable regardless of which order they appear in. Maybe its possible with FQP. I don't know. But all this data seems like formfield() to me.
   • Validation - there are built in mechanisms
   • Drop down lists, checkboxes, textareas, etc are easier to build when using the forms system.
   • InTopicTables are ugly before being saved
   • Triggered updates, dealt with by a plugin below, seem a lot more robust when you know there is an API to deal with form fields.

1. The People web will be restricted to only contain user/group information
   • The Main web may continue to exist, but there will be nothing about users about it
   • Only the TWikiAdminGroup (and the RegistrationPlugin) will be allowed to rename topics
2. The DefaultRegistrationPlugin would have an TopicSavedHandler that examined the content of the following form fields, and would execute the following rules:
   1. if emailAddress field changed:
      1. validate the new email address and get permission from the old address * i.e. send something secret to both addresses, expect them to click on it.
      2. once confirmed, send confirmation email to both addresses
   2. if loginName field changed:
      1. create a new htpasswd/twikiusers entry
      2. delete the old htpasswd/twikiusers entry
      3. send confirmation email to user's email address
      • N.B. loginName would be stored on the user's form, but we'd need a way to make the field hidden from other users
   3. if password fields changed:
      1. replace the htpasswd entry
      2. send confirmation email to user's email address
      • N.B. password not be stored on the user's form
   4. if wikiname field changed:
      1. do a ProgrammaticRename of all occurances of the users topic
      2. replace the htpasswd entry
3. This would necessarily mean that ONLY THE USER (or sysadmin) WILL BE ABLE TO CHANGE THE HOME TOPIC
   1. Necessarily this means we rely on TWiki's authorisation system to ensure access
4. LoginNamesShouldNotBeWikiNames: loginnames would no longer be restricted to WikiNames on internet installations: the user could chose any lowercase latin1 string, including EmailAddressAsLogin. WikiNamesWithUmlauts would also be possible.

Benefits

1. Registration is pluggable - take as much or as little as you want, tailor to specific implementation data and workflow requirements, reduce the size of the core.
2. Registration data is correlatable using form queries instead of dodgy and fragile SEARCH queries
3. User pages look more professional

Areas affected

1. Decoupled WikiNames from being their logins: LoginNamesShouldNotBeWikiNames
2. RegisterCgiScript
3. InstallPasswordCgiScript : deleted
4. ResetPasswordCgiScript : deleted
5. VerifyPasswordCgiScript (from patch) : not used
6. Many templates

Implementation

1. See RegisterCgiScriptRewrite for a partial rewrite. Note that that project has halted until I get feedback and endorsement/(or not) for this proposal.

Caveats

1. This is incompatible with UsingFormsForSettings until AllowMultipleForms is implemented. I assume that having those in form data is less important than having main fields there. (I've seen newbies scared to alter their home page if there is field data in them... at least we can default their settings. If they want to learn settings then they are not a newbie).

Other ideas

• Creating a new topic in the People web would be initially disabled (though ideally it would invoke the plugin to lead through creation of a new user).

-- MartinCleaver - 12 Oct 2004

We could have UsingFormsForSettings if the settings were stored on separate topics to the user page.

• Seems a bit clunky, but I agree it would work. Thanks for the suggestion. We could put a different form on the settings pages to keep them apart from the users home topics in the same web.

If you could then disallow normal editing and only allow UsingFormsForSettings for those pages, but not allow editing of the ALLOWTOPICEDIT setting then you could secure the settings from anyone but the user. I know having permissions on form fields has been discussed before but I can't remember where.

• Ok, thanks. I'll look for it - if anyone else knows where this is discussed I'd appreciate a pointer.

If ALLOWTOPICVIEW was secure you could also hide email address.

-- SamHasler - 12 Oct 2004

It's not clear if your proposal is a precondition for the rewrite, or an additional proposal.

• I have got so far, and think that to finish it properly I want to take a different route. I need to know which way to turn now.

There's a couple of things I'm not comfy with. (answers q's deleted - MC)

1. the remodelling of the Main web (extracting users to People) is anti-mission, which aims to keep old data compatible with new releases.
   • Sure, hence this topic. Would it be accepted if it continued to support the old way but made this way the new default?
2. you don't mention a UserObjectModel, which worries me slightly.
   • True, I didn't. The cursory user.getXField() would be trivial - just pull it from the form.

Apart from that, I think it's great that you take the initiative to get this area cleared up. It's been a source of confusion for me for a long time.

• Thanks, it has taken me a lot of thinking through, and a fair amount of time to code. -- MartinCleaver - 13 Oct 2004

-- CrawfordCurrie - 13 Oct 2004