Ajax bug in r416

Post reply
0 favourites
  • 9 posts
From the Asset Store
Bug Match
$5 USD
Match same tiles with each other as fast as you can and earn more score during a limited time!
01smile's avatar
01smile

  • Ok, so I went to GitHub to post this bug and it's whole 2fa thing has gone over the top. You'll pardon me if I don't spend 2 hours of what little free time I have getting THAT to work.

    This worked fine in 407.2 earlier today on the desktop app. My desktop app upgraded to 416 and now this falls over to the Ajax any error with an error code of 0. Before my phone app upgraded, I loaded the last autosave and it worked fine. As soon as it upgraded to 416, Ajax error. I open the last autosave in the browser 407.2 and it works as intended.

    And it's not just this Ajax call. Any event sheet that I have with an Ajax call in the system on load fails with an error code of 0 if I try to run with it as the main event sheet.

    Did I miss something about Ajax in the patch notes??????

  • The only change was the addition of the 'On upload progress' trigger, which should not have affected any existing projects at all. I'm afraid it's impossible to say any more without the details provided by a bug report, as we need that information to be able to investigate.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • The only change was the addition of the 'On upload progress' trigger, which should not have affected any existing projects at all. I'm afraid it's impossible to say any more without the details provided by a bug report, as we need that information to be able to investigate.

    Again, having issues getting signed in to Github. Here's what I can tell you:

    Here are 2 c3p. Both are identical. One in 416, one is 407

    drive.google.com/file/d/1u9h63j1Pbh53iUt1n4Sn11flneqzOHpN/view

    drive.google.com/file/d/1dp-nLFxixwaLh-Rxne4u2vb_ajZVJGZu/view

    Both look like this:

    I added this line to my PHP class right at the top of the __construct function for my class that handles communication. This logs the output of the ajax post to the debug log.

    error_log(print_r($_POST,true));

    When I run this c3p in 407, I get this correct response in my debug log:

    [20-Nov-2024 23:41:00 UTC] Array ( [command] => connection_check [PV] => 1.0.0.0 [N] => Ajax 407 [SH] => Layout 1 )

    When I run the same code in 416, I get this in the debug log:

    [20-Nov-2024 23:40:59 UTC] Array ( )

    This indicates to me that for whatever reason, the 416 version is not passing the post data to my php file. In 416, this ends up generating a CORS error as there's no post data to process so it sends back nothing, which is expected. In 407, this runs fine with the c3p reporting success and no console errors.

  • It looks like the problem is that since the AJAX plugin added support for 'On upload progress', cross-domain requests have changed from simple requests to "preflighted" requests. These make an OPTIONS request before carrying out the real request. It looks like your server is configured to respond with Access-Control-Allow-Origin: * for GET requests but not OPTIONS requests, so it now fails with a CORS error as the preflight request is not allowed. So I don't think it's a bug, it's just that the way requests are made has changed, and you now need to update your server configuration. There's more information in the MDN guide on CORS and I added a note about this to the AJAX manual entry.

  • It looks like the problem is that since the AJAX plugin added support for 'On upload progress', cross-domain requests have changed from simple requests to "preflighted" requests. These make an OPTIONS request before carrying out the real request. It looks like your server is configured to respond with Access-Control-Allow-Origin: * for GET requests but not OPTIONS requests, so it now fails with a CORS error as the preflight request is not allowed. So I don't think it's a bug, it's just that the way requests are made has changed, and you now need to update your server configuration. There's more information in the MDN guide on CORS and I added a note about this to the AJAX manual entry.

    You are correct. It is the CORS preflight.

    But, that brings up the request I made to lock a version into the apps. I'm using wordpress as a server. Now my c3 game is gonna bang on the server twice for what amounts to 1 request. Thus, wordpress is going to load twice per request. I don't need a preflight check. If I could lock 407 into my apps setting it would prevent this double-tap.

    That or can you add a setting to Ajax to prevent preflight?

    Thx

  • Preflight requests are a normal part of CORS and can happen in a variety of other circumstances. I think it's best just to accept it and update the server configuration accordingly, and then it shouldn't be an issue again. We could add some kind of setting for this, but as I mentioned preflight requests can happen in other situations so I think it's best just to get the server configuration to cover preflight and then all cases are covered.

  • And for those wondering how this preflight check works, here's the PHP code I used. If this is called pretty early in your code, it'll keep the overhead lower. In wordpress I hooked it into the init. 

     public function pre_flight() {
 	// Allow requests from any origin
	 header("Access-Control-Allow-Origin: *");
 	// Handle preflight (OPTIONS) request
 	if ($_SERVER['REQUEST_METHOD'] === 'OPTIONS') {
 		// Specify the allowed headers
 		header("Access-Control-Allow-Methods: POST, GET, OPTIONS");
 		header("Access-Control-Allow-Headers: Content-Type, Authorization");
 		// Set the content type for all responses
 		header("Content-Type: text/plain");
 		// Send a 200 response for preflight checks
 		http_response_code(200);
 		exit;
 	}
 }

  • Hi Fengist,

    So r416 has broken my PHP for updating a CSV file through C3/AJAX/PHP on my server.

    Did the pre_flight() function you posted here solve your issue? Did you have to do anything to your server to get it to work?

    I would really appreciate any guidance here. I'm a bit lost when it comes to changing server settings, etc.

    I've had to revert back to r407.2 until I can get this sorted :(

    And for those wondering how this preflight check works, here's the PHP code I used. If this is called pretty early in your code, it'll keep the overhead lower. In wordpress I hooked it into the init. 

    > public function pre_flight() {
	// Allow requests from any origin
	 header("Access-Control-Allow-Origin: *");
	// Handle preflight (OPTIONS) request
	if ($_SERVER['REQUEST_METHOD'] === 'OPTIONS') {
		// Specify the allowed headers
		header("Access-Control-Allow-Methods: POST, GET, OPTIONS");
		header("Access-Control-Allow-Headers: Content-Type, Authorization");
		// Set the content type for all responses
		header("Content-Type: text/plain");
		// Send a 200 response for preflight checks
		http_response_code(200);
		exit;
	}
}
Post reply
  • 9 posts
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)