Yet another case of Unity Web Player Crossdomain.xml troubles

[system]

Hi All,

My team is developing a web application that delivers Unity Web Player content to registered users.

The web application is a Ruby on Rails app hosted on Heroku. Since the Unity content is effectively behind a pay wall, we are serving it from an Amazon S3 bucket using a private CloudFront distribution.

I have the recommended UTF-8 encoded crossdomain.xml file served up at xxx.herokuapp.com/crossdomain.xml:

<?xml version="1.0" ?>
<cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy>

Yet, everytime the Web Player tries to upload data to my app (using the WWW object), I get an error “Rejected because no crossdomain.xml policy file was found”.

This is driving me insane because:

1. I can confirm that the app is serving up crossdomain.xml (ie using curl)
2. I see in the web app logs that the crossdomain.xml file is being served to the Unity player!

I am at a total loss here. Am I missing something? Are there any other debugging tools I can use to see what’s happening under the hood? How can I know what the result of Unity’s parsing of the crossdomain.xml file is?

Please help!

[system]

Well…

If you have your content located at some-bucket-name.s3.amazonaws.com, that is where Unity is going to be looking for crossdomain.xml. The point of crossdomain.xml is to make sure that the third party domain (the bucket domain in this case) is okay with other applications touching its files. So stick a public crossdomain.xml file in your bucket and you should be good to go (you need to be accessing your bucket using the virtual domain not the s3.amazonaws.com/some-bucket-name method).

Remember, you can’t tell Unity to look for the file in a special way (like through S3’s authentication methods), so make sure that the crossdomain.xml is publicly readable (there should be no security issues with this as the file reveals practically nothing.

P.S. It might be a good idea to stick encoding="UTF-8" in your XML file header just to be safe that the file is interpreted as UTF-8.

If you are confused as to why the crossdomain.xml file needs to be where it needs to be, consider this: Bob is a user with malicious intent. He knows that Alice has special access (from her computer) to access certain files that Bob wants to get to (files located in an internal website hidden.alicesite.com. Bob creates a game that he invites Alice to play. The game is hosted at bobsgame.example.com. Bob uses Unity to make a request to hidden.alicesite.com to get various files. If Bob was able to put a crossdomain.xml file in webspace that he controlled, the crossdomain.xml file would have no purpose, as he could easily put it on his server. The crossdomain.xml file is not designed to protect you, but to protect the user.

[system]

I am hosting the unity3d file using Amazon’s Cloudfront. I was accessing the webplayer file using https, and trying to POST data to my web app over http. Either the WWW class just doesn’t support https or it doesn’t like the mismatch between secure/unsecure connections.

My solution is for now to just access the unity3d file from Cloudfront’s http URL

[andresp]

Make sure you are saving the file in UTF8 without BOM (Byte Order Mark).

[Andras]

Thank you for your answer, indeed if Unity is served from S3 via https then for some reason it can’t connect to http://mydomain.com even if I have http://mydomain.com/crossdomain.xml.

As soon as I switch the Unity http (instead of https) it works.

[Dimetrock]

I had the same issue. The fix is rather simple.

Each tag has the optional secure attribute. The secure attribute defaults to true. You can set the attribute to false if your policy file is on an HTTPS server, and you want to allow accessing files via HTTP or HTTPS. Setting the secure attribute to false could compromise the security offered by HTTPS.

Example: allow-access-from domain=“*” secure=“false”/