[sork] Passwd Problems - Cannot Change password, no UPDATE applied

[Simon Brereton]

> -----Original Message-----
> From: sork-bounces at lists.horde.org [mailto:sork-bounces at lists.horde.org]
> On Behalf Of Eric Jon Rostetter
> Sent: Tuesday, October 20, 2009 4:24 PM
> 
> Quoting Simon Brereton <simon.brereton at dada.net>:
> 
> > The page loads with the Old password prefilled (but it always seems
> > to be 10 characters no matter if I use a user with a longer or
> > shorter password.
> 
> This sounds to me like your browser is filling in the password field
> for you with some saved password.  Try changing this to the proper
> password.

I struggled for hours to confirm what it was actually putting in there - and didn't think to manually change/enter it.  Thanks.  However, this had no effect.  Exactly the same results.

091020 22:30:27    1332 Connect     postfix at localhost on
                   1332 Init DB     Mail
                   1332 Init DB     Mail
                   1332 Query       SELECT Password FROM MailAccounts WHERE EmailAdd = 'simon at lydiard.net'
                   1331 Quit
Oct 20 22:30:27 HORDE [debug] [passwd] SQL Query by Passwd_Driver_sql::_lookup(): SELECT Password FROM MailAccounts WHERE EmailAdd = ? [on line
110 of "/usr/share/horde3/passwd/lib/Driver/sql.php"]

> Assuming that "EmailAdd" is the proper field name in you DB, this looks
> fine.
> 
> >                     582 Query       SELECT Password FROM
> > MailAccounts WHERE EmailAdd = 'simon at lydiard.net'
> 
> Assuming the same as above, plus that your database stores the full
> username with domain as shown, then this looks fine.

This is why I do it on the emailadd field - it's considered the username and is thus always full.  In my passwd conf, I have:

  9 $conf['hooks']['full_name'] = true;
 10 $conf['hooks']['default_username'] = false;

 
> > concerns me is the total absence of any UPDATE statement.  I take it
> > this is not normal.
> 
> It first verifies the old password, and only if that succeeds does it
> try the update.  So this would be normal if the old password is wrong,
> or the query fails.

Good to know - thanks.  At least now I need to know which step to work on - I was assuming it had pulled the correct password.  So, the db lookup is checking against form entry and failing.  I can increase my mysql logging to show results I guess, but I'm 100% sure I'm typing in the right password and running the example query_lookup in the backends.php (which is obviously still commented out but customised for my sanity) returns the correct result from the CLI.  

That means there's something in the checking algorithm that's choking - no?  I find that difficult to believe otherwise there'd be a ton of stuff out there on it :)

What do you suggest?  And thanks for your prompt reply!

SPB