Libgdx HTTPRequest

Newbie & Debugging Questions
#1

Hi,

I made a little math game and want to save and load the highscore with php and mysql.
Everything works fine in the desktop and the android version. But in the html version of the game I can save the score but the highscore dont want to load ingame.

The code I use


			HttpRequestBuilder requestBuilder = new HttpRequestBuilder();
			HttpRequest httpRequest = requestBuilder.newRequest().method(HttpMethods.GET).url(EqualConstants.USERLEVELS_GETPHP).build();

			Gdx.net.sendHttpRequest(httpRequest, new HttpResponseListener() {
				@Override
				public void handleHttpResponse(HttpResponse httpResponse) {
					String resultAsString = httpResponse.getResultAsString();
					String[] split = resultAsString.split("\n", -1);
					if ((split != null) && (split.length > 0)) {
						maxScore = Integer.valueOf(split[0]);
					}
				}

				@Override
				public void failed(Throwable t) {
					Gdx.app.log("Failed ", t.getMessage());
				}

				@Override
				public void cancelled() {
					Gdx.app.log("Cancelled", "Load cancelled");
				}
			});
			
			return true;

Can someone tell what is wrong? Thanks =)

#2

Ok, found the problem -> no access control allow origin header

Solved it with the new header information in the php file. But the correct solution seems to be using cors. I will add it now.

#3

Seems to work for me?

#4

Ah, yes, your web server needs to set the “Access-Control-Allow-Origin” header on the http response, otherwise the Browser will not allow the client side code to receive the message.

Browsers comply with this since it prevents blatant content leeching (doesn’t prevent anyone from accessing it directly though)

#5

CORS is actually a security measure, not a way to block content leeching.

#6

It’s not, though. I mean technically it’s an accepted vulnerability to break out of the Same-origin policy (which is different).

It’s practically a gentlemen’s agreement between the web server and the browser.

It doesn’t actually secure the web server in the slightest, nor the browser for that matter, and not really the user either - the only scenario I can think of is a compromised domain hosting the app accessing the same API - in which case the user has already been bamboozled (in fact it would make more sense for the comprised domain to NOT use the same API but simply grab the user details by proxy in that case so as to keep the original host unawares).

So in practice CORS really only prevents content leeching (through browser land). But certainly doesn’t actually secure anything. In fact browsers put heavy restrictions on CORS requests.

#7

Note sure what you mean, as CORS is not used for requests, and is used for ajax-calls with specific http-methods and non-trivial http-headers. So it does not stop content leeching of images and I’m not sure how many people leech content through the ajax API… :slight_smile:

In earlier versions of Chrome, you could disable CORS with the CLI param: [icode]@@–disable-web-security[/icode]

Anyhoo, this is a tad offtopic. If you wish to elaborate I could split it off this topic.

#8

Lots of sites load content dynamically directly through API’s these days. Usually text based like articles, blogs, comments, posts and image/video URLs (that are later :ed to the page) (Although avatars and small images are sometimes base64 encoded directly as a string). Using ajax-calls like you said (XMLHttpRequest).

However, since the API is public (you don’t have to register or be logged in to see comments) practically anyone could make use of your content (and they can).

Using Access-Control-Allow-Origin, however, you can restrict access to the API (and its content) from a specific domain. This way someone else can’t simply make another site using content from your API (since 99.9% of users use modern Browsers like Edge, Chrome or Safari that respect CORS).

Nothing of course prevents them from creating some kind of proxy (an HTTP request not issued through the Browser) to your API (but those are much more easier to detect and block), or simply copy/pasting your content (but still takes much more effort than simply using your API directly).

And if someone is somehow abusing your content anyway regardless of CORS, since your API is flexible, you can push a button to serve GOATSE or jargon from your old endpoints while keeping your own domain unaffected.