Ajax from C3

  • Ok, a long time ago I had this problem solved with C2. Now, I'm scratching my head again.

    Doing just a simple Ajax request to a php script.

    <?php header("Access-Control-Allow-Origin: *"); $myfile = fopen("newfile.txt", "w") or die("Unable to open file!"); $txt = $_POST; fwrite($myfile, "Post: ".$txt); fclose($myfile); echo "Success"; ?>

    If I export the C3 project to html5 and upload it to the server where this script is, it works as intended. If I try to run it via the C3 preview it gives an Ajax error in C3 with no Ajax.LastData.

    Obviously, this has something to do with cross site but I was under the assumption that the php header would fix that.

    Any ideas? I really don't want to constantly export and upload a project to live test it.

    Tagged:

  • I use a .htaccess file for this.

    Header always add Access-Control-Allow-Methods: "GET,POST,OPTIONS,DELETE,PUT" Header always add Access-Control-Allow-Origin "*"

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I use a .htaccess file for this.

    Header always add Access-Control-Allow-Methods: "GET,POST,OPTIONS,DELETE,PUT" Header always add Access-Control-Allow-Origin "*"

    Thanks, I'll give this a try.

  • Ok, tried the .htaccess and that didn't work. Tried adding both lines to the php, that didn't work either.

    Is there something about C3 on construct.net that prevents ajax from working?

  • Is there something about C3 on construct.net that prevents ajax from working?

    Defenitely not, as it works for me. But it´s hard to tell what´s wrong here. The file could be cached for example, try opening it in your regular browser and hit Ctrl+F5 to force it to reload and try again. But it should defenitely work since I don´t have that problem.

  • > Is there something about C3 on construct.net that prevents ajax from working?

    Defenitely not, as it works for me. But it´s hard to tell what´s wrong here. The file could be cached for example, try opening it in your regular browser and hit Ctrl+F5 to force it to reload and try again. But it should defenitely work since I don´t have that problem.

    Nope, didn't work. I'll check with the isp tomorrow.

  • Is your sever Https ? (Secure server)

  • The first place to look is the browser console for any error messages.

  • Is your sever Https ? (Secure server)

    This could absolutely be it. And yeah, you should check the browser console.

    Also there are chrome settings/plugins that disable cors, might be relevant in case you don't wanna buy ssl. Use only for testing your game though, cors is there for a reason!

  • Ok, so I did some digging in the Apache logs and discovered that any time I made an ajax request from the C3 IDE, it wasn't even hitting the server. Run locally on the server, the GET requests were logged with no errors.

    Since you guys say it works, I got to looking at the browser as a problem. Sure enough, one tiny little icon in the top right corner of Chrome notified me that this was an 'unsafe script'

    I clicked on that, and the project did a proper ajax request and I got the proper response back

    Since this script blocking didn't occur when run from html5 uploaded to the server and only occurred when running from the C3 IDE, I'm going to assume that my visitors aren't going to have this same issue with script blocking. Otherwise, them trying to spot that little warning icon is going to cause them to quickly give up.

    Thanks for the suggestion guys, you put me on the right path.

  • Is your sever Https ? (Secure server)

    It is not. And apparently that's exactly why the 'unsafe scripts' icon on chrome popped up. Well, at least until I get a cert I can at least bypass this blocking.

  • You should always check the browser console first. In this case it logs a warning telling you that requests from a HTTPS to HTTP page are blocked for security reasons (mixed content warning). That would have saved you all the trouble sifting through logs and all.

    You should absolutely run your server on HTTPS. Many web platform features no longer work on HTTP, so you may also find some features stop working when you publish your project to an insecure server.

  • You should always check the browser console first. In this case it logs a warning telling you that requests from a HTTPS to HTTP page are blocked for security reasons (mixed content warning). That would have saved you all the trouble sifting through logs and all.

    You should absolutely run your server on HTTPS. Many web platform features no longer work on HTTP, so you may also find some features stop working when you publish your project to an insecure server.

    Yep, just realized that was the problem the whole time. Guess it's time to visit Let's Encrypt huh?

    Thanks.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)