Password decryption failing

is this the reason for this error message:

"Wrong combination Username / Password. Please re-login to the site for synchronization" ???

Most likely a wrong username or password, for every update to that table there is an encrypt for the password.

For every time the password is needed there is a decrypt. Unless you have other alterations to the module this should not be failing at all

Are you guys getting this issue resolved any soon, I think I'm affected as well as result XWChat can't connect because of this error: Wrong combination Username / Password (While the xmpp rooster works finely). Please re-login to the site for synchronization. Practically this makes the whole module useless, would be nice to have just even a workaround for the time being... Thanks.

This code is written with ldap in mind and works without issue.

For the non ldap portion i would suggest you show the password field on the user edit form and then enter the password in there.

That will then save the password and it will be utilized correctly.

also make sure the save password on login is not checked.

Ok i tested a bit more in "LDAP" environment using the same drupal login password everything works... yet if I try to save a different password and not use the drupal login one, the error returns.

For me, the problem is that the value of $account->xmpp_user->password is not encrypted.

I'm trying to figure out why, but that's causing me problems.

Here's the fix:


function xmpp_user_update($edit, $account, $category = NULL) {
...
...

elseif (isset($edit['xmpp_user']['password']) && !is_null($edit['xmpp_user']['password']) && drupal_strlen($edit['xmpp_user']['password'])) {
$password = xmpp_user_encrypt_password($edit['xmpp_user']['password']);
db_query("UPDATE {xmpp_user} SET jid = '%s', resource = '%s', password = '%s' WHERE uid = %d", $edit['xmpp_user']['jid'], $resource, $password, $account->uid);
$edit['xmpp_user']['password'] = $password; // <----------- store the encrypted password
}

......
......

Can you put the fix into a cvs diff patch based off the current branch then i will be able to look at it and determine if it wont break the functionality which currently works on all 100+ sites it is deployed on our end.

Not quite sure if this is the same issue I'm seeing; I cannot get xmpp client to successfully auth against my ejabberd server.

I tried the method in comment #7 to check whether the password was being sent encrypted or not, but as far as I can tell, it's using digests which change on each connection attempt so no mileage there.

Also tried wiresharking the conversation which just confirmed the firebug findings.

If anyone has any suggestions as to how I might debug this further appreciated.

Darren, are you still waiting for a patch so that you can validate the fix?

Thanks.

Hi Brandon,

Yeah, I tried with and without SASL. With it on, screen width auth strings were being passed around, with it off, a smaller digest was being passed, possibly md5sum length, I didn't count exactly.

The module is currently unusable. We are not using an LDAP environment. I am able to log in fine with GAIM, but not with the browser, with the aforementioned error: "Wrong combination Username / Password. Please re-login to the site for synchronization". I've tried the fix in #9 to no avail. Looking in firebug, I see several calls, none of which seems to send a password of any kind for authentication. (I see two calls to query xmlns="jabber:iq:auth", the second of which does have:

<username>admin</username><resource>admin</resource><digest>488167baf272b1e0ab6ee8d479bc0d554cede0b7</digest>

Is the digest the encrypted password? It does not match either the plain text password nor the encrypted password stored in xmpp_user. Help!

Aaron,

The module is usable for me. I've applied many patches over time (mine and others), most of which are in the issue queue. Hopefully Darren will apply the patches (or already has in CVS?).

I've noticed that most of the bugs I ran into were related to non-LDAP setups, simply because Darren's environment uses LDAP. If someone could test the module from the ground up in a non-LDAP setup, as well as for each module update, that would be awesome.

I've created the DXMPP module (nearly complete but already working on our servers), which exposes a themeable XMPP chat client to Drupal. This suited our needs, and was faster than trying to fix the non-LDAP configuration problems I was running to with XMPP Framework. Perhaps I can add support for the XMPP Framework module to that module in the future for authentication.

have the same problem. how could I help you with the debugging thing ?