Password change not immediately effective

I am using the API for the last several days – quite easy to learn!

I have hit what appears to be a timing problem related to changing a user’'s password.

I have a Java Swing GUI with an account management panel. From the panel, you can create an account, delete an account, and I was trying to add a change password feature.

I create an XMPP connection. I login to that connection as the user using the old password and then get an AccountManager for the connection and then pass in a new password using the changePassword method. If I close the connection and then create a new one, and attempt to login to the connection as the user using the new password, I get an XMPP Exception: 401 Unauthorized. If I immediately try and login as the user with the old password, most times I can still login!

If I wait long enough, the old password will no longer work and I must then use the new password to make a connection.

So I have 2 questions: 1) has anyone else seen this? and 2) is there a work-around? I am using the Jabberd 1.4.3 server. I have gone through my code looking for an error on my part but can’'t find one. Plus, if I wait long enough (sometime nearly a minute is required) the new password is effective.

I would recommend testing with another server to see if it’'s a server bug – maybe Jive Messenger?

-Matt

Following up my original post:

I checked with the Windows client Exodus and my development server (jabberd 1.4.3). I changed the password with it (got a confirmation alert from Exodus that the password change worked), immediately closed the client, re-opened it and tried to login with the new password. This login attempt failed, but then changing the password to the old one and then logging in DID work. I then closed the client down, waited about a minute, and then logged in with the new password and that worked as well.

So the problem is clearly server related. It may have something to do with how the file system is used to store .xml files that have the password contained in them. The update to this file is made but there is a delay until a read from the file picks up the new password. It also may be machine/OS related. So far, I have only attempted this running the server on a Mac OS X box (10.3.6).

There are some pre-existing historical reasons why this server and this version (not the 2.0 version) are being used. Our target environment is actually Sun Solaris. Perhaps in the future, a switch to a new server or machine platform might be called for.

Jim,

Can I suggest Jive Messenger as a server alternative?

-Matt

The Java 5.0 requirement means that I can’'t use the latest Messenger in my development environment (Mac OS X based). I just downloaded the 1.1 version and will give it a try.

In reviewing the Messenger forum postings and documentation, I have learned that support for permanent (or persistent) chat rooms is not complete in Messenger 1.1. Although I believe that full MUC support, including permanent rooms, is available in Messenger 2.0+. My development environment (Mac OS X) does not yet offer Java 5.0 so that rules Messenger 2 out for now.

My intranet application requires the ability for an administrator to set up some defined rooms for internal users. I am currently using a Perl script that comes with jabber 1.4.3 to create these rooms. I also understand that some clients such as exodus support permanent room creation as well. But if Messenger 1.1 (the latest with Java 1.4.2 support) does not support permanent rooms, then using such a client will not help.

If I am wrong in my assumptions about Messenger 1.1 and permanent rooms, please advise.

Jim,

Yep, MUC isn’‘t fully supported in Messenger 1.1 – you’'d need to use 2.0 for that. Hopefully Apple will release their next OS (which includes Java 5) soon.

Regards,

Matt