- Home /
Why is Unity trying to get a crossdomain policy, even when trying to access a server on the same domain?
( I've previously posted this in the forums, before I new about unityAnswers. Sorry for reposting, but since it didn't attract any views there, I thought maybe I'd try my luck here:) )
The situation is this:
A Unity project is built targeting the WebPlayer platform. The resulting .html and .unity3d files are put in Apache's htdocs, and served by the localhost. The project, when launched by loading the page http://localhost/WebPlayer.html, tries to connect to a server application, which is also running on localhost.
Since both the Unity client and the server reside on the same domain, I expected there would be no need for a crossdomain.xml, but I still get the "Unable to connect, as no valid crossdomain policy was found". (Of course, if I launch the Unity's pre-packaged policy server, there is no problem).
Running from within the Unity Editor, with "WWW Security Emulation Settings" set to http://127.0.0.1/WebPlayer.unity3d has the same result.
The question is, should this be happening? (I think it shouldn't.) Why is Unity trying to get a crossdomain policy in this case? Am I missing something? Any info would be appreciated.
Answer by Dreamora · Jun 24, 2011 at 11:12 PM
The problem is a two fold one:
There is WWW - For WWW, there is the case where you don't need a crossdomain.xml, thats when you access things by relative filepaths. But if you use explicit domains / IPs for it, the target webhost has to have the Crossdomain.xml at its top level in accessable form.
There are Sockets - Sockets in Unity follow the regular web security Policy for sockets (same as Flash and Silverlight - as the rules on WWW too by the way). For sockets you have the option to use the PrefetchSecurity function (should work, never used it as I have the policy server) or if you really use the socket for gaming and alike, you want to use the Policy Server or create your own inbuilt in your game server (SFS and Photon have it inbuilt). Interesting and important here is to know that unity uses the same port etc as Silverlight.
What the documentation part on sockets you quoted there wanted to tell you is that if your connection goes to a specific host (anything but relative filepaths, so always for sockets), the policy security has to be complied to basically
I just noticed that I failed to say in the 1st post that I was using normal sockets (and a server app unrelated to Unity), not Unity's WWW... Sorry about that, I can see now how that would have caused misunderstandings.
Anyway, thanks for confir$$anonymous$$g my guess.
About the statement that Unity uses the same security policy for sockets as Flash (I don't know anything about Silverlight)... I've seen it in the documentation, but (and I hesitate to say this, since I only have a limited knowledge of ActionScript & the Flash environment), it's not what I experience:
At this time, I have 2 clients, one written in ActionScript and running within the Flash plugin & one written in C# and running withing the Unity WebPlayer plugin. Both are connecting to the same server (written in C++) (NOTE: I'm always talking about the case where both client & server are running on the same machine). From Flash, the connection is established no questions asked. From Unity, the crossdomain security policy is required. There might be something I set in the Flash Player Settings, but I don't think I set anything related to such security policies (I actually met them for the 1st time with Unity's plugin - after the Flash client was written & tested). Anyway...
Again, thanks for your time.
Answer by Dreamora · Jun 24, 2011 at 01:30 AM
Whats your code looking at? Or asked differently: Are you sure that the access you do is done with relative filepaths, not with absolute ones that use localhost or Application.xxxxurl and alike?
Crossdomain requirement is only waived for relative filepaths, for anything that uses absolute it enforces them to be present.
Trying to use sockets will always require crossdomain from what I recall (more correctly there is better a policy server running otherwise the performance suffers), no way to get around and no matter where you connect to. The reason here is security, otherwise you could missuse a java or flash plug running side by side to it to overcome security limitations that way allowing 3rd party to inject a virus or trojan that way by replacing yours and redirecting it to their place
Hello Dreamora, thanks for your time!
Still, I don't think that answers it. And I'm a bit confused, why the comment about filepaths? Since we're talking about socket connections -(protocol, serverIP, serverPort, clientIP, clientPort) tuples-,there are no filepaths to speak of. So I don't quite see how filepaths enter the equation, please clarify if possible.
I know about the security issues, the question is why the need of a crossdomain policy server when trying to connect to the same domain. The qualifier "*cross*domain" in itself indicates that the security policy should only come into play for connections to different domains.
Anyway, I've been reading http://unity3d.com/support/documentation/$$anonymous$$anual/Security%20Sandbox.html again and again, and on close scrutiny of the wording, one may come to the conclusion that this part from the introduction paragraph:
Restrictions on accessing data on a domain other than the one hosting your .unity3d file.
actually applies only to the WWW class (and not to .NET Sockets), based on this excerpt from the "Implications for usage of the WWW class" section:
The Unity webplayer expects a http served policy file named "crossdomain.xml" to be available on the domain you want to access with the WWW class, (although this is not needed if it is the same domain that is hosting the unity3d file).
and the lack of similar wording in the "Implications for usage of Sockets" section. Ins$$anonymous$$d, in that section it is only stated that
A Unity webplayer needs a socket served policy in order to connect to a particular host.
So, one might come to the (not so logical or evident) conclusion that .NET Sockets will always require a crossdomain policy, even when not doing a crossdomain connection (in contrast to Unity's WWW class).
I'm beginning to think this is the case, but some confirmation would be greatly appreciated.
should such a simple thing need to be pieced out like a jj abrams viral campaign?
I can't for the life of me get this working. it's been days and days of reading every post i could find. all the same. no good examples.