Item6128: Login names with dots not working properly

We are using the ApacheLogin login manager in our environment. Some users have a DOT in their login names (e.g., first.last). When one of these users edits a topic and saves, the topic author gets set to the cUID and when TWiki displays the author on the topic page it displays the cUID not the twiki name nor the login name. This transformation appears to occur in the mapLogin2cUID function in Users.pm.

I have temporarily changed the line from

    $cUID =~ s/([^a-zA-Z0-9])/'_'.sprintf('%02x', ord($1))/ge;

to

    $cUID =~ s/([^a-zA-Z0-9.])/'_'.sprintf('%02x', ord($1))/ge;
 

Notice the DOT added to the matching statement.

Without this change, the login gets transformed from something like first.last to first_2elast.

I saw this issue reference in Item5118 as having been fixed and it was working fine in Rev 17004 but then stopped working in Rev 17022, the next change that was checked in for Users.pm

Should I stay with my change? What consequences should I look for?

-- TWiki:Main/DougCampbell - 19 Nov 2008

Hi - TWiki:Main/DougCampbell

Not able to replicate this problem on "Revision 17728" release branch. Tried your suggested changes to the code- does not make any difference.

-- SopanShewale - 23 Nov 2008

On further review, I have discovered that this problem is created by myself I had developed an auto-registration plugin and I was using the login not cUID for creating the user.

Thanks!

-- TWiki:Main.DougCampbell - 24 Nov 2008

Actually, it turns out that this is still a problem. If I remove my plugin for auto-registration, things continue not to work properly. One thing I would like to note is that the topic meta data seems to store the cUID and not the loginname. I'm I correct in stating this? If so, what happens is that when I save a topic, the meta data for a DOTTED name gets written as "given_2elast" and when TWiki goes to later on when displaying try to display this back as a WikiName, it can't because it treats this a loginname and it can't find given_2elast in the users page, only given.last.

-- DougCampbell - 24 Nov 2008

Is somebody working on this? As DougCampbell wrote, the cUID is stored in the topic info. As I understand the code, a login or wiki name is expected by renderRevisionInfo (called getCanonicalUserID with the author). It's very confusing. Anyway, the following hack, fixed it for me.

Index: Foswiki/Render.pm
===================================================================
--- Foswiki/Render.pm
+++ Foswiki/Render.pm
@@ -1805,7 +1805,9 @@
     my $un  = '';
     if ($user) {
         my $users = $this->{session}->{users};
-        my $cUID  = $users->getCanonicalUserID($user);
+        my $cUID  = ($user =~ /^[a-zA-Z0-9_]+$/)       # already a cUID?
+               ? $user
+               : $users->getCanonicalUserID($user);
         if ( !$cUID ) {
             my $ln = $users->getLoginName($user);
             $cUID = $user if defined $ln && $ln ne 'unknown';

-- RobertGerlach - 19 Jan 2009

See also: TWikibug:Item6128

I'm quite uncomfortable with your 'hack' because i its doing the wrong thing in the wrong place, but also because I still do not appear to have enough information to reproduce, test and validate any changes.

If you could provide me with more information that we can turn into unit tests, that would be great. (similarly for the groups issue - that one i think is actually harder than this)

-- SvenDowideit - 20 Jan 2009

Yes, it's a hack to show a (working) workaround to the issue. I don't know how to fix it "the right way" (I'm new here and have no complete overview).

To reproduce it, enable ApacheLogin, TopicUserMapping and define an AdminUserLogin. Register a users with a login name that is not the cUID. Now add this user to a group to see the Item5920 issue or login as this user or with AdminUserLogin and create a topic to see this issue.

I many cases the login2cUID hash was filled with wrong mapping (login name => login name or BaseUserMapping _333 => BaseUserMapping _5f333) by using the cUID as login name (I guess).

-- RobertGerlach - 20 Jan 2009

ah, ok, so there is some chance that the fix i made for Item5920 has also resolved this one. cool

but there are related issues out of the box - reset password fails - but tells the user it has succeeded, so there's quite a mess in there.

-- SvenDowideit - 08 Feb 2009

Yes, the patch from Item5920 fixed it. Thanks again.

-- RobertGerlach - 10 Feb 2009

blooming awesome! - and the fix I just commited to setPassword should help for the those that are using a PasswordManager too.

closing, mapping is getting better

-- SvenDowideit - 10 Feb 2009

Thank you! I had been looking for updates to this on the TWiki site forever and it wasn't until I learned of Foswiki that I discovered that this issue had been resolved. I finally got a chance to try upgrading my site and test this and it does work. Appreciate the efforts in fixing it! Thanks again!

-- DougCampbell - 01 Mar 2010