powered by Jive Software

Login conflict: login from another client - BUG?

In Spark, when a user connects from another client, you get a message telling you you’ve been disconnected because someone else connected with your username. We’re trying to do this same functionallity on a Flex client using Xiff 3.0 beta. We have a listener on DisconnectionEvent.DISCONNECT:

xmppConnection.addEventListener(DisconnectionEvent.DISCONNECT, onDisconnect);

But the event doesn’t provide information as to why we’ve been disconnected.Spark uses the following code to catch the accounts conflict disconnection (Code from /src/java/org/jivesoftware/spark/ui/ContactList.java on Spark source):

Code:

public void connectionClosedOnError(final Exception ex) {
        String errorMessage = Res.getString("message.disconnected.error");

        if (ex != null && ex instanceof XMPPException) {
            XMPPException xmppEx = (XMPPException)ex;
            StreamError error = xmppEx.getStreamError();
            String reason = error.getCode();

            if ("conflict".equals(reason)) {
                errorMessage = Res.getString("message.disconnected.conflict.error");
            }
            else if ("system-shutdown".equals(reason)) {
                errorMessage = Res.getString("message.disconnected.shutdown");
            }
            else {
                errorMessage = Res.getString("message.general.error", reason);
            }
        }

        final String message = errorMessage;
        SwingUtilities.invokeLater(new Runnable() {
            public void run() {
                retryPanel.setClosedOnError(true);
                reconnect(message);
            }
        });
    }

Is there a way to know we’ve been disconnected because someone else has logged in with our user with XIFF? Or is this something that should be implemented from scratch on Xiff?

We’ve found there’s a probably unfinished/incomplete code on the handleStreamError function on XMPPConnection.as:

protected function handleStreamError( node:XMLNode ):void {
     dispatchError( "service-unavailable", "Remote Server Error", "cancel", 502 );

     // Cancel everything by closing connection
     try
     {
          socket.close();
     }
     catch (error:Error)
     {

     }

     active = false;
     loggedIn = false;

     var disconnectionEvent:DisconnectionEvent = new DisconnectionEvent();
     dispatchEvent( disconnectionEvent );
}

As you can see, a hardcoded 502 “service-unavailable” error is dispatched. The error could be caused by several reasons (400 bad request, 409 conflict, etc more here » http://xmpp.org/extensions/xep-0086.html)

Is this right? Should it be reported as a bug?

To temporarilly solve this problem, we’ve wrapped the XMPPBOSHConnection with our own XMPPCustomConnection overriding handleStreamError to detect conflict error. This could be more specific to handle each error type.

package patchxiff
{
    import flash.xml.XMLNode;
   
    import org.jivesoftware.xiff.core.XMPPBOSHConnection;
    import org.jivesoftware.xiff.events.DisconnectionEvent;

    public class XMPPCustomConnection extends XMPPBOSHConnection
    {
        public function XMPPCustomConnection()
        {
            super();
        }
       

        protected override function handleStreamError(node:XMLNode):void
        {
            if (node.firstChild && node.firstChild.nodeName == "conflict") {
                dispatchError("conflict", "Login conflict", "cancel", 409);
            } else {
                dispatchError( "service-unavailable", "Remote Server Error", "cancel", 502 );
            }
           
            // Cancel everything by closing connection
            try {
                _socket.close();
            }
            catch (error:Error){
               
            }
            active = false;
            loggedIn = false;
            var event:DisconnectionEvent = new DisconnectionEvent();
           
            dispatchEvent( event );
        }
    }
}

Hi,

Could you provide a diff against the current svn trunk version of the additional handling of error messages?

I uploaded the diff on the other topic:

I got confused with both fixes :S