Item1701: Reset password doesn't work with ApacheHtpasswdUser.pm

Hi,

I am getting:

Password reset failed

Password reset failed
IngoTest

Then I found that my ResetPassword.txt wasn't updated with the 1.0.5 upgrade package although it seems it may have required to be updated based on http://foswiki.org/Tasks/Item1458:

./data/System# ls -l ResetPassword.txt
-rw-r--r-- 1 www-data www-data 2336 2009-01-08 13:02 ResetPassword.txt

I tried to replace it from the full installation package:

root@wiki-ngm:/srv/www/foswiki/data/System# diff ResetPassword.txt ResetPassword.txt.bkp
1c1
< %META:TOPICINFO{author="ProjectContributor" date="1111929255" format="1.1" version="1"}%
---
> %META:TOPICINFO{author="ProjectContributor" date="1111929255" format="1.0" version="1"}%

It didn't help and the only diff is as shown above. Do I need a fixed version and if so how can I get it?

I've digged a bit more and found that bin/resetpasswd was correctly replaced. Right now I am not so sure anymore if this a task/bug or something else.

-- IngoKappler - 09 Jun 2009

AppliesTo SomethingElse should not be used for bug reports. If this was a bug it would be an engine bug.

(I am going to remove that silly SomethingElse selection in a near future because bugs end up in a queue noone ever looks at)

ResetPassword.txt is not in upgrade packages because it is a commonly tailored topic. If you do not use .htpasswd type passwords but use some corporate single sign-on scheme - this topic will typically be changed to a short note guiding the user to the corporate password changing site.

The CSRF change done with 1.0.5 did not create any changes to ResetPassword.txt. It was already corrected made with a form that had method="post".

I did a clean-up of distributed topics so they are all version 1.1 format. This gives a microscopic performance improvement because some compatibility code does not have to be called then the version is 1.1 instead of 1.0 (1.0 was where bullets had a tab instead of 3 spaces in front of the *). And for upgraders this is not important at all. It is more important that people do not get their tailored topic overwritten.

So your problem is not related to this topic.

When reset password does not work it is always related to

• You do not use a password manager that can reset the password
• The file access rights for .htpasswd and the directory that holds it is wrong.
• The email system cannot send the reset password message

I have tested the reset password feature only days ago when I added logging for it. It does work

-- KennethLavrsen - 09 Jun 2009

Kenneth, thanks for the comprehensive answer!

I put it to SomethingElse because I wasn't sure to put it on core, core sounds so heavy and important.

I guess the following applys to my situation:

• You do not use a password manager that can reset the password

I'll have to check but probably the ldap login manager is active although it falls back to apache login manager if it fails, which unfortunately is still the case in my situation. So let me change that in configure and see if ResetPassword will behave correctly after the ldap login manager is fully out.

-- IngoKappler - 10 Jun 2009

After re-checking the login manager settings I found I am using the following:

• Foswiki::LoginManager::ApacheLogin
• Foswiki::Users::TopicUserMapping
• Foswiki::Users::ApacheHtpasswdUser

From that point of view the ResetPassword should work, shouldn't it?

File system rights are:

foswiki# ls -ld data/
drwxr-xr-x 12 www-data www-data 4096 2009-06-10 09:49 data/

foswiki/data# ls -la .htpasswd
-rw-r--r-- 1 www-data www-data 1919 2009-06-09 13:52 .htpasswd

Those permissions look basically ok to me and the change password function works, hence the system is able to write there.

The last thing is the mail system. This might indeed be another point as we are having sometimes an issue with the a long response time from the mail server (maybe routing related).

I now found this in apache error log:

[Wed Jun 10 10:12:57 2009] [error] [client xxx.xxx.xxx.xxx] [Wed Jun 10 10:12:57 2009] view: Use of uninitialized value $repeatedLine in substitution (s///) at /path/to/foswiki/lib/Foswiki/Plugins/SkillsPlugin.pm line 354., referer: http://dns/foswiki/bin/resetpasswd/Main/WebHome
[Wed Jun 10 10:12:58 2009] [error] [client xxx.xxx.xxx.xxx] [Wed Jun 10 10:12:58 2009] view: Use of uninitialized value in substitution iterator at /path/to/foswiki/lib/Foswiki/Render.pm line 563., referer: http://dns/foswiki/bin/resetpasswd/Main/WebHome

After disabling the skills plugin I am getting only this one error line:

[Wed Jun 10 10:25:33 2009] [error] [client xxx.xxx.xxx.xxx] [Wed Jun 10 10:25:33 2009] view: Use of uninitialized value in substitution iterator at /path/to/foswiki/lib/Foswiki/Render.pm line 563., referer: http://dns/foswiki/bin/viewauth/System/ChangePassword

The connection to the Mail server looks ok including a response time which is good enough.

Seems I am stalled here.

-- IngoKappler - 10 Jun 2009

Well. Looking at your errors I note

Use of uninitialized value in substitution iterator at /path/to/foswiki/l

There is no path called /path/to/foswiki

That is a typical example patch that you are supposed to change to the correct one.

-- KennethLavrsen - 16 Jun 2009

The following files hold /path/to/ in some line:

$ find . -name '*' -exec grep -l '/path/to/' {} \;
./lib/CPAN/lib/CGI/Session/Driver/sqlite.pm
grep: ./twiki420: Too many levels of symbolic links
./bin/LocalLib.cfg.TEST-FNR
./bin/LocalLib.cfg
./bin/LocalLib.cfg.txt
./data/System/AccessControl.txt
./data/System/GenPDFAddOn.txt.bak
./data/System/GenPDFAddOn.txt,v
./data/System/InstallationGuide.txt
./data/System/SiteTools.txt
./data/System/GenPDFAddOn.txt
./data/TWiki/SearchEngineKinoSearchAddOn.txt
./data/TWiki/SearchEngineKinoSearchAddOn.txt.bak
./pub/System/YahooUserInterfaceContrib/tests/autocomplete.html
./pub/System/YahooUserInterfaceContrib/tests/autocomplete.html.bak
./pub/Offices/Duesseldorf/WikiInstallation/see-wiki_installation-upgrade_TWiki-4.2.4.log,v
./pub/Offices/Duesseldorf/WikiInstallation/see-wiki_installation-upgrade_TWiki-4.2.4.log
./kinosearch/bin/LocalLib.cfg.bak
./kinosearch/bin/LocalLib.cfg.FOSWIKI_TEST
./kinosearch/bin/LocalLib.cfg
./kinosearch/index/_410.cfs
./INSTALL.html

The canditate to be most likely responsible is ./bin/LocalLib.cfg but when looking into it I see the related lines are commented and indeed the correct line is correct:

$cat ./bin/LocalLib.cfg | grep '/path/to/'
#$foswikiLibPath = "/absolute/path/to/your/lib";
# @localPerlLibPath = ( '/path/to/dir', '/path/to/another/dir' );

I don't think the following should be relevant:

$ cat ./pub/System/YahooUserInterfaceContrib/tests/autocomplete.html | grep '/path/to/'
            this.data = "http://path/to/server";
            ac.dataSource.liveData = "http://path/to/server?";

Do you have an idea where else this /path/to/ may come from?

I wonder if I have to disable further plugins to get rid of this error line because the error line related to the skills plugin had a similar affect. I will check that later on today.

-- IngoKappler - 17 Jun 2009

I've now disabled quite some plugins and no error lines show up anymore. However, the issue persisted, so I disabled all Plugins and retested. Unfortunately nothing changed functionality wise. Only the strange error messages in the logs dissapeared. Hence the plugins don't seem to be the key issue; stalled again.

Guess I may need to get a tcpdump to provide some more insight. In case this doesn't look promising what else could be done?

-- IngoKappler - 17 Jun 2009

Since it looks like the issue only affected me and I just enabled ldap authentication, I have no need to further investigate it. Set to "No Action Required".

-- IngoKappler - 24 Jun 2009

I'm reopening this as urgent. I found the issue. With HtpasswdUser.pm, the "old password" field is set to '1' to force setPassword to reset, instead of validating the old password. ApacheHtpasswdUser.pm doesn't contain that logic. So the forced old password of '1' is never correct, and the password reset will always fail.

-- GeorgeClark - 03 Aug 2010