Item1701: Reset password doesn't work with ApacheHtpasswdUser.pm
Priority: Urgent
Current State: Closed
Released In: 1.0.10, 1.1.0
Target Release: patch
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