Auto reconnect

[dteleguin]

It may seem at the first sight that the very principle of BOSH and HTTP long polling is not prone to disconnects. However, there are situations even BOSH cannot cope with. We have received a lot of complaints on sporadic JSXC disconnects from our users. That means, the host system (RoundCube, ownCloud etc.) continues to function, but the JSXC sidebar suddenly shows disconnected message and offers to re-enter username and password. This may happen as often as several times a day, and is very annoying.

By analyzing the logs we've managed to figure out the following sequence of events:

1. the client sends the next long polling HTTP request;
2. the request doesn't reach XMPP server (due to packet loss etc.);
3. the server detects session timeout and invalidates SID (session ID);
4. the original request gets retransmitted;
5. the server receives invalid SID and responds with a 404;
6. the client reacts to this response by transitioning into disconnected state.

We attribute this to network instability. However, I can imagine situations where either network or a XMPP server goes down and up again after some time - the outcome will be the same. It would be nice to have an auto reconnection feature for situations like that.

[sualko]

Our research group is currently working on an auto reconnect feature which uses tokens like TURN-REST-API. So stay tuned.

[dteleguin]

@sualko sounds cool! Is it gonna use oAuth tokens, or something ad-hoc? If latter, will it be possible to extrapolate this mechanism to oAuth / OpenID Connect?

For a long time I've been thinking of bringing thing together with the help of oAuth. This could finally help to decouple authentication process to an external entity. Moreover, this could enable virtually any kind of authentication - traditional login/password, OTP, SSL certificates, smartcards, or any combination of the above - without modifications to JSXC or a host system. The workflow is roughly the following:

• a user tries to access the system;
• if not logged in, the user is redirected to the authentication server;
• the user authenticates himself according to the auth server configuration (LDAP, two-factor auth etc.);
• the user is redirected back with a cryptographically signed token;
• the token is used to authorize the user with the resources he needs access to.

oAuth is already supported by BOSH and TURN (an least in ejabberd and coturn, respectively). There also exists an oAuth SASL mechanism (used by GMail), and I'm thinking of implementing the same for Dovecot SASL. In this case, the puzzle will be complete: the user will be able to log in once, and then to have access to all the resources like IMAP, XMPP and TURN, without each service having knowledge of the actual authentication mechanism.

BTW, I'm a contributor to the KeyCloak project. It's an OpenID Connect server, and there is a client adaptor code for pure HTML5/JS applications (called keycloak.js). I think some day I could work on a proof-of-concept standalone JSXC using external KeyCloak server (or any other OpenID Connect compliant one) for authentication. What do you think?

[sualko]

Hey, we implemented time-limited tokens into our xmpp server authentication module for prosody/ejabberd. So this is the first step for auto reconnect.

[diegobill]

👍

[diegobill]

Is there some alternative solution like this?

$(document).on('disconnected.jsxc', function(){
   setTimeout(function(){
      var reconnect = function(){
         if(!jsxc || !jsxc.xmpp || !jsxc.xmpp.conn){
            jsxc.start(JID, PASSWORD);
            setTimeout(reconnect,10000); 
         }
      };
      reconnect();
   },10000); 
});

[sualko]

@diegobill I am working on it, see #574

[diegobill]

@sualko , this auto reconnect works when xmpp server fails and stop for period of time and after starts? I tested to stop and start ejabberd and sometimes the jsxc enters in a infinit loop of reconnections.

[sualko]

@diegobill please open a new issue for that

[kousu]

I'm seeing the symptoms of the sidebar disconnecting while the rest of my website continues to function under Nextcloud. I reported details at #658