A Flash Developer Resource Site

Results 1 to 9 of 9

Thread: [CS3] : cross-domain-policy well formed but rejected AS2

  1. #1
    Junior Member
    Join Date
    May 2008
    Posts
    6

    [CS3] : cross-domain-policy well formed but rejected AS2

    We have a multiuser chat that runs with an XML socket written in AS2.

    Since the April 2008 upgrade to Flash Player 9 our chat no longer works. We have put in a cross domain policy as per the developer centre blurb. The player seems to request the policy and get a success, but then it requests the policy again. This is the error we get from the Flash log:

    Warning: [strict] Ignoring policy file at xmlsocket://arnold.infodiv.unimelb.edu.au:8080 due to incorrect syntax. See http://www.adobe.com/go/strict_policy_files to fix this problem.
    Error: SWF from http://arnold.infodiv.unimelb.edu.au...atchatchat.swf may not connect to a socket in its own domain without a policy file. See http://www.adobe.com/go/strict_policy_files to fix this problem.
    *** Security Sandbox Violation ***
    Connection to mojo.infodiv.unimelb.edu.au:8080 halted - not permitted from http://arnold.infodiv.unimelb.edu.au...atchatchat.swf

    We cannot use port 834 because the university will block any unusual ports below 1024.

    It seems that the player is receiving the policy but rejecting it for some reason (yes it is properly formed - we've tried a range taken from the developer site and hand written from scratch). Needless to the say the socket closes and our chat is stuffed.

    Any ideas anyone? Anyone else facing similar issues?


  2. #2
    Senior Member
    Join Date
    Aug 2000
    Location
    Montréal
    Posts
    14,141
    Check the 1st sticky in this forum. You may find some info in the posted links.

    gparis

  3. #3
    Junior Member
    Join Date
    May 2008
    Posts
    6
    Thanks for the reply but we've done that. We get the lovely Deneb's happy visage and 7 pages of circular hell. We understand the concept but we can't get it to work.

    We've consulted Peleus
    http://www.adobe.com/devnet/flashpla...icy_files.html
    and used his policy with the stand alone Flash thing and that does work, but we can't get it to work on our server.

    We'll try it tomorrow using a different server. Maybe it's something in the config.

  4. #4
    Junior Member
    Join Date
    May 2008
    Posts
    6
    Oh sorry, you mean this one?
    http://www.adobe.com/devnet/flashpla...#socket_policy
    Yep, we've puzzled over this one too. Still working on it :-)

  5. #5
    Junior Member
    Join Date
    May 2008
    Posts
    6

    Nope, still can't get it to work

    It still won't work. When our programmer sends the code to the chat swf with the stand alone policy testing Flash it works.

    When he loads exactly the same chat swf and policy onto the real server it doesn't work.

    We can't use port 834 so we added System.security.loadPolicyFile("xmlsocket://arnold.etc:8080");
    into the swf as outlined in: http://kb.adobe.com/selfservice/view...nalId=kb400764
    - no joy.

    As I mentioned before using a port below 1024 is problematic for us. How important is it? If we specify port 8080 in the request shouldn't it be ok?

    I tried saving the swf as AS3 - no joy.

    Our guru has even tried a more recent version of java in case that makes a difference. Any ideas gratefully received.

  6. #6
    Junior Member
    Join Date
    May 2008
    Posts
    1
    Sorry, I can't help but I just wanted say/rant that we're experiencing the exact same problem.

    Thier stand alone sample server works fine. But since we, like you, can't run a server on port 843 I opted to modify our server to provide the policy file upon request to the SWF on the same socket it is using to connect to the server. According to the docs, this is supposed to work. And according to the Flash logs, the SWF gets the policy file but then rejects it because it claims it has invalid syntax. Which is, of course, a bunch of bullsh*t. Here's all I have in my policy file:

    <cross-domain-policy>
    <allow-access-from domain="*" to-ports="*" />
    </cross-domain-policy>

    And the Player rejects it due to invalid syntax. I, of course, tried the policy file provided with their sample master socket policy file server and that gets rejected as well due to invalid syntax. BULLSH*T!!

    Man, I can't tell you how much I'm fuming at the ears right now at Adobe. We have a customer waiting on getting this damn thing to work (which worked fine prior to this stupid security update). This clearly seems to be a bug in the Player, but they don't seem to be owing up to it all. Just silence. We're not the only ones complaing about this issue if you do a Google for it.

    It's bad enough they thrust this brain dead scheme upon us (what genius thought of doing a dedicated server on port 843 anyway?!?!). Then their implementation doesn't even work as documented. They must follow the "if it compiles, ship it!" philosophy in their Q/A. Lol!

  7. #7
    Senior Member
    Join Date
    Aug 2000
    Location
    Montréal
    Posts
    14,141
    I suggest you contact the people at Adobe. In case you find a solution to that issue, posting it here would be very much appreciated.

    Thanks

    gparis

  8. #8
    Junior Member
    Join Date
    May 2008
    Posts
    6

    Resolved

    So I'm paraphrasing our java guru here:

    He has gone back to the original swf file but has rewritten some code to change the way the swf interacts with the server.

    We used to have the server send a "server ok" kind of message on connection with the swf - very simple xml just so we know the connection is working. The flash player was getting this message appended to the policy file so therefore the xml was not well formed thus the syntax error.

    So now the server waits for the request from the flash player. If a person runs a chat session the server doesn't do anything, just listens for requests. There is a null character at the end <policy-file-request/> and at the end of our home-made chat login request. He has set the server to receive byte by byte. When it receives a null character it checks to see if the request is a policy request or a chat login request (in our case it can only be one of these two things). If it is a policy request the server sends back the policy and closes the socket. From there the swf will run as it used to ie. it opens another socket to send and receive the chat content.

    Simple huh?

  9. #9
    Junior Member
    Join Date
    May 2008
    Posts
    6
    btw, I did contact Adobe and they did get back to us. They are going to put up a more concise version of the instructions.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  




Click Here to Expand Forum to Full Width

HTML5 Development Center