As above: Received ‘Crossdomain.xml is not found’ error when using HTTPS.
The file is available [confirmed in browser] and is identical to the one unity loves when presented with HTTP.
Try setting the secure attribute to “false.”
My apologies, but what secure attribute?
Andorov, I’m having the same problem, could you please elaborate???
It’s an optional attribute of the allow-access-from tag. In Flash, at least, it’s used to let insecure clients read secure resources, i.e. it only applies if the client is HTTP but the resource being fetched cross-domain is HTTPS. However, who knows how Unity chose to interpret these things.
Also bear in mind that the crossdomain.xml file needs to be accessible via the same protocol as the resource being fetched - so if the resource is HTTPS on some funny port, then crossdomain.xml needs to be visible by HTTPS too, in the root.
Geaorge, I tried setting the allow-access-from-secure to false but it still didn’t work 
From the looks of it they didn’t:
NullReferenceException: Object reference not set to an instance of an object
MonoForks.System.Windows.Browser.Net.FlashCrossDomainPolicy+AllowAccessFrom.CheckDomain (MonoForks.System.Uri uri)
MonoForks.System.Windows.Browser.Net.FlashCrossDomainPolicy+AllowAccessFrom.IsAllowed (MonoForks.System.Uri uri, System.String[] headerKeys)
MonoForks.System.Windows.Browser.Net.FlashCrossDomainPolicy.IsAllowed (MonoForks.System.Uri uri, System.String[] headerKeys)
MonoForks.System.Windows.Browser.Net.BaseDomainPolicy.IsAllowed (MonoForks.System.Net.WebRequest request)
UnityEngine.UnityCrossDomainHelper.GetSecurityPolicy (System.String requesturi_string, IPolicyProvider policyProvider)
UnityEngine.UnityCrossDomainHelper.GetSecurityPolicy (System.String requesturi_string, IPolicyProvider policyProvider)
UnityEngine.UnityCrossDomainHelper.GetSecurityPolicy (System.String requesturi_string)
This is the xml:
<cross-domain-policy>
<allow-access-from domain="*"/>
<allow-access-from secure="false"/>
</cross-domain-policy>
The HTTPS is literally the same site as HTTP in my case. And for further confusion, that above error occurs on both HTTPS and HTTP.
NPSF3000, the secure attribute should be in the first tag along with the domain attribute. Probably still won’t work though!
Ahh… all I get now is inability to find valid crossdomain.xml:
SecurityException: No valid crossdomain policy available to allow access
UnityEngine.WWW.get_text () (at C:/BuildAgent/work/b0bcff80449a48aa/Runtime/ExportGenerated/Editor/Utils.cs:87)
wwwTest+<Start>c__Iterator1.MoveNext () (at Assets/wwwTest.cs:19)
Even though it’s there and working fine. Tried setting secure to both true and false.
I ran some tests and it mostly makes sense to me - I can have the webplayer accessed securely or insecurely, and the content accessed securely or insecurely, and all four combinations work fine, though some require crossdomain.xml and some require ‘secure=“false”’ too. However a limiting factor in my tests is that I only have one secure server to test with, so if you’re hosting content on one HTTPS server and your webplayer on another HTTPS server, that’s not a case I can try out myself.
So given a webplayer app that accesses some content via HTTPS, it works fine with no crossdomain.xml file if the webplayer is hosted on the same server using HTTPS. It also works fine if the webplayer is accessed through plain HTTP, but requires a basic crossdomain.xml file (with no ‘secure’ attribute).
Rebuilding the webplayer to access the content by plain HTTP, it works fine with no crossdomain.xml file if the webplayer is also accessed via plain HTTP. But if the webplayer is accessed via HTTPS, it requires a crossdomain.xml file with the ‘secure=“false”’ attribute on the ‘allow-access-from’ element.
I should add that I got inconsistent results from simply editing the “WWW Security Emulation” host URL in the editor - it doesn’t seem to work properly.
Adding ‘secure=“false”’ doesn’t seem to prevent plain HTTP sources from accessing the data either, so I guess you can put it there all the time.
After all that, though, I get very inconsistent results when I try uploading the webplayer to another server. Unity won’t load the content unless the server hosting the content has a crossdomain.xml file with domain matching that server’s own hostname. I thought the whole point was that the crossdomain.xml file had to have an entry matching the original domain.
i.e. I uploaded a webplayer to my webspace at .virginmedia.com which loads a file from .lan. In order to allow this, I need a crossdomain.xml on my lan server which lists domain=".lan". Now I thought that was meant to say ".virginmedia.com" - the place where the webplayer is hosted. Hmm.
1 Like
Ah, it turns out my virginmedia webspace also supports HTTPS, so I have been able to test that too. As before, when the webplayer is accessed via HTTPS and the content is accessed via HTTP, it requires ‘secure=“false”’ in the allow-access-from tag. And I am even more sure now that the ‘domain’ in allow-access-from is being interpreted as the domain where the content is, not the domain where the webplayer is.
On the face of it, putting this on your content server’s root should allow access from absolutely anywhere, regardless of whether either the webplayer or content are accessed through HTTPS or not:
<cross-domain-policy>
<allow-access-from domain="*" secure="false" />
</cross-domain-policy>
It seems to work for me, anyway.
Oh, this might be obvious, but Unity will generally not like it if your SSL certificate hostname doesn’t match the hostname used to access the resource. It doesn’t seem to mind self-signing though.
1 Like
Oh crap okay so I tried setting it to false earlier it didn’t work, but for some reason it works now!!
Thanks a lot George!!
Indeed, was having this problem as well because of Facebook’s “secure canvas” redirection - thanks for posting your insights!