CrossDomain.xml partial rejection

Hi,
I’m currently trying to send/receive data from my webserver. I thought I had finally a working build, I can upload and download data from a standard editor build, but as soon as I switch to a Webplayer build, I get the dreaded “Unity Rejected because no crossdomain.xml policy file was found”.
I read basically everything I could about that error, from the unity sandbox manual to every forum thread I could find, but I just don’t get it now:
If it works on a standalone build, it should mean that the crossdomain.xml file exists, is at the right place with the right format and the right informations. Is there something more about the Webplayer build that requires to do things differently?
Please help me if you have any idea…
Thanks!

Olivier

I’ve not had too much trouble with this… I basically followed the settings for my flash client (running in browser) and the exact same settings worked for me for the Unity web player.

You need to run 2 services on your server machine. On port 843 - the service should simply return your crossdomain xml file. And on port 80 your regular application web server.

Thanks for your answer Dhruv!
I’m really a beginner when it comes to servers… My guess is that the service on port 843 returning the crossdomain.xml is functionnal server side since it works in standalone mode. Maybe there is something to do with port 80, I’ll try to investigate and find some tests to narrow the field of investigtation…

By standalone, are you referring to the standalone Mac/Windows desktop apps? Then those don’t require crossdomain xml file. Only when running in the web player does unity make those requests to port 843. So just because your desktop app is working doesn’t mean that your crossdomain xml is setup correctly.

Damn you’re right! I was sure a functionnal desktop version meant crossdomain.xml was fine, but I just removed the file from the server and the desktop version keeps working fine, so there…
I tried to telnet my server and port 80 is open but not port 843, so there goes the explanation…
Since I’m on a mutualised server I won’t be able to open the port, but those are other problems!
Thanks again for your help, I don’t know how many hairs I would have pulled off my head without your advice :stuck_out_tongue:

haha this is hilarious, I was struggling with same issue and noticed that port 80 is open but not port 843 :smile: thanks for creating this thread and solving my issue at the same time heheh

If all your communication is through Unity’s WWW class then you don’t need unusual ports open, you only need the regular webserver ports to work, serving crossdomain.xml via HTTP or HTTPS (whichever you’re using for your other communication). Usually that’s just a matter of putting the crossdomain.xml file in the root of your web domain, and you don’t need port 843 for that.

If you’re using anything other than Unity’s WWW class then you need to serve crossdomain.xml in an alternate way, as a response to a TCP connection on some port. The default for that is port 843 but you can also configure it.

What I get from the Unity documentation and the previous answers:

  • there are 2 policies to get: the WWW policy and the socket policy
  • the WWW policy is given by crossdomain.xml and fetched using http on port 80
  • crossdomain.xml is not needed if it is the same domain that is hosting the unity3d file
  • the socket policy is fetched from port 843 by default, using a trivial server that implements the
  • I can change the port for the socket policy with Security.PrefetchSocketPolicy()
  • I shouldn’t need the socket policy since I’m only using Unity’s WWW class

What I don’t get:

  • I use the web functions from the EasySave lib, its author confirmed to me he only uses WWW class from Unity.
  • I get a crossdomain.xml not found error even though my port 80 is open, my file is saved in UTF8 with the basic windows7 notepad in the root directory
  • I get the “no crossdomain policy found” error when I launch a build from the editor on my local machine, but also from the webplayer launched from my server, even though in that case it should not even need it

So I guess I’m still missing/misunderstanding something, if anyone has some suggestions left, I can’t wait to hear them… :stuck_out_tongue:

Thanks again for your time!

Did you try enabling the debugging log - see the Debugging section of http://docs.unity3d.com/Documentation/Manual/SecuritySandbox.html.

The main reasons I’ve had failures with this stuff in the past were:

  • Trying to use anything other than “*” in the allow-access-from tag (it’s not supported, or wasn’t back then)
  • Not hosting the crossdomain.xml file with the right protocol - if you’re doing an https request through WWW then you need a crossdomain.xml at the root of your secure server too
  • Weird issue when performing https WWW requests from an app that was itself only served by http (or vice-versa?) - my memory is hazy but I think I had to add an additional directive to the crossdomain file for that.

I’m using “*” and no https so that’s not it. I activated the debugging log and it has given me this error though:
UriFormatException: Invalid URI: The format of the URI could not be determined.
MonoForks.System.Uri…ctor (System.String uriString, Boolean dontEscape)
MonoForks.System.Uri…ctor (System.String uriString)
(wrapper remoting-invoke-with-check) MonoForks.System.Uri:.ctor (string)
MonoForks.System.Windows.Interop.PluginHost.get_SourceUri ()
MonoForks.System.Windows.Browser.Net.CrossDomainPolicyManager.GetCachedWebPolicy (MonoForks.System.Uri uri)
UnityEngine.UnityCrossDomainHelper.GetSecurityPolicy (System.String requesturi_string, IPolicyProvider policyProvider)
UnityEngine.UnityCrossDomainHelper.GetSecurityPolicy (System.String requesturi_string)

So I guess the problem could simply be one of using a wrong formatted web adress, the weird part being that I only get this error in webplayer mode…
Since I can’t access the code from EasySave that makes the www calls, I contacted the guy who makes EasySave, he is usually very quick to answer so there’s still hope :stuck_out_tongue:

Hi, I finally solved my problem, which turned out to be 2 problems (so that when I fixed one on a wild guess the other one would still prevent stuff to work properly)
The first problem, to my shame is that I saved the crossdomain.xml file in UTF-8, which I thought was equivalent to ASCII but is not, turns out you have to save your file in ANSI.
The second problem was the host url in the editor’s “www security emulation” field: I tried to leave it empty, to put the adress of my server, to put the adress of my Unity file… But in order to work I had to put the adress of the EasySave php script.
Si big thanks to everyone who helped, and to Joel from EasySave who answered very quickly and took the time to debug on his side!