'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.
Important New Pages
Important Changed Pages
Likely future changes
- Incorporation of Rafael's %!PEOPLEWEB% variable patch
Functionality changes in regstration moved to DakarReleaseNotes
25 Jun 2005
| Package / entrypoint
|| 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
|| 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
|| Implementation would be straightforward
|| Volunteer needed
| RenameTheMainWeb 'peopleWeb' proposal
|| 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?
|| See Develop:Bugs.Item593
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.
- 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)
- 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.
- 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
- I need to check this - I added %PARAM1% ?
- 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.
- 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
How you can help
- 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
- Add your comments to the questions posed below
Issues for consideration
- See my questions on DoubleRegistration
- 03 Oct 2004
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...
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
but stable name for RCS
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?
entries do use the login name - try doing an
to see the
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).
- 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
As for Duplicate WikiNames
): 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.
- 07 Oct 2004
confirms the problem exists...
- 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.
- 05 Nov 2004
Yes, there is a bulkRegister method built-in to the new version.
- 06 Nov 2004
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.
- 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.
- 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.
- 05 Oct 2004
Good. The more we can automate for you the more time you will have to focus on strategic issues.
- 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.
- 27 Oct 2004
Noted, and now implemented. See configure.
- 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
- Confirm email
- Authorise registration
- Complete registration
All sorts of configurations might be wanted, depending on the particulars of the site, for example:
- Register -> Complete
- Preload -> Register -> Complete
- 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?
- 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.
- 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.
- 29 Oct 2004
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?
- 26 Mar 2005
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.)
- 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.
- 18 Oct 2004
1. There are a number of topics in Dakar for changing passwords.
Some tell you what's elsewhere; for example ChangePassword
if you've forgotten your password.
I wonder if there shouldn't be a standard INCLUDE that lists
- Anton, on 1, sounds sensible. -- Main.Crawford.Currie - 26 Mar 2005
asks for your "LoginName" and this is a
mandatory field. The documentation on it at LoginName
correct and up to date except for the situation where the LoginName
are the same.
- 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
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
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
- We could send the registered user a mail letting them know of changes. -- MartinCleaver - 26 Mar 2005
- 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
- Lock topics in Main so that only the named user can edit them by default
- Make it so that only the registration script can make new topics in the Main web
- 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.
- 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
- 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.
- 26 Mar 2005
This is a design issue that needs to be fixed
. I put this back to UnderConstruction
. See Bugs:Item593
- 05 Oct 2005
If someone wants to do this I'd be happy to give some direction.
- 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'.
- 03 Sep 2006