SparkWeb with Zimbra XMPP backend?

I’ve been successful configuring Spark (thick client) to authenticate agains and log into our Zimbra IM server. This has been an exciting event for me, so the obvious next attempt was to configure SparkWeb to do the same thing. It “looks” like it should work, but I’'m getting the infamous login errors I’ve seen 50 times in this forum.

I think I may be close, but I just cannot tell.

  • my Spark client is 2.5.8

  • my Zimbra account would be of the format "user.name@domain.name"

  • On the login page, I’ve configured my “server” name to reflect our “domain.org

  • in the SparkWeb.heml, I’ve configured the server name to the server’s FQDN “server.domain.org

I can connect SparkWeb to a local OpenFire server (I’ve done so to prove myself sane), but I cant connect to the Zimbra XMPP server to dave me.

I’m finding no errors on the httpd server iteslf, nothing that stands out as helpful on my end. I’ve read until my eyes hurt and I’m stumped.

Anyone out there able to make this happen?

Use the debug version of the Flash Player. It will show you any errors being throw by the Flex code.

Is Zimbra supporting http-bind?. If not, then you have to use socket and follow the discussions about the problems with policy-file requests.

I’ve been capturing packets between my Zimbra server and my Firefox/Apache workstation.

Here’s my SparkWeb.html section:

function jive_sparkweb_getConfig()
{
return {
server: “zimbraserver.domain.org”,
connectionType: “socket”,
port: “5222”,
policyFileURL: “http://localhost/crossdomain.xml”,
autoLogin: “false”
};
}

Problem 1) No MATTER what I change the server setting to, the SparkWeb login page keeps reverting to the server name I was using when testing a totally local install (and the OpenFire server is shut down, so I don’t think it’s grabbing it from there). It’s as if the HTML file is cached somewhere (and yes, I keep clearing my Firefox cache first). I have to manually edit the server field to replace the name of the OpenFire server with the name of my Zimbra server before any attemt to communicate with the Zimbra server is accomplished.

Problem 2) I’ve tried numerous variations on the policyFileURL (http://localhost, http://localhost/, http://localhost/crossdomain.xml, xmlsocket://localhost/crossdomain.xml, xmlsocket://apache.domain.org/crossdomain.xml, http://apache.domain.org, http://apache.domain.org/, http://apache.domain.org/crossdomain.xml, ad infinitum) to no avail.

Once I manually edit the server field (on the SparkWeb login page) and my Firefox/Apache workstation starts talking with my Zimbra XMPP server, the Apache server ALWAYS sends a packet that looks like it’s asking for the policy file, even though I’ve been telling it to grab the copy stored locally. Taken from the packet capture, this snippet is being sent from my Firefox/Apache workstation to the Zimbra server:

Jabber XML Messaging

extensible Markup Language

\000

It looks like the Zimbra server then ACKs the msg, then the Firefox/Apache workstation FIN, ACK followed by the same thing from the Zimbra server and it’s all over.

Never does the login data ever get transmitted.

And yup, the crossdomain.xml file does exist on my Firefox/Apache workstation, I can access it through the HTTPD server directly, and it contains this:

<?xml version="1.0"?>

(where “domain” is substituted for my organization’s real domain).

Why does the server name never inherit the changes to the SparkWeb.html file?

Am I supposed to be able to pass the crossdomain.xml file using the policyFileURL directive in the SparkWeb.html file? That’s what my reading leads me to believe.

Why does my Firefox/Apache workstation appear to be requesting the crossdomain.xmlfrom the Zimbra XMPP server instead of the Apache server as I’m trying to direct it to do?

Just a little more update, hoping this will assist others in their search.

I tried running the Openfire server locally, running the Apache server locally and the SparkWeb client locally and have had wonderful success doing so.

I fired up a Perl server (sample script provided by Adobe) to supply the crossdomain.xml file, configured the SparkWeb client to request the crossdomain.xml file from port 843 (from the Perl server) and log into the Openfire server running locally. I could see the Perl server supply the file to the client and the local Openfire login proceeded as planned.

I shut down the local Openfire server, tried again, could see the Perl server supply the crossdomain.xml file to my client BUT the login failed (heck, the Openfire server was shut down after all.

So I then configured the client to log into a XMPP server on a different and remote server, while changing nothing else. I also launched Wireshark to trace packets between my client and the remote XMPP server. I fired up the client and pointed it at the local Apache server. The login page started but the local Perl server DID NOT provide the crossdomain.xml file to the client.

In fact, I could see the request for the crosdomain.xml file come from my client being sent to the physical server on which the XMPP server was running, RATHER THAN requesting it from the local port as it was before.

So, it looks to me like something (is it the Flash or is it Sparkweb?) is ignoring the “policyFileURL” directive in the SparkWeb.html file (which is what I changed to get the local Perl server to offer the crossdomain.xml on port 843 in the first place).

SOOOO … it kinda looks to me like (I am not a software engineer) like the only way (with the current Sparkweb) to log into ANY XMPP server is to provide the crossdomain.xml file from the same physical machine on which the XMPP server is running? Does that make any sense? According to Adobe, I’m supposed to be able to provide that file on one server and provide the other app backend on another, but what do I know.

Since the XMPP server I’m trying to attach to is running on a productin server, I cannot readily test the theory by firing up the Perl script on that box.

Maybe someone else has more knowledge of these things and a light-bulb will go off.

Here’s hoping…

Cheerios.

See my comments about Flash player behaviour with PolicyFile request.

_http://www.igniterealtime.org/community/docs/DOC-1553

You may be experiencing the same issue.