Item8192: SecondaryPasswordManager and registration, change password, change email

Hello,

short description: SecondaryPasswordManager and registration/change password/change email does not work

Detailed description in these question topics:

http://foswiki.org/Support/Question54

http://foswiki.org/Support/Question167

Regards, Timm

-- TimmWunderlich - 29 Jun 2009

Vote, vote. We are having same problem - no failover working, despite setting the config options and a lot of testing. Would really appreciate a solution to this bug.

-- MarcusLeonard - 18 Aug 2009

Though I had a lot of trouble tracing the code I found that checkPassword never got called to failover if the user was not in the cache. Therefore I resolved to add my htaccess users to the cache when updating from ldap.

The following code snippet inserted into LdapContrib.pm solved the problem for us by keeping a separate user file (we called foswikiusers) in the format username:encrypted passwd:email:Common Name. The usernames and passwords are copied into the htpasswd file at the same time they are added to the cache.

    my $users_file="/home/foswiki/data/foswikiusers";
    open(FH, $users_file) || die("Could not open file!");
    open( FILE, ">$Foswiki::cfg{Htpasswd}{FileName}" )
      || throw Error::Simple(
        $Foswiki::cfg{Htpasswd}{FileName} . ' open failed: ' . $! );


    while (<FH>) {
      unless (/^[#\n]/) {
        chomp;
        my ($username, $password, $email, $wikiname) = split(':');
        my $tmp =  Net::LDAP::Entry->new();
        $tmp->dn( '' );
        $tmp->add(
          uid => $username,
          email => $email,
          cn => $wikiname
        );
        $this->cacheUserFromEntry($tmp, $data, \%wikiNames, \%loginNames) && $nrRecords++;
        print FILE "$username:$password\n";
      }
    }
    close(FILE);
    close(FH);

-- DennisSketchley - 20 Aug 2009

Thank you for your answers i already searched for a alternative wiki solution, as nobody seemed to be interested in this problem, and as i have not enough time to reverse engineer this code...good to see that there are more with this problem....

The solution adding external users to the cache is somehow nice, but does not solve the problems with registration and change password/email for htaccess users i think.

It would be nice if you could also provide some replacement code for the registration and change password/email....

Just to explain again: I don`t want this features to work with LDAP users but for the htaccess users. As we use Kerberos for authentication and SASL as a middleware between LDAP and Kerberos, a change password in LDAP is NOT a desired feature for ME.

-- TimmWunderlich - 22 Aug 2009

Hi all,

i did spend some time with trying to understand what happens during the registration process and why the e-mail adress is not written to the .htpasswd file.

This is what i found out: in lib/foswiki/UI/Register.pm first "sub register" is called to validate the data and then "sub complete" is called to save the data.

In "sub complete" the email is set by this line: $users->setEmails( $cUID, $data->{Email} );

And the Problem is that there is no such sub in LdapUserMapping.pm. But, as LdapUserMapping.pm is a subclass of TopicUserMapping.pm, the setEmails sub from TopicUserMapping.pm should be called or not?! I put some debug statements into this sub, and it is definitely not called.....so this is the problem i think. But i do not understand why the SUPER sub is not called at all....

-- TimmWunderlich - 09 Nov 2009

I've the same problem. Some users in ldap and some users local and the password change and reset system is read only. Is there a solution? In which part or sub of the file LdapContrib.pm I include the code snipped?

Why is no field for password on the register page?

-- TorstenZ - 25 Nov 2009

I've updated foswiki-ldapcontrib up to version 091118-203 but the password system is still read only.

-- TorstenZ - 27 Nov 2009

I found out that "setEmails" in UserMapping.pm gets called(which is empty), so perhaps the mapping is set to BaseUserMapping instead of LdapUserMapping or TopicUserMapping!?

The _getMapping($cUID) function in Users.pm gives back BaseUserMapping instead of LdapUserMapping or TopicUserMapping.

-- TimmWunderlich - 08 Dez 2009

Now i replaced (Users.pm, SUB setEmails) return $this->_getMapping($cUID)->setEmails( $cUID, @emails ); with return $this->{mapping}->setEmails( $cUID, @emails ); and then the setEmails function in <nop>HtPasswdUser.pm gets called which seems to be right as this is my <nop>SecondaryPasswordManager. But it gives me following error: "register: Use of uninitialized value $login in hash element at...."

-- TimmWunderlich - 09 Dec 2009

After more debugging:

In LdapUserMapping.pm SUB getLoginName:

return undef unless $this->{ldap}->getWikiNameOfLogin($login);

This makes the function return undef during registration and therefore no cUID is given to setEmails....

-- TimmWunderlich - 09 Dec 2009

After more debugging:

In LdapUserMapping.pm SUB getLoginName:

return undef unless $this->{ldap}->getWikiNameOfLogin($login);

This makes the function return undef during registration and therefore no cUID is given to setEmails....

-- TimmWunderlich - 09 Dec 2009

I ran into this problem too, and came up with a one-liner solution that seems to work for me - though only to fix it so my existing native wiki (non-LDAP) users can login and logout, not to make registration and password changing work (not critical to me at this point, since I only have one native user WikiAdmin who I registered before switching to LDAP, and don't plan to add any more).

The solution that I came up with was to add the following in LdapUserMapping.pm right before the final "return 0;" at the end of sub handlesUser:

  # fallback
  return 1 if $this->SUPER::handlesUser($cUID, $login, $wikiName);

This allows the function to fallback to the super class to check if the mapping manager can handle this user, and the super class is the template user mapper.

I haven't done extensive debugging or tracing, so user beware, but I thought I'd post this in case it helps anyone else in a similar bind.

-- LeilaPearson - 10 Aug 2010

Thanks I will look into this asap.

-- MichaelDaum - 11 Aug 2010

Thanks for posting that, Leila, it did in fact help somebody!

I can confirm that the patch works, or at least allows me to log my couple locally registered users on with htpassword as the secondary password manager. However, I also haven't done any extensive testing.

I was in the same puzzling situation, where a single locally registered user "RasmusPraestholm" worked (made before enabling LDAP), but a "RasmusPraestholmLocal" didn't. Doubly puzzling since my LDAP user "RPraestholm" resolved to the same wiki name as my original local user, "RasmusPraestholm". Maybe that's why I was able to log that local user in, since it matched the resolved name in the LDAP cache? "RPraestholm" and "RasmusPraestholm" had different passwords.

Either way with the patch my other local user works too

-- RasmusPraestholm - 17 Aug 2010

-- KevinKaiser - 26 Apr 2011

Is there any progress on this issue?

-- KevinKaiser - 26 Apr 2011

Wont fix. There will be a new LDAP implementation coming out soon, called PluggableAuthContrib.

-- MichaelDaum - 07 Aug 2023

Commenting is disabled while not logged in