Flash crossdomain policy socket server

[Tazio]

Hi, everybody! 

I'm working on a simple client-server social game. System consists of game client(SWF on a remote host), which connects to my game server (Neko port 10240) and simple Policy Server (Neko port 843).  

Policy server successfully receives <policy-file-request/> on 843 port then makes an answer. But client SWF does not react on it and after few seconds makes another <policy-file-request/> this time to port 10240 where GameServer is.

What is wrong with my policy server?

Here is the policy server code:

-------------------

class XmlPolicyServer {

public function new() {

var socket = new Socket();

try{

socket.bind( new Host( "somehost" ), 843 );

socket.listen( 10 );

}catch (z:Dynamic) {

Sys.stdout().writeString("Server Start Failed. \n");

return;

}

while(true){

var cnx = socket.accept();

var msg = cnx.input.readLine();

var msg_cut = msg.substr(1, 6);

if ( msg_cut == 'policy' )

{

var sbuf = new StringBuf();

var response = '<cross-domain-policy><allow-access-from domain="*" to-ports="*" /></cross-domain-policy>';

sbuf.add(response);

cnx.output.writeString(sbuf.toString());

cnx.output.writeByte( 0 );

cnx.output.flush();

cnx.close();

}

}

}

}
-------------------

[Philippe Elsass]

Try:

var response = "<cross-domain-policy>"
+ "<site-control permitted-cross-domain-policies=\"master-only\"/>"
+ "<allow-access-from domain=\"*\" to-ports=\"*\" />"
+ "</cross-domain-policy>";

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/groups/opt_out.

--
Philippe

[Tazio]

Thanks for advice but - alas - it didn't help. I've already tried different ways the mesage is sending, its formatting, the null byte. And no result.

It makes me mad cause everything is right and it should work but nevertheless it simply does not.  It seems that swf doesn't see /or understand xml response. 

OR may be the problem is in my server OS? Or something wrong with client SWF - some weird sandbox security options that prevents it from receiving data? 

[Michel Romecki]

Hi,

Maybe it's something linked with the encoding or the charset ?
Try add that at the begining of the cross domain policy xml:

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

2013/9/12 Tazio <paul.e...@gmail.com>

[Tazio]

Puting full XML in response doesnt help either (and I ve tried that before). 

Encoding?
SWF makes <policy-file-request/> via something similar to XMLSocket and it is a UTF8.  Neko String is UTF8 too. Cant see how can be a problem here...  Please correct me if Its wrong

[Michel Romecki]

Sometimes people use the same xml for socket and http so maybe if it's bad encoded in the file, if you take that from here ... I don't know, it was a suggestion.
If it doesn't help, maybe it's something linked with the null char, try adding it into the buffer or do something around that ?

2013/9/12 Tazio <paul.e...@gmail.com>

[Philippe Elsass]

I don't think that can be an encoding problem. Do you return an additional \0 character to mark the message end?

[Tazio]

I double checked what i'm sending as a reply. I ve checked every byte in it (literally!) and I'm 99.9% sure that the reply is correct, of same encoding as the swf original request and with a perfect null byte at the message end. 100% that the problem is on the haxe/neko server side - I ve used a Python server from adobe example and it worked just fine without any errors or complications. I ve studied its code - and did not find anyhing special about it - open socket, check data, send reply as a string, close socket, etc.

The last and I guess somewhat crazy idea - SWF player understands connection stream sort of differently (from the neko). I ve heard something about BigEndian/LittleEndian formats of stream. But that is beyond my experience and knowledge.

Nevertheless I still hope somebody could point out where the problem is.

[Cauê Waneck]

Try to use a debugging proxy to check what's being sent, and the difference between the python server response and yours.

2013/9/13 Tazio <paul.e...@gmail.com>

[John Plsek]

Tested your code with a socket policy reader I wrote years ago, and it timed out waiting for response

Here's code that works with my "reader"

class XmlPolicyServer {
    public function new() {
        var socket = new Socket();
        try{

            socket.bind( new Host( "localhost" ), 843 );

            socket.listen( 10 );
        }
        catch (z:Dynamic) {
            Sys.stdout().writeString("Server Start Failed. \n");
            return;
        }
        while (true) {
            var cnx = socket.accept();

            var tbuf = Bytes.alloc(30);
            var cont = true;
            var msg : String = '';
            while (cont)
            {
                try
                {
                    cnx.waitForRead();
                    var len = cnx.input.readBytes(tbuf, 0, 30);
                    msg += tbuf.toString().substr(0, len);
                    cont = msg.indexOf('\x00') < 0; // read up to null byte
                }
                catch (e : Dynamic)
                {

                    var x = Std.string(e);
                    if (x != 'Eof')
                    {
                        trace('Error: $x');
                    }
                    cont = false;

                }
            }
            var msg_cut = msg.substr(1, 6);
           
            if ( msg_cut == 'policy' ) {   

                var response = '<cross-domain-policy><allow-access-from domain="*" to-ports="*" /></cross-domain-policy>\x00';
                cnx.write(response);
            }
            cnx.shutdown(true, true);
        }
    }
}

Note: I simplified the overly complicated write code, but that wasn't the issue. The issue was with reading the request. Also, rather than using cnx.close, I use cnx.shutdown, not sure if that makes any difference, but as least to this old coder, shutdown on a socket is the "polite" thing to do :p

I have not tested this against any SWF's, but as your code didn't ever send anything for me, I figured that could be the issue

I would also recommend including the <?xml... and the <!DOCTYPE... headers, because they are part of the specification by adobe, and I've never come across a Socket Policy Server that doesn't include them.

John

[Michel Romecki]

Hej again,
I've written some monthes ago a sample neko policy file server that can be found here :
http://mromecki.fr/blog/post/simple-socket-cross-domain-policies-neko-server
It's light and it works fine without any tricks. Maybe it can help.
I've written also a summary of the Flash Player Security with some informations for socket policy files but you probably know all of that yet:
http://mromecki.fr/blog/post/flash-player-security-and-application-domain-summary

2013/9/14 John Plsek <jaro...@gmail.com>

[Tazio]

jaromanda, 

Many many thanks! Your code is working perfectly! Even better than python server from Adobe :) 

But I still dont understand what the difference between:

var tbuf = Bytes.alloc(30);
cnx.input.readBytes(tbuf, 0, 30);


and

var tbuf = cnx.input.readAll(30);

The first one is working fine, the second one - does not at all. But they are the same! And both should give one result.. Am I wrong and why?

[Tazio]

filt3rek ,
Thanks for your tutorials! I've studied them and learned much.
Now I understand what was my mistake. Its a noobish but far from obvious. None of the correct tutorials making accent on this moment and some of them are simply incorrect. 

When reading a message, you need to remove ("read away") null byte from input stream explicitly. And when you dont - that null byte simply stays there and blocks the socket. 

[John Plsek]

cnx.input.readAll(23); MAY work as 23 is the length of <policy-file-request/> + null byte

[Michel Romecki]

Of course it works fine reading 23. Here it was just easier for me to compare 22 length string and just pop the null byte :)

2013/9/14 John Plsek <jaro...@gmail.com>