[libgdx] Hosting js/html5 files: SecurityError due to different origins

I’m trying to incorporate libGDX javascript/html5 games into my little website. I have the default libgdx game (the BadLogicGames logo on a red background) exported as html5. I then upload those files to AWS S3.

The html5/js files work great if I access them directly on S3: http://s3.staticvoidgames.com/games/Firefly/libGdxHtml5/dist/index.html

However, what I want to do is embed those S3 files on another website, not hosted on S3. I took the javascript from the above index file and just add it to an html file on my actual website:

<div align="center" id="embed-html"></div>
<script type="text/javascript" src="http://s3.staticvoidgames.com/games/Firefly/libGdxHtml5/dist/html/html.nocache.js"></script>

However, when I visit that html page, the game doesn’t show up, and the JavaScript console shows this error:

Uncaught SecurityError: Blocked a frame with origin “http://s3.staticvoidgames.com” from accessing a frame with origin http://staticvoidgames.com". Protocols, domains, and ports must match.

Doing some research, I understand why that error happens: JavaScript can’t access stuff from my website, if it’s hosted on another website. Gotcha.

So now this becomes either a JavaScript question: how do I make this work? Surely somebody has hosted their libGDX files somewhere, and their website somewhere else?

Or it becomes a Spring question: how do I allow JavaScript from S3 access to my site? I’ve tried adding Access-Control-Allow-Origin to the header in my controller method:

	@Override
	@Transactional
	@RequestMapping(value = {"/{game}", "play/?game={game}"}, method = RequestMethod.GET)
	public String viewGame(HttpServletRequest request, HttpServletResponse response, ModelMap model, @PathVariable("game") String game, HttpSession session) {

	response.setHeader("Access-Control-Allow-Origin", "*");
        response.setHeader("Access-Control-Allow-Methods", "POST, GET, OPTIONS, DELETE");
        response.setHeader("Access-Control-Max-Age", "3600");
        response.setHeader("Access-Control-Allow-Headers", "x-requested-with");

//...

		return "games/viewGame";
	}

But that throws the same exact error.

Alternatively: is there a way to “trick” the browser into thinking that the JavaScript from S3 is really coming from my server? I’ve tried adding a Controller method that serves up the S3 files by redirecting URLS:

	@Override
	@RequestMapping(value = {"/{game}/{subdirectory}/**"}, method = RequestMethod.GET)
	public String viewGameHtmlFile(HttpServletRequest request, HttpServletResponse response, ModelMap model, @PathVariable("game") String game, @PathVariable("subdirectory") String subdirectory, HttpSession session) {
		String url = (String) request.getAttribute(HandlerMapping.PATH_WITHIN_HANDLER_MAPPING_ATTRIBUTE);
		url = url.replace("/games/"+game, "");
		String s3File = "http://s3.staticvoidgames.com/games/" + game + "/libGdxHtml5/dist" + url;
		return "redirect:" + s3File;
	}

But that throws the same error.

This is mostly me thinking out loud, but I’d love to hear anybody’s opinion on this, since I’d guess that somebody has done something similar with libGDX files before?

To see this error in action, this page (at the time of this writing) contains the link to the JavaScript hosted on S3: http://staticvoidgames.com/games/Firefly

Can yoiu map the s3 server to a subdomain of staticvoidgames?

Thanks for the reply!

The S3 server is a subdomain of StaticVoidGames.

Apparently the problem is caused by JavaScript not being able to access iFrames between origins, even on subdomains, and even if CORS is enabled? I don’t really know what I’m talking about.

What I eventually decided to do was just have a link on the game page (on StaticVoidGames) that goes directly to the index file on S3, instead of trying to embed the JavaScript on StaticVoidGames. Embedding the game on StaticVoidGames had issues with focus and whatnot, so this is probably the correct way to go anyway. Simpler for the user, simpler for the person uploading the game, and simpler for me.

Even subdomains are blocked? I didn’t know that.

But on the whole, I’m glad we have the Javascript security rules we do.