Security.loadPolicyFile() not working?


I’ve got openfire (3.6.0) running, trying to connect via xiff. I keep getting a security error when trying to run my script locally for testing. Here it is:

package {
    import flash.display.MovieClip;
    import flash.system.Security;
    import org.jivesoftware.xiff.core.*;
    public class Test00 extends MovieClip     {
        public function Test00()
            Security.loadPolicyFile("xmlsocket://"  + "" + ":5229");                
            var xmpp:XMPPConnection = new XMPPConnection();
            xmpp.server = "";
            xmpp.port = 5222;
            xmpp.username = "test00";
            xmpp.password = "passw0rd";

Debugging hangs on connect() and I get this error:

there was a security error of type: securityError
Error: Error #2048: Security sandbox violation: file:///C/test00.swf cannot load data from

what else do I need to do to get this to work?

Also, will I be able to get this in a flash player through a web page, without my users having to accept any security policy stuff?


I’ve the same problem. I believe that last versions of flash player are only looking for the policy file on port 843 or the port used by the client (5222 here).

OpenFire should serv the policy file on the 5222 (since 3.5.2) but that seems broken in 3.6.0 (I’ve got errors in OpenFire logs) !

The only way I’ve found to solve this issue for the moment is to serv the policy file using a Perl script on port 843.

Hi Kochka,

Thanks for that info - I realized now actually that xiff is using some Flex classes - is this meant to be used strictly within Flex applications? (I am new to using flash, coming from C/C++/Java) - it’s a bit confusing -

I also realized I should be using XMPPSocketConnection instead of XMPPConnection, but now that I use it I get compile errors related to missing Flex class ‘ArrayCollection’.

Wondering if you’re using it within Flex? I guess once I can get it to compile again, I can try serving up the policy file using perl.

I don’t understand the state of xiff, it seems like the openfire dev team has kind of neglected it, there isn’t really documentation and a lot of people seem to be having problems with the policy file?



I’m using Flex 3.

You can found a Perl and Python daemons scripts to serv policy files here :

ArrayCollection is an AS3 class only I think. What flex version are u using ?

For Xiff state, I don’t know, but there are developping Spark Web on it.

I’m more worried with OpenFire and I hope we will get a new version soon that fix theses policy issues.

Ah ok I’m using Flex3 as well, so that makes me feel better! Thanks for that link, seems I’ll have to use it.

I thought that the openfire project itself was pretty active, they just released a few updates over the last week? I guess it’s time to start bugging them about it to see what’s up. It seems to be a really great product so far.


The project is active but we was used to get a new version each month, and no new version till quite 3 monthes make me worried

And I’m not a java dev, so I can’t help to fix the server issue

Did you try v3.6.1? I wonder if that fixes it? If not, I guess a bug should be logged. I could take a look at the java code to see what they’re doing.

Oh Sh_t I’ve missed that 3.6.1 is out lol

I’m going to test it right now and tell you if it’s working or not.

It’s the same with 3.6.1

This is madness!

Well, but you have it working by serving up the policy file via perl, right?

So you have a flex 3 app working with openfire 3.6.1 -

until they fix the policy thing, that should work ok?

Right, I’ve a flex 3 app working with openfire 3.6.1 and using a f___ing perl script

Maybe i’m wrong, but Openfire is sending the policy file through the 5229 port. You can try to telnet that port and you’ll get

<?xml version="1.0"?><!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia


That’s what I read in a few different places, shouldn’t this call take care of it?:

Security.loadPolicyFile("xmlsocket://"  + "" + ":5229");

also just got a post from another user here about this:

about the bug in 3.6.0 (if it is a bug, I'm not sure) - could that be the problem?