powered by Jive Software

Xmpppy library unsupported?

I can’‘t manage to authenticate against Jive Messenger using the python XMPP library xmpppy. The same code that allows me to connect/auth with our jabberd1.4 server and jabber.org (don’‘t know what server they run) won’‘t work with Jive Messenger. What is needed from me to go further? Here’'s a clip of some debugging:

DEBUG: socket sent testingcc42c080067fe0eac1e311222ef3b9a1a5fd6a54tipJab</re source>

DEBUG: dispatcher wait Waiting for ID:2 with timeout 25…

DEBUG: socket got

That’'s the digest for “testing” in there (and after looking at the “Preview”, ignore the smileys…).

That account is registered on the server.

tiptone,

There’‘s a private data request in there to “private.jabber.org”. Do you know why that would be? Obviously, it will fail since you’'re not connected to jabber.org

Regards,

Matt

Sorry, I just edited the address out, I’‘m connecting to our development jabber server (forgot ‘‘jabber.org’’ was a server you would recognize). It’'s actually trying to connect to a server address that is there.

I’'m doing the testing to see if Jive Messenger will make a good replacement for jabberd1.4.

Is the issue fixed then? Can you post updated debug info if not?

Regards,

Matt

No, the issue is not fixed. Here’'s the useful bits from debug (actual jabber server address has been replaced with “private.jabber.server”):

DEBUG: socket sent <?xml version=''1.0''?><stream:stream version=’‘1.0’’ xmlns:stream=’‘http://etherx.jabber.org/streams’’ to=’‘private.jabber.server’’ xmlns=’‘jabber:client’’>

DEBUG: socket got <?xml version=''1.0'' encoding=''UTF-8''?><stream:stream xmlns:stream=“http://etherx.jabber.org/streams” xmlns=“jabber:client” from=“private.jabber.server” id=“df8c8526” xml:lang=“en”>

DEBUG: socket sent testing

DEBUG: dispatcher wait Waiting for ID:1 with timeout 25…

DEBUG: socket got testing

DEBUG: socket sent testing988caca83b995e412a2a7740347b4f84b1041552tipJab</re source>

DEBUG: dispatcher wait Waiting for ID:2 with timeout 25…

DEBUG: socket got

Followed by the library discovering the error and bailing out. Same code works for connecting to jabber.org. Here’'s what the last segment above looks like when connecting to jabber.org

DEBUG: socket sent testing988caca83b995e412a2a7740347b4f84b1041552tipJab</re source>

DEBUG: dispatcher wait Waiting for ID:2 with timeout 25…

DEBUG: socket got <iq id=’‘2’’ type=’‘result’’/>

As far as I can tell, the same packets are being sent out to both servers, but the Jive Messenger server doesn’'t handle something correctly. I have subbed in another uname/passwd above where connecting to jabber.org, a real account was acutally used for testing.

Let me know if I can get you more/better info.

Thanks,

Brian

Brian,

Have you verified that you can connect to the account on your local Jive Messenger server using another client program such as Exodus?

Regards,

Matt

Matt,

Yes, I have no problem connecting to the server with Gaim and Gabber on SSL(5223) and non-SSL(5222) ports. I even fired out a quick PHP script using class.jabber.php to test and it works as well.

I’‘ve mentioned the problem to the maintainer of the library I’‘m using, hoping he might have some insight. But since the problem only appears when connecting to Jive Messenger, I’'m working on the assumption that the problem is on the server end.

Here’'s two seperate debug logs, one a success connecting to jabber.org, the other a failure connecting to the Jive Messenger server. Passwd digests replaced with “PASSWD DIGEST HERE” and server hostname replaced with “private.jabber.server”.

Success:

http://www.shsu.edu/~ucs_bmt/jabber-log-success.txt

Failure:

http://www.shsu.edu/~ucs_bmt/jabber-log-failure.txt

Let me know if I can get you anything else.

Thanks,

Brian

Brian,

I think I see the issue. The IQ you send back to the server is:

testingPASSWD DIGEST HEREtipJab

Notice that a AND element are present. According to JEP-0078, the user should present “one of password or digest” and not both. Messenger is probably looking for the password element first. It finds it with a blank value so tries to authenticate with a blank password and fails. It never even looks at the digest value.

So, this is really a bug in the library – it should send password or digest but not both. We could probably work around this in the server, but it’‘s really a client issue so we shouldn’'t be forced to. Please let us know what the xmppy dev gets back to you with.

Regards,

Matt

Matt,

Makes sense to me. I’'ve sent a message to the list for xmpppy and pointed to this thread.

Thanks for your (prompt) help,

Brian