Tags:

tag this topic create new tag

view all tags

Rewrite of the RegisterCgiScript

KevinAtkinson's good work has been merged into the DevelopBranch. Much documentation has moved from here and into the code.

I have suspended the RegistrationAsPlugin proposal until consensus changes.

Changes

Improved Tools

• TWikiRegistration

New Tools

• BulkRegistration
• BulkResetPassword

Important New Pages

• LoginName
• UserList

Important Changed Pages

• WikiName
• TWikiUsers

Likely future changes

• Incorporation of Rafael's %!PEOPLEWEB% variable patch

Functionality changes in regstration moved to DakarReleaseNotes -- CrawfordCurrie 25 Jun 2005

To Do

Package / entrypoint	Issue	Impact	Likelihood	Waiting for	Assigned to
RegisterDotPm / writeRegistrationDetailsToTopic	Form fields passed in registration that do not* appear in the form should get left in the content, only comment currently gets left in the content	Registration field content could get lost	Low - administrator would have to misconfigure registration; most admins don't configure registration anyway and default ok	Either: drive registration from the UserForm (preferred) or: create method in forms handling to enquire the names of fields in the form, and match these when writing registration details to topic	-
RegisterDotPm / RegistrationHandler	The name 'RegistrationHandler' is used for something else
RegisterDotPm / RegistrationHandler	Some hardcoding	People have to edit the code to make it auto-attach photos whilst bulk registering
UpgradeTWiki	The code and templates is changed for new installs to use the UserForm , but there is no way to convert bulletfield reg topics into ones using UserForm	New installs will use new functionality, old ones will not have functionality available	High	Implementation would be straightforward	Volunteer needed
RenameTheMainWeb 'peopleWeb' proposal
RegisterDotPm	ApprovingRegistrations	none	-	Now easy though: don't have the user call finish() after confirming their email address - use this to start another WorkFlow to the administrator and wait for the administrator to click til running finish(). We need workflow functionality, else how else can they see what tasks they have to perform?	-
RegisterDotPm	RegisterCgiScriptRewrite	See Develop:Bugs.Item593	Volunteer

Code Structure

The bulk of the code is in TWiki::UI::Register.pm - arguably it belongs in UserDotPm/UsersDotPm; When I first wrote the code it was unclear to me whether I was going to end up maintaining it as a separate stream so I minimised the touchpoints with the main codebase instead of putting things in their final places. When I get time I am gradually moving things to their correct places, so feel free to go ahead and change things: if you care about the code location then you probably have enough nouse to put it in the right place, just document what you have/want to do.

Possible uses for RegistrationHandler

• SiteMinderPlugin has a handler to derive the WikiName from a site-minder specific HTTP variable instead of from REMOTE_USER. To implement the same here you could meld the variable into REMOTE_USER
• Sites with groups of users Main.WhateverUsersGroup for various values of "Whatever" could get added to one or more groups depending on which items on the registration form were filled in. (AntonAylward)

RegisterDotPm

Internal Classes

• UnregisteredUser
  • UnregisteredUser ::getLastError
  • UnregisteredUser ::putRegDetailsByCode
  • UnregisteredUser ::reloadUserContext (names need regularising)
• RegistrationHandler (see RegistrationAsPlugin)
  • RegistrationHandler::deleteKey - API for plugin to delete a form key.
  • RegistrationHandler::register - handed ($row, $meta, $text), returns the same with modifications
  • RegistrationHandler::addPhotoToTopic - for my purposes, calls TWiki::Store::saveAttachment

Topic Changes

• TWiki.ChangePassword
  • Tells them to use their LoginName (findable on TWikiUsers ) to change their password.
  • Still calls ManageCgiScript with action=changePassword
    • Does this allow for both?

• TWiki.ManagingUsers
  • Tells administrators about the use of a Form on TWiki.NewUserTemplate
  • Tells users that resetPassword will send them a system generated password

• TWiki.NewUserTemplate
  • Only the owner or admin can change this page
  • Links to a new GuestBooks.UserNameGuestBook through an include
  • Removed Related Topics about Change password, etc.
  • Uses TWiki.UserForm

• TWiki.ResetPassword
  • Changed wording to be less discouraging about using reset (after all, it does not now need admin assistance)
  • Uses LoginName not WikiName (but allows for both)
  • Tells them that they will get a system-generated email through the mail
    • Next step is actually ChangePassword - silly I can't specify that here.

• TWiki.TWikiRegistration
  • Replaced combined first/last names with separate boxes for each
  • Generates a combined FirstLastName ("Name" / "Name as you want it displayed") field on tabbing into it
  • WikiName generated as before
  • Replaced "Intranet LoginName" with "LoginName". Defaults to lowercase version of WikiName
  • Moved Phone, Office, Department to the TWiki.UserForm

Template Changes

• oopsnotwikiuser.tmpl
  • Refers to LoginName instead of WikiName

• oopsregerr.tmpl
  • ALERT! I need to check this - I added %PARAM1% ?

• oopsregerr.tmpl
  • Now tells them that they might want to ResetPassword if they've tried to re-register, or to go to TWiki.TWikiRegistration if they didn't.

• oopsresetpassword.tmpl
  • Instead of showing them the encrypted password, it tells them that a new system password has been generated and has been emailed to them. It tells them to proceed to TWiki.ChangePassword to make it more memorable.
  • Added an Ok button that takes them to TWiki.ChangePassword

Not done

How you can help

1. Please point out things I need to consider - i.e. look through the topics below and any others, add things to the #Issues_for_consideration list
2. Add your comments to the questions posed below

Issues for consideration

1. See my questions on DoubleRegistration

-- MartinCleaver - 03 Oct 2004

Logging-in with WikiName vs LoginName

As the wikiname is the users' displayed name, it should be whatever they want it to be. It should be as long and as complex as their name is, and be i18n compliant.

As the loginname is how the person logs in, it should be whatever fits in with that person's life. It should be changeable and can be restrained according to browser (e.g. Basic Auth/LDAP login) conditions. The login name can be defaulted, say to their email address, and should be alterable. Email addresses are good for logins because they are remembered and completed by broswers. Another reason LoginNamesShouldNotBeWikiNames is that (it looks like) users with non-ascii characters in their name are currently prevented by Apache's Basic Auth system from having their user topics properly stored even though the limitation is in the login name...

Are RCS entries being written against login name instead of wikiname? It seems so (I can't tell, the terminology used in TWikiDotPm is AWEFULLY inconsistent) but I believe doing so is flawed: login name should allowed to be anything, whereas the rcs log entry should be made against a controlled string. Is WikiName more stable than login name?

This leads to a third requirement though: the need for an RCS-compliant, but stable name for RCS. WikiName is correct in essence but incorrect in storage: it is not 8-bit clean. I venture use a two way mapping function to shunt back and forth.

---

(Comment boxes don't work well when there are no sigs above them...)

I don't see why the login name needs to be so easily changed - typically on an intranet, people have a single user name while they are on that intranet. For Internet use, if they need to create a second account they'll do that. Of course, if the LoginName is an email address, there's a good reason to enable that to be changed, but do we really want an email address in a public page, for spammers to pick up?

Currently, RCS entries do use the login name - try doing an rlog FooPage .txt to see the author field. It's possible that using email addresses as login name will break this anyway, and there may be a length limit.

Not sure of the best approach here, but it seems that making the LoginName acceptable to RCS is important - we could then imply track changes of login name (or create a stable login name when WikiName first created, and allow email address to be the changeable version of the login name).

-- RichardDonkin - 03 Sep 2006

The problem with preload

Once we've decoupled login from WikiName, consider the impact: it's their Display name... their identity - how they like to be known. So during preload, all fields are taken as non-authoritative. The problem is WikiName - what if we preload them with the wrong name? If we've already created the user topic it now needs to be renamed.

So when a user goes to edit during register they must be able to alter wikiname. There are could already be pointers to it though... e.g. on group definitions. So renaming a user has to be supported, and that means we need a ProgrammaticRename facility.

As for Duplicate WikiNames (HowToUseCustomLoginNames): my thought is initially preload with as much information as possible, and file their details under this. If they then register and rename their account, let them do so as long as there is not already an account with the desired name. If the preload fails, append an increasing number until you get an available wikiname. The user can the rename during register if necessary.

-- MartinCleaver - 07 Oct 2004

RenameUser confirms the problem exists...

-- MartinCleaver - 08 Oct 2004

A pre-loader would be nice. A list of people by name or by e-mail address that are either completely pre-registered or have most of the registration process already done for them.

-- AntonAylward - 05 Nov 2004

Yes, there is a bulkRegister method built-in to the new version.

-- MartinCleaver - 06 Nov 2004

No-password configuration

Is your refactored script aware of the two modes of operation? One where the password is supplied (and stored), one without password but where a login name to WikiName mapping is done.

-- PeterThoeny - 05 Oct 2004

Yes. The existing behaviour is preserved. Indeed, if you set up the registration topic appropriately you can have a non-wikiword login with a password. Most newbies are flummoxed by the username is case sensitive rule so I thing this is important.

-- MartinCleaver - 06 Oct 2004

A week later I've concluded that generally LoginNamesShouldNotBeWikiNames, sure keep them for existing installs but newbies have too many problems with them. The existing set up could be selectable.

Support for e-mail verification

For TWiki.org I really would like to have an e-mail verification. Would reduce my workload on assessing and removing goofy registrations.

-- PeterThoeny - 05 Oct 2004

Good. The more we can automate for you the more time you will have to focus on strategic issues.

-- MartinCleaver - 06 Oct 2004

There should be an option to turn off "e-mail verification". Some publics sites that only want registration so their users have a homepage and such don't need that mechanism.

-- RafaelAlvarez - 27 Oct 2004

Noted, and now implemented. See configure.

http://develop.twiki.org/~develop/cgi-bin/view/Bugs/Item156

-- MartinCleaver - 26 Jul 2005

Note that in Cairo if sending of emails fails the user is presented with an error message.

There is quite an array of workflow possibilities:

• Preload registration details
• Invite person to register
• Register
• Confirm email
• Authorise registration
• Complete registration

and:

• ResetPasswordByEmail
• RenameUser

All sorts of configurations might be wanted, depending on the particulars of the site, for example:

1. Register -> Complete
2. Preload -> Register -> Complete
3. Preload -> Invite -> Register -> Complete

To do this properly would require infrastructure support for WorkFlow, ideally table and described on a topic such as TWiki.SystemWorkFlow; how ready is WorkflowAddOn ?

When should the user topic get written?

Different sites might have different rules about when the user topic gets written. e.g. Does it make preloaded/incomplete registration user topics available to other users?

Perhaps readers can give me feedback?

-- MartinCleaver - 27 Jan 2005

Ask for password on the default form

I think the default TWikiRegistration form should be the registrationpub form or at least I think the Default registration form should include a password field even if authentication is not going to be used on the twiki. By asking newly registered users to supply a password on the registration form, at least you have a password on file for that user, if for some reason later on authentication is put into effect for any portion of the twiki (which often seems to happen, to one extent or another) you will already have passwords in place for users who registered prior to its implementation and will save the site admin (and users) the hastle of re-registering in order to access those restricted sections of the site.

A password on file for an unauthenticated twiki would be ignored, and nothing lost, but a user account that doesnt have a password attached to it for a twiki that has recently moved to a more secure authentication policy is a user account that will not be able to access those restricted sections (even if their name is on the list) untill they effectivly re-register with a password.

-- TravisBarker - 27 Oct 2004

I think there ought be NO default - the administrator should be forced to choose. That way when they upgrade nothing overwrites the user registration form.

-- MartinCleaver - 29 Oct 2004

Workflow

The workflow needs to be documented with some nice state transition diagrams.

If I recall, ArthurClemens has done these in the past for other parts of Twiki. Arthur, what did you use?

-- AntonAylward - 26 Mar 2005

RegistrationShouldBeFormTemplateDriven

See RegistrationShouldBeFormTemplateDriven

Design Issues

Change Password

oopschangepassword says "You need to close your browser to make this change take effect." I could force a user to do so but its really nasty for continuity. I wondered whether it was better to force them to do so. (e.g. remove the OK button that takes them back, but as Crawford pointed out, it's better to leave the choice to the user.)

Considerations:

• If they have changed password then what state will authentication be in?
• They will still be authenticated - I want to log them out, but this is not possible.
• Even forcing a window close would not help if they have other browser windows open
• As there is no way to signal back to apache to end the authentication session (log out), and it would be different on different webservers
• Also being logged in as TWikiGuest is not the same as Unauthenticated User

Hence the end of change password is OK - which will leave them logged in as before, but will not have tested their new password.

-- MartinCleaver - 18 Oct 2004

Dissection

1. There are a number of topics in Dakar for changing passwords. Some tell you what's elsewhere; for example ChangePassword suggest ResetPassword if you've forgotten your password.

I wonder if there shouldn't be a standard INCLUDE that lists them all.

• • Anton, on 1, sounds sensible. -- Main.Crawford.Currie - 26 Mar 2005

2. ChangePassword asks for your "LoginName" and this is a mandatory field. The documentation on it at LoginName is correct and up to date except for the situation where the LoginName and WikiName are the same.

* TWikiGuest - TWikiGuest - 05 Sep 2004

This is significant since the Bulk registration puts things in like this unless a login name is explicitly specified.

However my question applies to the "Your LoginName" field in both ResetPassword and ChangePassword.

In each case there is the suggestion to look in TWikiUsers. Why not use a SEARCH statement with suitable formatting to pull out the names? The basic reason why not is the two forms of entry in the TWikiUsers topic, as documented in LoginName.

So why not make this field a TWikiName rather then the LoginName? The software can then map to LoginName.

• • On 2. Sounds reasonable. -- CrawfordCurrie - 26 Mar 2005
  • Actually you can already use either - feel free to rename the label on the dialog. -- MartinCleaver - 26 Mar 2005

Its about usability.

However there is a downside, which is mostly a security issue. The argument is that by telling a hacker who the users are we are giving away clues. My response is that we are already giving away clues with the TWikiUsers file.

• • We could send the registered user a mail letting them know of changes. -- MartinCleaver - 26 Mar 2005

-- AntonAylward - 26 March 2005

Personally I think login names need to be played down as much as possible. There really is no good reason to have the TWikiUsers mapping in a topic, it could equally be in a side file (.twikiusers). That way only wikinames are ever visible. If we were really serious about security, we would have a page where you could ask to be mailed the information. -- CrawfordCurrie - 26 Mar 2005

Home Page Lock Down

Both of:

1. Lock topics in Main so that only the named user can edit them by default
2. Make it so that only the registration script can make new topics in the Main web

-- MartinCleaver - 15 Dec 2003

i think thats a crap option. locking user topics is not-wiki - see the converstaions that occur on c2.com on user topics. a better option might be to store wikiName - email info somewhere else (in a registration only topic / data file. but thats not great either, just better than de-wiki-ing user topics.

eg

• can you edit GrantBow's topic to inform people of his gone-ness?
• can WillNorris fix my spelling mistakes on my topic if he sees them? (thanks Will smile

-- SvenDowideit - 16 Dec 2003

There is also a case for having the authoritative email address not visible either, and if we kept those in TWikiUsers we would not need to lock down the home topics.

-- MartinCleaver - 26 Mar 2005

This is a design issue that needs to be fixed. I put this back to UnderConstruction. See Bugs:Item593

-- PeterThoeny - 05 Oct 2005

If someone wants to do this I'd be happy to give some direction.

-- MartinCleaver - 05 Oct 2005

Commented above about login name stability for RCS.

Re international WikiNames, which is related to this, I think this does need supporting now that we have more flexible authentication in TWiki. This isn't too hard to do, just a matter of tweaking the I18N regexes. There's also a need to use these improved regexes for login name etc in the sandbox code that executes programs such as RCS - see TWiki.UsingI18NInUsernames for the current situation, which is risky on platforms such as Windows that don't have 'safe pipe opens'.

-- RichardDonkin - 03 Sep 2006

ChangeProposalForm
TopicClassification	FeatureRequest
TopicSummary	Major improvements to the registration process
CurrentState	UnderConstruction
OutstandingIssues	Volunteer needed to fix Develop:Bugs.Item593
RelatedTopics	ApprovingRegistrations
InterestedParties
ProposedFor	DakarRelease
TWikiContributors	MartinCleaver

Topic revision: r41 - 2006年09月03日 - RichardDonkin