HTML5 liveupdate CORS error (Access-Control-Allow-Origin) (SOLVED)

Questions
#1

I’m trying to test an HTML5 build that uses liveupdate. I get the following error in console:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://www.mydomain.com/liveupdate_folder/defold.resourcepack.zip. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). Status code: 200.

Firefox documentation is here but it’s not enough to get me over the line… Reason: CORS header 'Access-Control-Allow-Origin' missing - HTTP | MDN

I believe my server is Apache and I’ve tried adding an .htaccess file but I am unable to resolve the error. I’ve tried various permutations of .htaccess but they just yield another error:
(Reason: CORS header 'Access-Control-Allow-Origin' does not match

What should I put in .htaccess, and where do I put .htaccess? Thanks!

#2

If your game is on domain A and your liveupdate data are hosted on domain B, then something like this in the .htaccess of domain B should work:

Header add Access-Control-Allow-Origin "https://A"
Header add Access-Control-Allow-Methods "GET"
Header add Access-Control-Allow-Headers "Content-Type, Authorization"

If it still doesn’t work then you might wanna check if Apache is using the .htaccess file, and if updating the headers is allowed (e.g sudo a2enmod headers). It’s possible that the administrators have blocked this at some web hosting providers.

2 Likes
#3

Thank you. Both are hosted on the same domain, so I thought it was strange that this type of error occurred. I’ll reach out to the hosting company to see what they think.

#4

Then you shouldn’t be getting any CORS messages :smiley:

If you open the developer console using F12 on the browser and go to the Network tab, can you spot the request that tries to load your liveupdate data? Could it be that the domain used there is somehow different? For example if one starts with www and the other doesn’t.

2 Likes
#5

Thank you! This seems to have solved the issue. It’s awfully precise - I had to ensure both www and https:// were added! I suppose it’s security stuff that I am not familiar with.

1 Like
#6

www.something.com is a completely different domain from something.com after all :wink:

2 Likes
#7

@Haath One more thing if you don’t mind! I’m realising that the “fix” here was that I ensure the URL I’m accessing the game on matches the liveupdate link I’m using. This fix is harder in the wild because I can’t force users to browse a specific way. I am aware there are kinds of redirects and such where you can force www prefixes for example. But what would you do in the situation where you are hosting a game on a domain that you don’t control?

#8

Some ways that come to mind:

  • Force a redirect. Can be done even with .htaccess or Javascript if you don’t control the domain. Might be a bad idea though if the website isn’t yours either.
  • Find out which domain the user is on from window.location.hostname and adjust your liveupdate url.
    • I think this may have some issues inside an iframe. But in that case I guess you can control the domain? We had some relevant discussion here.
  • Make sure both ways of accessing the game are allowed through the Access-Control-Allow-Origin header. Some more info on that:
    • Multiple values are not allowed on this header. You can set either one value, or a wildcard *.
    • Using the wildcard is somewhat insecure, and only works with GET requests if I recall correctly. Should be fine for you if you’re just exposing a zip file.
    • You can also put the .htaccess inside the liveupdate folder, so that any CORS headers you apply to that don’t spill out on the rest of the website.
    • The recommended way to allow a list of specific domains is to read the ORIGIN header, and if it exists in your list of domains, set it on the header. An example for apache is here. Or if you don’t control the apache server maybe this example which shows how to do it with .htaccess.

The last one is probably the least intrusive.

4 Likes