|
We are using the Unity's Caching product to store the downloadable content on the local disk to minimize downloading times. This has been working fine on Unity2, but when we migrated to Unity3, the Caching.Authorize function started to return false (meaning we can't use the caching feature). Are signatures not compatible between Unity versions? Do we have to request another signature for our domain to solve this?
(comments are locked)
|
|
Thanks for your reply. We look into the UnityWebPlayer logs and then we found this error: You need to run this player from the http://bla.something.com:81 domain to be authorized to use the caching API. (currently running from http://bla.something.com ) Then we changed the domain from "http://bla.something.com:81/" to "bla.something.com". Now the Caching.Authorize function just returns false without logging any errors. It seems that there is a difference between how Unity2 and Unity3 detects the domain from where its running the player. We will need a new signature for the modified domain to fit this new behavior. I just checked the code. You are correct. We are now stripping port numbers of the url we verify, so people just need to authorize http://bla.something.com, and can then use any port on that. We had some complaints before that this didn't work. Now, it seems that in your case, this is failing, because your authorization is actually keyed to the domain name with port number. I cannot issue new authorization keys myself, so you will have to contact sales, to get a key without the port number (feel free to refer to my explanation). Sorry for the inconvenience.
Oct 21 '10 at 09:30 AM
jonas echterhoff ♦♦
(comments are locked)
|
|
It should not have changed. When Caching.Authorize fails, you should get an error message on your console. What does it say?
(comments are locked)
|
