Question

Hi.

Please help enlighten me - I am very confused about WikiNames and login names, and how they map. I've been using TWiki authentication for many years. This is simple:

WikiName = 'login name' which maps to WIKIUSERNAME via the Main web using Main.WikiName.

I'm trying to move to LDAP auth. The authentication seems to work easily, but I expected my login name and WIKIUSERNAME to now have different values, with TWiki mapping my WIKIUSERNAME variable to my old Main.WikiName once I am logged in.

This doesn't seem to be the case, though. Instead I get:

login name = steve jones WIKIUSERNAME = Main.steve jones (which doesn't link anywhere)

But, very oddly;

[[%WIKIUSERNAME%]] = Main.SteveJones

So the WIKIUSERNAME variable does map as I expected if I put double brackets around the variable ! Surely this is not the correct behaviour ?

This causes a huge problem, as many pages have access control which refer to existing users' WikiNames, which clearly won't work now, since their WIKIUSERNAME has changed to their login name. Access is no longer granted to these users.

I tried to get access control to work with the login name, but this wasn't working either.

I believe I have all the correct variables set in my LocalSite.cfg:

$TWiki::cfg{LoginManager} = 'TWiki::Client::ApacheLogin';
$TWiki::cfg{MapUserToWikiName} = 1;
$TWiki::cfg{Register}{AllowLoginName} = 1;
$TWiki::cfg{PasswordManager} = 'TWiki::Users::HtPasswdUser';

Please help if you can. How should this be working ?

Thanks so much,

Steve.

Environment

-- SteveJonesST - 12 Dec 2007

Answer

What should be happening, is that TWiki uses the

   * Main.SteveJones = steve jones

line in the TWikiUsers topic to convert your login (steve jones) to your WikiName (SteveJones), which is then used in the top of the left bar to create the webDotWikiName (SteveJones).

My theory is that the code does not deal with spaces correctly.

do you have an LDAP user that you can test without a space?

(If I'm right, this is something we still have a small window of oportinuty to fix in 4.2.0)

-- SvenDowideit - 13 Dec 2007

Also, the reason %WIKIUSERNAME% appears to work, is that converts spaced words into wikiwords, by capitalising first letters and removing spaces.

-- SvenDowideit - 13 Dec 2007

Hi Sven.

My TWikiUsers is like this:

   * SteveJones - steve jones - Nov 2003

Unfortunately, all the users in our LDAP db have a space in their name (this directory is not something I can change), but your theory certainly sounds correct, but I can't test it conclusively.

I would really like to get this fixed - should I raise it in the bugs database for 4.2.0, or is there another way I should bring to the attention of the right people ?

Thanks,

-- SteveJonesST - 13 Dec 2007

Sven's theory should be correct based on the fact that he has been working on the code for some years now

For any authentication scheme which creates nontrivial alphanumeric login names, there are two options:

1. Use appropriate TWiki extensions which support your authentication backend. In your case, TWiki has Plugins.LdapContrib, which offers support to map arbitrary LDAP fields to what TWiki will take as "login name". However, it takes some effort to wrap your head around, and to customize.
2. Use a quick'n'dirty hack to get rid of the blank as given by Apache. I always (ab)use bin/LocalLib.cfg, and have occasionally recommended this to others, who seem to be happy with it. In your case, of course, this would mean to get rid of the blanks in your TWikiUsers topic as well.

So, if you want to go the first path, check out Plugins.LdapContrib and Plugins.LdapContribDev. Before you decide to go the second path, please do raise a bug item as well. Describe your use case as you did here. When refactoring TWiki's user management code, it has proven difficult or impossible to know in advance how people would like to use it.

-- HaraldJoerg - 13 Dec 2007

Thanks Harald for your helpful suggestions. It seems that a simple workaround in my case, is just to remove the space from the login names in the TWikiUsers topic. If I do this, the mapping to WikiName seems to take place with no issues as far as I can tell, but I would appreciate feedback from someone more experienced. Here's what happens:

When the space is removed from the login name in TWikiUsers:

   * SteveJones - stevejones - Nov 2003

I can authenticate via the LDAP server (adding a few lines in the bin/.htacces file) as 'steve jones', and TWiki knows me as:

• WIKIUSERNAME = Main.SteveJones
• WIKINAME = SteveJones
• USERNAME = steve jones

Access control and rcs operations all seem to work fine. Is there any danger of this causing unexpected side effects elsewhere in TWiki ?

All advice appreciated - thanks.

I also added a bug item for the current 4.2.0.

-- SteveJonesST - 13 Dec 2007

Steve, thanks for the bug

One more test - Can you map a different WikiName to your login please? something that could not possibly be made by concatination? I'm rather unsure how and why * SteveJones - stevejones, and am rather afraid it will stop working in 4.2.0.

-- SvenDowideit - 13 Dec 2007

Hi Sven.

I just did this in TWikiUsers:

   * TWikiGuest - stevejones - 05 Nov 2003

When I externally authenticate with 'steve jones', my TWiki name variables are:

WIKINAME = TWikiGuest

WIKIUSERNAME = TWikiGuest

USERNAME = steve jones

For me this still works. Is this what you were asking me to do ?

I am about to move around 1800 users over to working this way, and to be honest, I'd rather someone like you was convinced that this is a safe way to authenticate and map names. You can imagine the mess if I screw this up...

Thanks,

-- SteveJonesST - 13 Dec 2007

I think the problem is that TWiki does not handle spaces in login names. Assuming you have no login manager and rely on the REMOTE_USER environment variable to detect the login name, you can change spaces in the login name to underscores: In bin/LocalLib.cfg add this line:

$ENV{REMOTE_USER} =~ tr/ /_/;

In TWikiUsers you would have:

   * SteveJonesST - steve_jones - 05 Nov 2003

This is untested code though. Changes in bin/LocalLib.cfg are robust and should survive upgrades.

-- PeterThoeny - 16 Dec 2007

I think Peter's suggestion is better than using

   * SteveJonesST - stevejones - 05 Nov 2003 

as it will allow you to later convert to using a space (I hope to find time to make a space work, but i can't promise it)

This is the sort of code change Harald refered to - if you put it into bin/LocalLib.cfg, you can make sure it gets processed before anything else does.

-- SvenDowideit - 17 Dec 2007

Thanks to Peter, Harald and Sven for their advice, which I will follow.

Last question to close this - with this in place, what should newly-registering users type in the LoginName field on the TWikiRegistration form ? I know the final value in TWikiUsers needs to have space replaced with underscore, but new users won't know this. Will the substitution from Peter in LocalLib.cfg put the correct value in TWikiUsers, or do I need to substitute this myself ?

To ask another way, what should a new user provide as a LoginName - should it be either:

• steve_jones
• steve jones

By default, they will only know to provide the second login name (with the space). If this is not enough, I will need to write something to replace the space at registration time.

Thanks again.

-- SteveJonesST - 17 Dec 2007

This depends on whether your users are already authenticated when they register. If so, then the code in bin/LocalLib.cfg will make sure that the "correct" value of steve_jones is displayed as a default in the registration form. If newly registering users leave it alone, then it will work fine.

However, if your users are not authenticated when registering, or if they manually enter their login name with a space, then TWiki will register the wrong name in TWikiUsers. So to safeguard against this case you'd have to add another tr statement to the registration code (which may be easier and more reliable than adding some help texts to the registration form).

-- HaraldJoerg - 17 Dec 2007

Thanks again, Harald. This is clear to me. I will implement as you have suggested. Thanks to you all for such good advice.

-- SteveJonesST - 18 Dec 2007

Hi, I am about to roll this solution out this weekend, and just noticed a problem which will block me. If anyone has a suggestion, please let me know asap.

I have implemented HaraldJoerg's suggestion, which uses a hacked LocalLib.cfg to correctly map spaces to underscores, so that WikiNames are correctly mapped to LoginNames.

This works perfectly when the login or edit script is called, but not when view is called on a topic with access control.

To be more specific, if I am asked to authenticate because I clicked on 'Log In', or 'Edit', then I get good behaviour as follows:

• I give my LDAP credentials, (username has a space)
• The LocalLib.cfg hack replaces the space with an underscore in my LoginName.
• The TWikiUsers topic matches my hacked LoginName (steve_jones) to my WikName.
• Everything is OK.

However, this no longer works when I am asked to authorise myself because the view script finds a page with access control. In this case the following happens:

• I authorise OK via LDAP (username has a space)
• The LocalLib.cfg hack seems to fail (space is not replaced with underscore)
• My LoginName doesn't match anything in TWikiUsers, since it still contains a space, and the one in TWikiUsers has an underscore.
• My WikiName is not set properly.

The apache log shows this:

Use of uninitialized value in transliteration (tr///) at LocalLib.cfg line 4.

As a reminder the hack in twiki/bin/!LocalLib.cfg is:

$ENV{REMOTE_USER} =~ tr/ /_/;

Could it be that $REMOTE_USER is not defined in this case ?

Please, Harald or anyone else, do you have any suggestions as to how to get this to work with a direct view of restricted content? If not, I'll have to abandon the switchover, which will be quite embarrassing.

All suggestions appreciated.

-- SteveJonesST - 18 Apr 2008

Not a solution, but some additional hint. When you look at an access restricted page with the view script it should redirect to the viewauth script. The view script is not authenticated, e.g. the REMOTE_USER env variable does not exist, hence your uninitialized value message. The viewauth script should see the REMOTE_USER env varable, so I do not understand why it does not work in your case.

-- PeterThoeny - 18 Apr 2008

Peter, your hint may have helped me. It seems that the problem is caused by the use of speedyCGI on the viewauth script. If I move viewauth back to perl, then $REMOTE_USER is picked up, and I get the correct behaviour after authentication.

speedyCGI was only enabled on view in my install, and viewauth was alink to view. Is it possible that speedyCGI somehow stops $REMOTE_USER from being evaluated ?

I will copy view to viewauth and remove speedyCGI from viewauth. It will be a shame to lose the speedup on authenticated pages, but we can live with it for the time being I guess.

Will I see a slowdown on every page of an access controlled web, or is there a mechanism whereby the first page view in an access controlled web uses viewauth, and the rest use view ?

Thanks, as always.

-- SteveJonesST - 19 Apr 2008

You are correct: The trick with LocalLib.cfg definitely does not work with speedyCGI (or any other persistent interpreter like mod_perl). Sorry, I found that we completely missed to mention this important fact in the previous discussion. The technical reason is that with speedyCGI, one process serves many HTTP requests, but compilation only takes place for the first request. LocalLib.cfg is evaluated only during the compilation phase, so only the first request for every speedyCGI process will have its $REMOTE_USER examined.

-- HaraldJoerg - 19 Apr 2008

I guess that answers the question.

You will see a slower speed if you run viewauth without speedyCGI.

-- PeterThoeny - 19 Apr 2008

Thanks, both Peter and Harald for giving me the information I needed to make progress here. I appreciate your excellent support very much. I will re-close this question.

-- SteveJonesST - 19 Apr 2008

Change status to: AskedQuestions AssignedQuestions AnsweredQuestions ClosedUnanswered