User Objects

Motivation

Every time I touch any code to do with users I get frustrated by the way user handling is splattered across the code. The UserDotPm module is very restricted in its scope. User handling badly needs tidying up.

Also, plugins are forced to know about UserNames and WikiNames, the translation between them is rather clunky, and there's no way to recover simple user information - the sort of thing that LDAP would provide - such as email address and per-user preferences.

Proposal - new objects

What I'd really like is to have a User object: For example,

TWiki::User

package TWiki::User {
   sub new( String username, String wikiName, String emailAddress );

   sub getWikiName() => String; # _without_ web name
   sub getUserName() => String;

   sub sendEmail( String emailBody ) => error string;

   sub resetPassword();
   sub changePassword($oldPassword, $newPassword); => success / failure
}

TWiki::UserManager

package TWiki::UserManager {
   sub new( String userWeb ); # load all users from the given web

   sub getUserFromUsername( String username ) => User object;
   sub getUserFromWikiName( String wikiname ) => User object; # wikiname with or without web

   # get the preferences of user
   sub getPreferences() => TWiki::Prefs object; 

   # get the current user, from a cookie or other session item
   # or TWikiGuest if no session info available
   sub getCurrentUser() => User;

   # get the user after authentication. This method does nothing unless the
   # user is TWikiGuest, in which case it goes through an authentication
   # cycle and may return a different user.
   sub authenticater( User user ) => User;
}

These objects would of course be published across the interface to plugins, to allow them access to these basic user operations.

This should solve the arguments about canonical user names as well. it would also allow us to easily plug in different user implementations; I can imagine one that goes straight back to an LDAP server, for example.

Another angle would be the authentication of users using different methods. For example, you might have editors authenticated by LDAP and writers by htpasswd registration.

-- CrawfordCurrie - 10 Oct 2004

I agree. I just decided that much of the code I moved from RegisterCgiScript to RegisterDotPm actually belongs in UserDotPm.

I'll move some stuff as part of the RegisterCgiScriptRewrite, and will incorporate whatever I can from here in the process, but as I am running out of time it'll be necessarily incomplete.

RenameUser is very likely to appear, as is the ability to choose to log-in by email address or arbitrary login names. This is implemented.

-- MartinCleaver - 10 Oct 2004

Access.pm should work in terms of User objects as well. Would be a lot easier all round.

-- CrawfordCurrie - 10 Oct 2004

Extensible, queryable, attributes

Apart from the LoginName and WikiName, I'd make it fetch any other sought values from the user MetaData on the home page.

i.e. $user->Town would get the Town field from the User's page.

-- MartinCleaver - 16 Oct 2004

No. That's exactly how I would do it, myself.

-- CrawfordCurrie - 16 Oct 2004

indeed, more ReflexiveProgramming would be a good thing for twiki (especially with all the data fields)

-- WillNorris - 16 Oct 2004

I just discovered how TWiki hardcodes the mappings it supports. Before I change this - am I right in thinking that is only Email that is pulled from the user topics?

I need to know because the RegisterCgiScriptRewrite involves a move from BulletFields to FormFields.

Unless we sort out modularity such rewrites become a long tail-chasing exercise. I had no idea that I'd broken TWiki::getEmailOfUser() until I went to use it during testing of ResetPasswordByEmail

-- MartinCleaver - 17 Oct 2004

Currently, yes, though I can see a requirement for any and all other fields. Note that it is critically important to be able to override the User interface with an LDAP implementation, so bear that in mind.

-- CrawfordCurrie - 17 Oct 2004

Ok. Good point, thanks. I'll probably make two implementations from the outset anyway - one for BulletFields and another for FormFields. We'll need a DelegatePattern mechanism here anyway to cater for when MultipleFormsPerTopic mean a change of the Meta variable names.

-- MartinCleaver - 17 Oct 2004

Why not add code to migrate BulletFields into FormFields and reduce the cruft.

-- SvenDowideit - 17 Oct 2004

That's what the RegisterCgiScript does: it uses FormFields if there is a form attached to the TWiki.NewUserTemplate. I'd have stripped the old implementation but there is no point me talking about any of this unless I get feedback.

-- MartinCleaver - 07 Nov 2004

gotta love it. you won't get feedback unless you advertise it positivly, but you've decided to shoot yourself in the foot instead. cool

-- SvenDowideit - 08 Nov 2004

TWikiRelease04x00x00 has some UserObjectModel features, but I need more:

Password and email information has been abstracted into a TWiki::User::Password handler, but there is still an assumption written into TWiki::User and TWiki::Users that users and groups are defined in USERWEB as twiki topics. I have made a functioning change that removes this assumption, and instead get the user and groups info from a Joomla Database. So far, its a hack, because there is code spread out over a number of places.

-- SvenDowideit - 09 Feb 2006

I've just commited an initial extraction of the TWikiUserManager.pm code into the DevelopBranch see: Bugs:Item1651. Along the way ObjectOrientedTWikiPluginSystem has come up as a potentially better way to over-ride TWikiCore functionality.

Next step is going to be to add a way to disable changing User info/groups and passords, either to lock down a site, or for those implementations that do this function through another interface (thus it will be a mix of a configure setting, and code in the implementation class).

-- SvenDowideit - 15 Feb 2006

In upgrading this topic to ChangeProposalForm I've calssified it as a CodeRefactor and it's state as UnderConstruction, I hope that's correct.

-- SamHasler - 29 Apr 2006