Tags:
create new tag
, view all tags

Question

We have some users with a dot in the loginname, e.g. james.bond. When filling the LDAP cache everyting is fine, the correct entries are added.

Strange things happen when TWiki tries to lookupWikiName() (TWiki/Users/LdapUserMapping.pm) from login name. Example log output:

constructed a new LdapContrib object
cacheAge=11105, lastUpdate=1209544138, refresh=0
called getLoginName(james.bond)
called lookupWikiName(bond)
asking SUPER
called getLoginName(james_46bond)
called lookupWikiName(james_46bond)
asking SUPER
called lookupLoginName(james_46bond)
asking SUPER
returning jamesbond

I understand the first clipping, where the code tries to remove a prepended TWiki web identifier. (I tried to block this, but was not successful.)

Then there follows a second try where the dot is encoded as _46. How can I stop this, resp. what can I do to get JamesBond as return value? Could modifying {LoginNameFilterIn} or {Ldap}{NormalizeLoginName} help?

Thanks for your support.

P.S.: MapApacheUserWithDotToWikiUser seems to be a different problem.

Environment

TWiki version: TWikiRelease04x02x00
TWiki plugins: DefaultPlugin, EmptyPlugin, InterwikiPlugin, LdapContrib, LdapNgPlugin, NewUserPlugin
Server OS:  
Web server:  
Perl version:  
Client OS:  
Web Browser:  
Categories: Registration

-- AlexanderStedile - 30 Apr 2008

Answer

ALERT! If you answer a question - or someone answered one of your questions - please remember to edit the page and set the status to answered. The status selector is below the edit box.

Does anybody know, in which module the loginname might be encoded? I could not find it yet.

-- AlexanderStedile - 01 May 2008

LoginNameStylesDifferentEffects seems to be the same problem.

-- AlexanderStedile - 02 May 2008

I had the same issue and made an ugly hack to fix this.

Add the following to the getWikiNameOfLogin function located in the file LdapContrib.pm

$loginName =~ s/\_46/\./g;

Add this between

$loginName = lc($loginName);

and this

return TWiki::Sandbox::untaintUnchecked($this->{data}{"U2W::$loginName"});

The number 46 is the ASCII code for a period. It gets converted somewhere.

-- AlexWong - 30 May 2008

I traced this back, and it seems to get converted in TWiki::Users::forceCUID. I think TWiki::Users has an unmet expectation regarding the login name coming from the UserMapper. See this log, where initialiseUser uses forceCUID to reformat the login name:

called checkCacheForLoginName(james.bond)
TWiki::Users::getCanonicalUserID(james.bond), stored login=
TWiki::Users::getCanonicalUserID(james.bond) TWiki::Users::LdapUserMapping=HASH(0x18b5340)=>james.bond
LdapUserMapping::getLoginName(james.bond)
LdapUserMapping::lookupWikiName(james.bond)
TWiki::Users::getCanonicalUserID(james.bond) => james.bond
TWiki::Users::initialiseUser(james.bond), cUID=james_46bond
TWiki::Users::getCanonicalUserID(james_46bond), stored login=
LdapUserMapping::getLoginName(james_46bond)
LdapUserMapping::lookupWikiName(james_46bond)
TWiki::Users::getCanonicalUserID(james_46bond) TWiki::Users::LdapUserMapping=HASH(0x18b5340)=>james_46bond
In any case, I added the hack AlexWong suggested to fix the problem.

-- MattEverson - 04 Jun 2008

After more research, I did find the cause of this. The TWiki::Users facade gets a request, and turns to your selected mapper. The standard TWikiUserMapping pulls login names and wiki names from the Main.UserList page, where all the data already conform to canonical UID specifications. LdapUserMapping passes data straight in without checking. The easiest place to change this is in the LdapContrib.pm module. To fix this you need to translate wiki names back from cUID form as AlexWong said, and also translate login names into cUID form for access list checks. If you don't perform the second translation, you will not be able to use LDAP groups in access lists.

To turn login names into cUIDs in LdapContrib, open LdapContrib::getGroupMembers, and put

$members =~ s/\./_46/g;

right before

my @members = split(/,/, $members);

-- MattEverson - 05 Jun 2008

Hi,

I have the same problem, I add the two lines

  • "$members =~ s/\./_46/g;" in getGroupMembers
  • "$loginName =~ s/\_46/\./g;" in getWikiNameOfLogin

I have the following configuration :

  • {Ldap}{NormalizeWikiNames} = 1;
  • {Ldap}{NormalizeLoginNames} = 1;
  • {Ldap}{NormalizeGroupNames} =1;

And it still doesn't work. To define groups, i must do as following :

  • Set GROUP = james_46bond (for Ldap user james.bond)

I updated all the account to remove the "." so it does not bother me anymore.

pl.

-- TWikiGuest - 10 Jun 2008

This _46 is TWiki's internal representation of "canonical user ids" that are exposed to the upper levels. I think I've got a fix for both: (a) the core to convert wikinames and login names in ACLs to canonical user ids before checking access rights and (b) to implement the mapping from login names back to canonical user ids within the ldap contrib. See also Bugs:Item5118 for more information.

-- MichaelDaum - 11 Jun 2008

Closing this after more than 30 days of inactivity. Please feel free to re-open if needed.

-- PeterThoeny - 02 Aug 2008

The dot problem exist for the underscore also!!!!!. If the user's ldap uid (login name) is x_xxxx and cn is "James Bond" and hi belongs to ldap group "ldapuser", then:

1. LdapContrib doesn't find the WikiName 2. the permissions to access/change/rename topic is not respected (the user seems not have the permissions assigned to "ldapgroup" group. 3. the LoginName x_xxx is internally treated ad x_5fxxx 4. the various hacking suggested above seems to have no effect.

-- MassimoMancini - 04 Sep 2008

Change status to:
Edit | Attach | Watch | Print version | History: r12 < r11 < r10 < r9 < r8 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r12 - 2008-09-04 - MassimoMancini
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.