Hack to backbone.js to get buddycloud webclient + http api server + tigase (+ buddycloud java server) talking.

gistfile1.diff

@@ -1418,9 +1419,18 @@
     // Make the request, allowing the user to override any Ajax options.
     return Backbone.ajax(_.extend(params, options));
   };
-
+var credentials;
   // Set the default implementation of `Backbone.ajax` to proxy through to `$`.
   Backbone.ajax = function() {
+    if (arguments[0].credentials) {
+        console.log("Storing credentials", arguments[0].credentials);
+        credentials = arguments[0].credentials;
+    } else if (credentials) {
+        arguments[0].credentials = credentials;
+        arguments[0].xhrFields   = {withCredentials: true}
+        console.log("Setting credentials", arguments);
+    }
     return Backbone.$.ajax.apply(Backbone.$, arguments);
   };

What I found was that request #1 from the weblclient was passing authentication details through as expected.

The 2nd - 4th requests were not passing through credentials and so new sessions were attempting to be created with a jid of "@hostname" rather than "user@hostname".

Please be aware that I'm running a setup much different to the standard with buddycloud:

• buddycloud java server (latest)
• Tigase XMPP server (latest)
• HTTP API (latest)
• Webclient (latest)

... to add to this, my stack is running on ec2, all apart from the java server which is running on my local machine with ports forwarded as required. Therefore the response the webclient sees is going to be a little slower than normal. I wonder if on the production/standard setup everything replies fast enough in order that the API calls get their token for the next request?

I never seem to get the X-Session-Id set by the webclient, i.e. loads-and-loads-and-loads of new sessions!

^^^^^ this may be a consequence of hack

sessionID stuff is a bit broken right now. There's an issue open for addressing that.