I have read many threads about this subject, and I still can’t solve the problem…
Can you please please please help me out urgently?
I have setup a policy server, and got it working properly (tested it with telnet).
In my code I use the following line on awake():
if (Security.PrefetchSocketPolicy("83.142.226.16", 1026)) {
Debug.Log(":>");
}
I then try to open the following URL:
var request = WWW("http://newerth.com:1025");
When running this in the WebPlayer, I can see the application send “GET /crossdomain.xml HTTP/1.1” to my XML-RPC server running on port 1025. This behaviour is incorrect!
The same request is sent to my server when I use this method instead of PrefetchSocketPolicy:
var request = WWW("http://newerth.com/crossdomain.xml");
Why in your Unity3d Asset Folder? I just placed it in my server and it works. Flash is the only building option that doesn’t work, but it doesn’t throw an error either…
Flash handles crossdomain fetching on its own with its own security sandbox. unity can’t control that.
and its not required. The fetching you do there is not for crossdomain access through WWW but for TCP socket policy fetching (theoretically socket policy fetching but flash only has TCP) and unless I’m wrong the .NET sockets are not even supported in flash targets at the time.
For WWW you don’t need it, for WWW the crossdomain has to be at http://www.yourdomain.com/crossdomain.xml (or correspondingly on https) and thats likely where flash looks too as Unity uses flash security sandbox specs, not the silverlight one.
you might want to consult the flash security guidelines on this matter to see what and what not is allowed.
Mohican, the only solution is to host the policy file where Unity looks for it. It must be on the same protocol, hostname, and port, as the request you want to make, but in the root directory. In short, whatever is listening on port 1025 needs to serve the crossdomain.xml file itself.
This is precisely the problem!!!
I am running an XML-RPC server on port 1025.
Such servers cannot process the command “GET /crossdomain.xml HTTP/1.1” they only support “POST”.
So for this reason (amongst probably many others), it would make more sense if Unity looked for the crossdomain.xml file at the URL “www.newerth.com/crossdomain.xml”.
Or at least, allow the coder to specify “www.newerth.com:PORT/crossdomain.xml”.
Otherwise, what is the point of the field if Unity tries to fetch a copy of crossdomain.xml on every port that the coder is trying to access with WWW?!?!.
So in other words, I am gonna have to hack my XML-RPC server just so that it returns something for “GET /crossdomain.xml HTTP/1.1”?
That’s rather unpleasant if you ask me…
Important question:
Will Unity check crossdomain.xml for EACH WWW object to “http://newerth.com:1025”?
The application makes many calls to this server, and the ping of some user is 300+ms.
If the policy file needs to be checked each time, there will be serious network delays…
I have now implemented “crossdomain.xml” on my XML-RPC server. HOWEVER, the following piece code works properly in the editor but hangs indefinitely the WebPlayer:
var policy = new WWW("http://newerth.com:1025/crossdomain.xml");
while (!policy.isDone) {
WaitForSeconds(0.1);
}
if (policy.error == null)
Debug.Log(policy.text);
If you’re going to write an infinite loop, you must ‘yield return’ inside it, or your game will hang. You could just ‘yield return policy;’ instead, which will yield until it’s done. See the docs for ‘isDone’ which explicitly tell you that this kind of loop will hang in the web player. Unity - Scripting API: WWW.isDone
You shouldn’t need to fetch the policy explicitly like this. I guess you only did it for testing. But I’d expect that if the policy is invalid, you won’t even be able to see the policy… as Unity will be firing off its own request for the policy behind the scenes, and won’t let the WWW class return until it’s satisfied.
Bear in mind that you did have another option rather than hacking your XML-RPC server - you could have used a third party HTTP library on top of .NET sockets. That way your initial attempt would have worked, where a server on one port provides a crossdomain policy enabling access to other ports.