I posted something about this a month or so ago, but I got no response. When trying to get a client to log into the Openfire server, I noticed that the response it sends in reply to the initial client xmpp-bind request has a bad value for the “to” attribute. Things work correctly if the client ignores this value, but if the client attempts to validate it against the JID they are currently logging in as, it won’t match.
I suspect the problem is that the final JID for the session is only being established by the request being replied to, and this may not be in place yet when the response to this message is generated. Later responses have the proper JID filled in. Here’s an example of an exchange which illustrates the problem:
From client to server (after TLS and SASL negotiation is complete):
jblilyServer’s response:
maker@xmpp.timeheart.net/jblilyNote the value of “xmpp.timeheart.net/1cc0837b” here – the initial authentication was for "maker@xmpp.timeheart.net" and the resource requested was “jblily” in this case. Later messages look correct, though. For instance:
From client to server:
Server’s response:
I think it would be better if Openfire was changed to return this final JID value even in the initial xmpp-bind response. Either that, or it should leave off the “to” completely in these responses. That’s what is shown in section 7 (Resource binding) of RFC 3920, and that’s what I’ve seen other XMPP servers do.