So as of right now, our attempt to make an HTML5 League of Legends simulator has completely failed as we could not even load the champion data which was step 1. So why did this work when the target was Windows but not on HTML5? The answer being of course that the browser saw the http_get to /lol/static-data/v3/champions as a cross domain call and properly blocked it. That is exactly what we expected and wanted, but the goal was not to make a Windows game so let’s change the target to HTML5 and run it again: Now if you run the above with a target of Windows, you will get the following popup with a lot of JSON, full of LoL Champion Data: Show_message("HTTP_GET message attempt failed.") //Debugging message popup "result" of the http_get we performed as a popup window so we can easily view it Show_message(ds_map_find_value(async_load, "result")) //Here we just dump the It means the http event was successful, if it is -1 then it was not successful If (ds_map_find_value(async_load, "status") = 0) //If the async status is 0, Then create an Async_Http event to handle the callback from the http_get: if (ds_map_find_value(async_load, "id") = getChampionJson) //This checks if theĪsync message we got back matches the getChampionJson ID from the message we sent earlier GetChampionJson = http_get("") //This method returns a unique ID and assigns it to the variable "getChampionJson", we will then look for this ID later on when checking the Async callbacks for a response to this exact message ![]() Step 1: Get a list of Champions from the LoL API in a GML Event: If we use a very simple example of building a League of Legends fight simulator game that loads different champions and simulates battles against them we can easily see the problems. ![]() What this means for games, however, is that we cannot load external data from different domains into our game since the browser will see that as no different than a regular cross-site script and block the connection. In order to prevent these types of attacks, modern browsers will employ what is called: “Same-Origin policy” that will only allow scripts to access data from the same “origin” or domain. Much like the old sql injection methods used for dumping database tables, cross-site scripting allows for embedding malicious scripts ( tags) inside user input fields like custom search queries or comments which would then be run by an unsuspecting user’s browser when they loaded the infected page that would then make connections to the attackers server to, for example, store the unsuspecting user’s form data. Please see the section on Cross Domain Issues for further details.”īut what exactly is Cross-Site Scripting and why would anyone be trying to use it in a game? Further, are there any ways to get around browser restrictions to make this work in case we really need this functionality? We’ll step through these issues piece by piece and hopefully make sense of everything by the end.Ī cross-site script refers to any script running on a user’s browser that attempts to load or pull data from a different domain than the one the user originally loaded. “ NOTE: You should be aware that due to XSS protection in browsers, requests to and attempts to load resources from across domains are blocked and may appear to return blank results. If you have ever looked up any of the http_* methods in the Gamemaker: Studio documentation you have surely seen the following warning about cross domain issues: GameMakerBlog Tutorials HTML5 Games and Cross-Site Scripting
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |