Feature Proposal: Ignore differences in case between registration and login

Motivation

LDAP and many Windows based authentication schemes are case-insensitive. This forces TWiki users to remember exactly how their login name is written.

Description and Documentation

When mapping login names to user names, ignore case.

Examples

The following content has been moved from a support question Support.CaseInsensitiveUserMapping:

Question

How can I match a user's wiki name to his login name in a case-insensitive way?

For example, given this line in the TWikiUsers page:

• AndrewBanks - abanks - 1 Jun 2006

how can I get TWiki to say the user is AndrewBanks whether he signs in as abanks, Abanks, or ABanks?

Because I use the LdapContrib plugin and because LDAP is case-insensitive, he is allowed in however he types his username. But the topics that he edits are not signed AndrewBanks unless he uses all lower case, as I have in the TWikiUsers topic. If he types ABanks then it calls him Main.ABanks.

Please do not advise me to use the LdapUserMapping module. It is too slow without ModPerl, and TWiki is too flakey with ModPerl

-- AndrewBanks - 14 Nov 2006

Impact and Available Solutions

WhatDoesItAffect:	Auth, Security %WHATDOESITAFFECT%	edit
AffectedExtensions:	%AFFECTEDEXTENSIONS%	edit
HaveQuickFixFor:	TWiki 4.0	edit

Implementation

I don't know what I'm breaking but this works:

--- Users.pm.bak        2006-11-20 19:03:41.000000000 -0600
+++ Users.pm    2006-11-20 19:05:20.000000000 -0600
@@ -311,6 +311,7 @@
     return undef unless $loginUser;

     $loginUser =~ s/$TWiki::cfg{NameFilter}//go;
+    $loginUser = lc($loginUser);
     return $this->{usermappingmanager}->lookupLoginName($loginUser);

 }

-- AndrewBanks - 21 Nov 2006

-- Contributors: AndrewBanks

Discussion

The same problem - login names are case-insensitive - is occurring frequently in Windows environments like mod_ntlm or mod_auth_kerb with ApacheLogin. Given that these environment are frequently encountered, I'd say that there is enough reason to introduce Yet Another Configurable option. This should be filed as a feature request. For Version 4.0x or 4.1 this is too late, but probably a one-line patch would do for you:

   $ENV{REMOTE_USER}  =  lc $ENV{REMOTE_USER};

Where to add the hack is a question of taste and your environment. Without a persistent accelerator bin/LocalLib.cfg would be an option, because that file is read early enough and will never be touched by upcoming hotfixes, with mod_perl or similar you'd have to insert it into one of the core modules.

• Ouch - I just noticed that you mentioned LdapContrib. In my reply I assumed that you are nevertheless using ApacheLogin as LoginManager - if not, just forget what I've written...

-- HaraldJoerg - 16 Nov 2006

I also have this problem. My users also authenticate with LDAP. Ie. normal Apache auth with LDAP all taken care of by Apache.

LDAP is not case sensitive so people get authenticated. But they are only mapped to the right Legacy.WikiName if they enter their username in same case as when they registered.

• Users often register with upper case letters. We have silly usernames like C12345 or c12345 and ABC345 which is equivalent to abc345. I always monitor these registrations and alter their user ID to lower case.
• People randomly login with uppercase and lowercase and find themselves unable to edit topics because they are not mapped to their Legacy.WikiName.

So far my only work around has been training. But TWiki should be able to handle this.

I support a config option that makes the user mapping not case sensitive. Just converting to lower case only works if you registered lower case. So it is probably best to...

• Either have the feature convert both registration and login to lower case.
• Or match the login name with the name in TWikiUsers case-insensitively and then change the login name to match the case used in TWikiUsers.

Above hack should be good for the login case but not the registration case. But I will actually consider trying this little hack on our Motorola installation. It can save me 1-2 user support calls per week.

I have made a link from TWikiFeature04x02 so we can consider this feature for 4.2.

If we just make the user mapping permanently non-case-sensitive. Would it actually have to be configurable? Would it ever harm to just have it like this always? We would save yet another config option and yet another thing for a new admin to worry about.

-- KennethLavrsen - 21 Nov 2006

I agree - preserving case and doing case insensitive comparison should do the trick. I was afraid of large installations doing disambiguation of persons with identical first/surnames by case only (JohnDoe vs. JohnDOE), but that would be a really bad idea. The change would then be moved from Users.pm to the user mapping managers, so technically the proposal reads:

• Let lib/TWiki/Users/TWikiUserMapping.pm do case insensitive lookup when mapping login names to Wiki names.

Shouldn't be too difficult to do, including test cases and documentation.

-- HaraldJoerg - 22 Nov 2006

The way the TWikiUSerMapping is implemented is that a double hash is created and cached in memory with the mapping between Legacy.WikiName and login name. Once this is created the actual lookup is not a comparison but a direct lookup using the login name as the key for getting the Legacy.WikiName. This is very smart as it is very fast.

So it seems that the practical fix would be to convert the TWikiUsers topic's login name to lower case when you build the hash for mapping Login name to Legacy.WikiName. Probably not needed/wanted the other way.

I cannot see if there are other negative unwanted consequences of doing this. Sven who last altered this part of the code most likely have a better overview on this and can comment.

Doing a conversion to lower case when building the hash could have a very negative effect on the performance when you have many users. This should be timed. If you convert at registration this effect would be eliminated.

This is the code that builds the hashes.

sub _cacheUser {
    my($this, $web, $wUser, $lUser) = @_;
    $web ||= $TWiki::cfg{UsersWebName};
    $lUser ||= $wUser;   # userid
    # FIXME: Should filter in for security...
    # SMELL: filter prevents use of password managers with wierd usernames,
    # like the DOMAIN\username used in the swamp of despair.
    $lUser =~ s/$TWiki::cfg{NameFilter}//go;
    my $wwn = $web.'.'.$wUser;
    $this->{U2W}{$lUser} = $wwn;
    $this->{W2U}{$wwn} = $lUser;
}

and this is the simple and fast code that does the lookup.

sub lookupLoginName {
    my ($this, $loginUser) = @_;

    $this->_loadMapping();
    return $this->{U2W}{$loginUser};
}

-- KennethLavrsen - 22 Nov 2006

I guess this one deserves a little attention unless we just drop it.

The current status is

• We agree not to convert to lower case during registration
• We agree that the desired behaviour is that login name is mapped to WikiName case-insensitively
• Building the hash by converting to lowercase prevent preserving could be done by creating the $this->{U2W} hash by converting the $lUser to lowercase and looking up converting $loginUser to lowercase IF and only if login name is not wikiname. But the fear is that the conversion has a major performance hit to sites with many users as this is done quite many times.
• KennethLavrsen thinks this should be parked and considered in the scope of finding a more efficient mapping between username/WikiName/email than we have today.

-- KennethLavrsen - 26 Mar 2007

I think this issue should be added to the grab bag for me at AddTWikiAdminUser. as It's somewhat related. it also seems somewhat releated to TopicCaseSensitivity...

-- SvenDowideit - 26 Mar 2007

Is this part of the work you have done or is this deferred to Georgetown?

-- KennethLavrsen - 28 May 2007

Is this part of the work you are implenting with the user mapping or is it deferred to Georgetown.

If you have made the work put it in MergedToCore.

If you are still working on it then you are naturally OK to finish the work - then put it in UnderConstruction

If you have not started then sorry, you did not make the deadline and it is deferred to Georgetown per release meeting decision.

-- KennethLavrsen - 28 May 2007

No reaction. Sadly

gotta say, i haven't seen this topic since march. so i totally did not see Kenneth's changes of the 28th. I guess that there were alot of other topic changes that day? or was that last weekend when i was away friday-monday?

-- SvenDowideit - 03 Jun 2007

Sven, you committed to this in 2007. Do you want to revisit? Should we plan for 1.2?

-- CrawfordCurrie - 17 Feb 2012

Note that with the changes to do better validation of registration parameters, there is a new routine in the Mapper API - validateRegistrationField that is called for each field in the registration request. It can be used to apply changes like "lc" to the input fields.

-- GeorgeClark - 17 Feb 2012

Changed to Parked, needs developer to adopt.

-- Main.GeorgeClark - 19 Nov 2015 - 15:29

Commenting is disabled while not logged in