• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

In configure - for the MapUserToWikiName it says

"Map login name to Wiki name via the mapping in the topic named in {UsersTopicName}. Set this to $FALSE for .htpasswd authenticated sites where the user's wiki name is the name they use to log in, or if you have some other way of making the mapping to a Wiki name (e.g. a local Plugin). "

And since I use .htpasswd authentication I have turned unselected the option as instructed.

I have recently received emails from users that complain that they cannot reset their password.

Some can. Some cannot. It seems to be the new users that cannot.

The error they get is "Password reset failed - Can't find user WikiName"

And I can confirm that they are right because I get the same error when I try to reset their username. But I can reset other users name.

I followed the reset password code. And I ended up in lib/TWiki/Users/TWikiUserMapping in the function lookupLoginName.

I cannot quite see what goes wrong exactly, because that piece of code is quite strange to me.

But I could see that _loadMapping depends on MapUserToWikiName and does not seem to do much if it is turned off.

This needs to be fixed because it is not the idea that MapUserToWikiName is enabled when you do not allow usernames.

When the fix for this is available I will put it in the next hotfix. This is pretty important. I am sure many have this problem.

-- KJL


Great analysis! I also have mapping set to false (as configure recommends for Apache login via .htpasswd). I was about to file an enhancement report as follows:

ResetPassword basically works for us (tested 2-3 users). However:

  1. TWikiAdminGroup should be able to use it to reset any user's password. So far, only oneself's password can be reset.
  2. The message "Can't find WikiName" is really misleading. It lead another admin and myself to go looking for problems in a wrong place. We obtain this message whenever we enter the login name of another user in the form. It should say one cannot supply another user's name if that's the restriction and not a bug.

Add 1): resetting one's own password not enough functionality. It's no replacement to the InstallPassword mechanism our admins used in ancient releases of TWiki.

So maybe it's exactly the same bug as you, maybe not?? You say you "can reset other users name." I can't unless I login using their identity.

Regards, TWiki:Main/JoergHoehle


Joerg.

First - the bug reported here is that Reset Password fails (not with all user names for some reason) because it cannot find the user when MapUserToWikiName = 0. That is the bug report. We should try and have one bug per report.

Second - When Reset Password works anyone can reset anyones password. You do not have to be an admin. If a user could only reset his own password then that user would have to be logged in before TWiki can know who he is. And if he can login then he does not have to reset the password in the first place. Then he can CHANGE the password which is another feature. Can't find WikiName" is not misleading. It is the result of a bug. That error message is supposed to be displayed only when someone resets a user that does not exist. But the bug is that the user cannot be found unless MapUserToWikiName = 1.

-- KJL

Ok, I've moved the enhacement request to Item2640. -- TWiki:Main/JoergHoehle

I confirm your bug report. I've switched configuration to map users from login names, despite using Apache login -- I don't foresee any harm from doing so. It allows ResetPassword to work for our people.

-- TWiki:Main/JoergHoehle

I would like to include the fix for this one in a Hotfix 2 for 4.0.4.

But I am not able to do the fix myself. I have dug into the code as far as I could as you can see from above description but I need help getting it fixed.

-- KJL

I don't doubt for a moment that there is a problem, but so far i've not managed to reproduce it using your instructions.

I do the following:

  1. svn co TWikiRelease04x00
  2. set up with configure to get a running system
  3. set {MapUserToWikiName}=0 & {LoginManager}='TWiki::Client::ApacheLogin';
  4. register SomeGuy
  5. change password without any problems.

I've also commented out all the code in _loadMapping with no problems.

please - can someone who does get this make a real step by step instruction from svn co or unzip that Will reproduce it?

SD

It is my morning and I do not have that much time. I can provide more tonight.

The info I can give this morning is: What I saw was that some users could reset and some could not. Most could not. And it may be dependent on the actual name. ???!

These two names could not reset: CassioAnother and CassioFreitas. The latter was actually a name of an actual guy with the problem. The first is a test person I created.

I have attached the home topic of the user that fails.

And below is the line from .htpasswd

CassioAnother:gsRtsEt6sggss:kjl@inet.uni2.dk

and from TWikiUsers

   * CassioAnother - CassioAnother - 16 Jul 2006

finally the LocalSite.cfg

$TWiki::cfg{DataDir} = '/usr/local/apache2/twiki/data';
$TWiki::cfg{DefaultUrlHost} = 'http://merlin.lavrsen.dk';
$TWiki::cfg{LocalesDir} = '/usr/local/apache2/twiki/locale';
$TWiki::cfg{LoginManager} = 'TWiki::Client::ApacheLogin';
$TWiki::cfg{Password} = 'nonoyouwont';
$TWiki::cfg{Plugins}{CommentPlugin}{Enabled} = 1;
$TWiki::cfg{Plugins}{DefaultPlugin}{Enabled} = 1;
$TWiki::cfg{Plugins}{EditTablePlugin}{Enabled} = 1;
$TWiki::cfg{Plugins}{PreferencesPlugin}{Enabled} = 1;
$TWiki::cfg{Plugins}{RenderListPlugin}{Enabled} = 1;
$TWiki::cfg{Plugins}{RevCommentPlugin}{Enabled} = 1;
$TWiki::cfg{Plugins}{SlideShowPlugin}{Enabled} = 1;
$TWiki::cfg{Plugins}{SmiliesPlugin}{Enabled} = 1;
$TWiki::cfg{Plugins}{SpreadSheetPlugin}{Enabled} = 1;
$TWiki::cfg{Plugins}{TablePlugin}{Enabled} = 1;
$TWiki::cfg{Plugins}{WysiwygPlugin}{Enabled} = 1;
$TWiki::cfg{PluralToSingular} = 0;
$TWiki::cfg{PubDir} = '/usr/local/apache2/twiki/pub';
$TWiki::cfg{PubUrlPath} = '/twiki/pub';
$TWiki::cfg{SMTP}{MAILHOST} = 'localhost';
$TWiki::cfg{SMTP}{SENDERHOST} = 'lavrsen.dk';
$TWiki::cfg{ScriptUrlPath} = '/twiki/bin';
$TWiki::cfg{Sessions}{ExpireAfter} = '-21600';
$TWiki::cfg{Site}{CharSet} = 'iso-8859-15';
$TWiki::cfg{Site}{FullLang} = 'en-us';
$TWiki::cfg{Site}{Lang} = 'en';
$TWiki::cfg{TemplateDir} = '/usr/local/apache2/twiki/templates';
$TWiki::cfg{Plugins}{TwistyPlugin}{Enabled} = 1;
$TWiki::cfg{Plugins}{RevisionLinkPlugin}{Enabled} = 0;
$TWiki::cfg{AntiSpam}{EmailPadding} = 'PLEASENOSPAM';
$TWiki::cfg{Plugins}{ChartPlugin}{Enabled} = 1;
$TWiki::cfg{Plugins}{ActionTrackerPlugin}{Enabled} = 1;
$TWiki::cfg{Plugins}{CompareRevisionsAddonPlugin}{Enabled} = 1;
$TWiki::cfg{Plugins}{TWikiDrawPlugin}{Enabled} = 1;
$TWiki::cfg{Plugins}{BlackListPlugin}{Enabled} = 1;
$TWiki::cfg{MapUserToWikiName} = 0;
1;

If you cannot reproduce it still I will zip up an entire non-working example that you can download and try.

KJL

I do not know if this still applies to TWiki 4, but there might be a security issue if the user mapping is enabled on public sites. See TWiki:Codev/SecurityAlertGainAdminRightWithTWikiUsersMapping

-- PTh

Sven (and anyone else that wish to give this bug a try).

I have built a fresh build of the current TWiki4 tree. And I have set it up so that the bug can be reproduced.

If you download the tgz I have made then you get a complete installation of TWiki as it is per 05 Aug 2006 and with this configuration all 3 users registered cannot reset their passwords. The configure password is "twikirules".

The URL:

http://www.lavrsen.dk/misc/twiki404b1.tgz

KJL

sven testing, but its slow, too many things to do

SD

Can you reproduce it now?

Any further analysis I can do to assist? And debug messages I can and run and report back?

KJL

Trace if reset password.

  • bin/passwd is run
  • Calls TWiki::UI::run( \&TWiki::UI::Register::passwd_cgi );
  • Trace in lib/UI/Register.pm in function passwd_cgi shows this function is run
  • Confirmed that the $action eq 'resetPassword' and that resetPassword( $session ) is called.
  • Confirmed that the reset is not a bulk reset
  • Put a trace message inside foreach my $userName (@userNames) {
    • Confirmed that there is only one $userName in @userNames.
    • A printout shows that the $userName is correct - example "CassioAnother"
  • Confirmed that _resetUsersPassword( $session, $userName, $introduction, \$message ) is called
  • Confirmed that inside _resetUsersPassword $userName is still "CassioAnother"
  • Confirmed that $session->{users}->findUser( $userName, undef, 1) does not return a user
    • Confirmed that $$pMess .= $session->inlineAlert( 'alerts', 'bad_user', $userName ); is run inside the unless( $user ) loop.
  • Continue the trace inside TWiki::Users::findUser.
    • Inside findUser: name = CassioAnother, wikiname is undefined, dontCreate = 1
    • confused WHY DO WE CALL FINDUSER WITHOUT A WIKINAME when $TWiki::cfg{MapUserToWikiName} = 0 ????? Is this the bug?
    • We pass past $name =~ s/^Main.//; still with name = CassioAnother
    • We pass by the "#not cached" comment
    • unless( $wikiname ) is true to we call the function $wikiname = $this->lookupLoginName( $name )
    • lookupLoginName returns nothing
  • Continue the trace inside lookupLoginName( $name )
    • Confirming that inside lookupLoginName() the $loginUser is still CassioAnother
    • Confirming that after the substitution regex the $loginUser is still CassioAnother
  • Continue the trace inside $this->{usermappingmanager}->lookupLoginName($loginUser) which is lib/Users/TWikiUserMapping.pm - lookupLoginName()
    • Confirmed that inside the lib/Users/TWikiUserMapping.pm $loginUser is still CassioAnother
    • This is where I get lost - I do not know what $this->_loadMapping(); is doing exactly and if it succeeds or fails.
      • Note that inside _loadMapping there is code where the execution depends on $TWiki::cfg{MapUserToWikiName}
      • The $text at the end of the _loadMapping has the value "guest". So it seems with MapUserToWikiName = 0 the _loadMapping behaves very differently.
      • $text is a local variable. And thing is returned at the end of _loadMapping. It seems $text is set but not used. Something fancy happens in the last regex and this is where I am lost
    • $this->{U2W}{$loginUser} - returns nothing

Note In the Action notify bug same thing happens Item2732. my $user = $TWiki::Plugins::SESSION->{users}->findUser( $wiki, undef, 1 );

So Item2732 and this bug are the same bug. And I am sure other features using findUser will have same problem but probably only when the function is called to translate a login name to a wikiname and the loginname and wikiname is the same thing. I still wonder why we see the bug only a few places because findUser is all over the place.

I am now trying to see what other features I can find that fails with $TWiki::cfg{MapUserToWikiName} = 0

-- KJL

After having looked at the code again tonight I now understand what _loadMapping does. And I now also understand why $this->{U2W}{$loginUser}

When $TWiki::cfg{MapUserToWikiName} = 0 then there is never any cache being built up. There is only a dummy cache with TWikiGuest mapped to guest.

Natually one can just eliminate this. But it was originally introduced as an extra security precausion when you run a TWiki that does not have login names different from WikiNames.

I am not sure how important this thing is anymore. I think we should consider removing the entire MapUserToWikiName feature. The old issue was when you had left TWikiUsers open for general editing. I think we are way past that now. We know this topic can never be left open to anyone else than the admin.

That is a thing to consider. But if we want to keep this safety code then the fix must be earlier in the chain. Why are we trying to look up a translation from username to wikiname when we know we pass on a wikiname?

The findUser function is called many places. So to fix this one has to walk through all the places findUser is called to see if there is some logic we can take advantage of. The quick and dirty solution I thought about is to return the name as wikiname when $TWiki::cfg{MapUserToWikiName} = 0. They are always the same. Except if the user is invalid! So this we also have to think about.

-- KJL

I have a fix that I am pretty sure is right. I am testing it for the moment.

Changing to actioning.

-- KJL

I implemented the fix and it works. But it also means that mapping is happening even when it is disabled and that can cost performance.

So I have made yet another fix. This time in Users.pm. Simply skipping looking up in the user mapping code unless it is enabled. I have only implented the fix for translating login name to wikiname. I guess the opposite should also be implemented.

There are probably more solutions. However. This 2nd solution means that user names that are not in TWikiUsers are mapped. Does that have any other influence.

I hope some core developers more experienced than I will have a look at the proposals and give feedback.

At least there is now so much information in this bug report that an experienced programmer can finish this in minutes. It is 3:18 AM so I will stop now.

-- KJL

The 2nd fix I made is dangerous. The 2nd fix comes from the talk Peter and I had about the first fix where we were worried about the need for reading in the TWikiUsers topic even when user mapping is disabled. So I tried to make a fix that just returns the wikiname since loginname and wikiname is then the same.

But that is not good.

You cannot just let lookupLoginName translate any wikiname into itself. When you do that you get a major security hazard. When you reset the password of an unknown user the user is added to the .htpasswd file and an email is sent to the admin. Worst I tried to reset the TWikiAdminGroup and it then got an entry in the .htpasswd file. I am sure this will lead to both malfunction and security holes. The lookupLoginName function must only return a wikiname if the user is found in TWikiUsers. And that leads back to the first fix I made which does exactly that.

It has the performance impact that the TWikiUsers file has to be parsed each the first time the function is called. After that the entries are cached.

I thought about just checking for the Users topic. But that is also a risk because often people can create whatever file they want in the Main directory. So you create the topic first, then reset password. Now you are in the .htpasswd file. All left is getting an entry in TWikiUsers. But if the lookupLoginName now returns something when mapping is off I am sure the security hole is wide open.

The only valid way to find valid users is parsing the TWikiUsers topic.

And if not found - return nothing.

-- KJL

I looked at the code from before SD split out the code in the seperate user mapping file. And as far as I can see the error must have been there before. It just seems noone tested reset password and actionnotify with MapUserToWikiName disabled.

So instead of my proposed fix - we also need to go back and look at the code in findUser. Why does it call the mapping in the first place? findUser is used many places so one has to be careful before you change too much around.

I do not dare checking in my fix because I will be away on vacation.

-- KJL

I really wonder why no core developer has looked or commented on this one until now other than Peter.

I almost feel like just checking in my first fix - but I will not check something in and then be away for two weeks.

So setting this back to new. I have done so much analysis and proposed code fixes that any core developers should be able to quickly close this one.

-- KJL

Anexcellent debug, though your logic took you so far but not all the way.

If you read the code that was in _loadMapping, you will observe the reference to TWiki:Codev/SecurityAlertGainAdminRightWithTWikiUsersMapping. On reading that report, it emerges that there was a vulnerability where a normal user could change the TWikiUsers topic to map their username to a TWikiAdminGroup username. This presumably applied before there were topic permissions, and the fix was to not load the mapping if the map option was switched off. Since we have the ALLOWTOPICCHANGE permissions on TWikiUsers locked down, this is no longer a vulnerability, so we can safely load the mapping file in all cases. So in the end, the fix was really simple (it wouldn't have been without the wealth of analysis above; thanks, Kenneth!)

CC

closed in 4.0.5 KJL

ItemTemplate
Summary Reset Password does not work when $TWiki::cfg{MapUserToWikiName} = 0 (hotfix candidate)
ReportedBy TWiki:Main.KennethLavrsen
Codebase 4.0.4, ~twiki4
SVN Range Wed, 12 Jul 2006 build 11001
AppliesTo Engine
Component

Priority Urgent
CurrentState Closed
WaitingFor

Checkins 11340
TargetRelease patch
Topic attachments
I Attachment History Action Size Date Who Comment
Texttxt CassioAnother.txt r1 manage 3.3 K 2006-07-27 - 04:09 UnknownUser Users home topic
Unknown file formatdiff item2631-solution2.diff r1 manage 1.1 K 2006-08-17 - 23:19 UnknownUser Solution 2 - fix is in Users.pm
Unknown file formatdiff item2631.diff r1 manage 2.0 K 2006-08-17 - 20:27 UnknownUser Fix I am testing
Edit | Attach | Watch | Print version | History: r21 < r20 < r19 < r18 < r17 | Backlinks | Raw View |  Raw edit | More topic actions
Topic revision: r21 - 2006-11-14 - KennethLavrsen
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback