Do XIFF2/XMLSockets still work with Flash v9,0,124?

Our working XIFF2 client broke with Flash v9,0,124 (released 3/31/2008). After much trouble-shooting, it seems that this is related to some changes to policy files (crossdomain.xml) first introduced in v9,0,115, and just now starting to be enforced.

Here is a good writeup of the changes: http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html

"Specifically, the strict rules always require permission from a socket

policy file in order to make a socket connection, even when the socket server

appears to be the same as a connecting SWF file’s domain of origin."

Our client makes an expliit poicy file check with Security.loadPolicyFile() to the host:80, while the actual XIFF2 connection is oppened to host:5222. This worked on previous Flash versions, but now is explicitly not allowed.

If you enable Flash logging, the exception is:

Error: Request for resource at xmlsocket://host:5222 by requestor from http://…swf has failed because the server cannot be reached.

I understand this was addressed by JM-537 (http://www.igniterealtime.org/issues/browse/JM-537)? If so, how do we actually utilize that bug fix from our XIFF client?

Currently, we are using Openfire 3.2 and XIFF2, but I understand we may have to upgrade to Openfire 3.4 to get this bug fix to work, or even Openfire 3.5 + XIFF3 and use BOSH instead. What’s the recommended setup now?

FYI - I was able to work-around this issue by installing Openfire 3.5 (3.4 worked, too), which implemented the mentioned feature.

Then, I changed my code from:

Security.loadPolicyFile(“http://” + this.hostname);

To:

Security.loadPolicyFile(“xmlsocket://” + this.hostname + “:5229”);

Hi,

The work-around you have provided doesn’t work for me…

I’m using Xiff2beta4 and Openfire 3.5 (and the port 5229 is oriented to the FlashCrossDomainServlet)

Is there something I missed?

Do I need to upgrade to Xiff3?

Is there an ultimate solution???

Thanks

That should be the correct solution; it’s not a work-around. Adobe purposely disabled using a crossdomain.xml over HTTP and then connecting to another port with a socket.

See: http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html

I would recommend following the directions there to enable policy file logging on the Flash player side. That will give you a good idea of what’s failing. One thing I noticed was that the policy file query has a 3 second timeout. Our Openfire test box is a VM on an overloaded server, so we sometimes get the timeout.

But that’s actually what your code do, connect to the 5229 port from you swf… Does it?

I’ve read all the Adobe articles concerning this new security patch and one of them that says clearly you must have a xml response from the 843 port…

Security.loadPolicyFile()

loadPolicyFile()

+"If an ActionScript command exists within the SWF file, then the Flash Player runtime checks that location. Flash Player checks the destination of the *only after it has checked the

master policy file on port 843* for permission to acknowledge other policy

files. "+

See: http://www.adobe.com/devnet/flashplayer/articles/socket_policy_files.html

I can’t understand how do success to connect on 5229. You’re a lucky guy.

Where I’m wrong?

My understanding is that port 843 is the default polciy file socket. Flash will always attempt to load the policy file from this port if you are using XMLSockets or regular Sockets. Even when I explicitly load port 5229, I can see it also hitting 843 (and failing, because I don’t have that setup on my server). However, only one of the policy file loads needs to succeed.

I can actually see it still loading the crossdomain.xml over HTTP on port 80 also, which I now have disabled. But it still works, because the port 5229 one works. All of this information is from the Flash policy file logs, which you can enable if you are using the Flash debug player. It will tell you which policy files it tried to load, and which ones succeeeded.

I wrote a patch which allows the cross-domain to be served from the client port. This works with 9.0.124.0:

Hopefully this will be integrated into the main build.

Hey Ben,

Excellent improvement.

I hope to see it in next Openfire versions (3.5.2 and 3.6.0).

Thanks!!!

jfyi,

i’ve written a simple flash-policy-socket-server in haxe and neko both for the nekoVM which can be used instead of the python and perl from adobe, til the policy stuff is integrated into openfire.

http://blog.disktree.net/file/flashpolicyd.neko

http://blog.disktree.net/file/fpserver.zip