lennaert's Forum Posts

  • You do not have permission to view this post

  • You do not have permission to view this post

  • I use teleporters with 2 values, teleport.location and teleport.target

    I give the instance variables via a family with the teleport inside.

    family: TeleporterS

    object: teleporter

    location is where the teleporter is located, target is where it's going

    if you have 2 teleport objects, give them these values:

    1.

    teleporter.location = "entry"

    teleporter.target = "nextplace"

    2.

    teleporter.location = "nextplace"

    teleporter.target = "entry"

    The following events should work for the teleports, even if you add lots more, as long as they have their own location and got another teleporter targeting it.

    conditions

    player on collision with teleporter

    pick TeleporterS where location = teleporter.target

    action

    player set position to TeleporterS

    Something along those lines

  • In order to hide transaction calls from the player, you would need to encrypt the payload on client side and decrypt it on the server. Obfuscating variable names seems to be a poor measure, since ?asda34859=4000000 can be crosschecked with the score the player has made in that session and figure out that asda34859 is the score variable - not to mention development hell to map the obfuscated variables with the real database names.

    For starters, you could encode your payload in base64 and split the string in 2-3 variables.

    Yup, thats some measure you can apply to make it harder to tamper.

    There are a lot more options to make it harder, like some mentioned earlier.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Your missing the point:

    at no point prior is data sent visible

    Because this is not true for the browser having the app or game running.

    If I simply copy the link from the inspector, and paste it in my adress bar (with or without altered values) my transmission goes through ... and IF that link is using https ... it will also go over https

    https is security between user <--> host

    But in this scenario, the user is a potential culprit .. (for example, wanting to cheat with the biggest highscore)

  • even if u send a password as plain text if it'S through https it's encrypted so other people can'T steal it

    But that does not solve the problem mentioned here, that a user is able to see what is posted/send by means of the dev tool inspector ...

    Like, say a link sends ?player=1&score=10 ... and the user copies and tweaks it to send ?player=1&score=1000000000 ...

    No matter how much its encrypted by https ..... this user suddenly has a score of 1000000000 in the database.

    Going further, depending how data is processed server side, one could add bits of sql statements within the score, and if the data isn't properly filtered or checked, lends itself for unwanted sql injection.

  • it's fine if u use https

    How come ?

    Whether https or http is used, the user instantiating the app could still be able to see the involved URL and the post parameters ...

  • Yup, that happens.

    A thing to consider is that the dev tool is used by the browser, does not exist in an app form.

    Several things to consider regarding the POST action:

    You can and should obfuscate the variable names in the links (POSTs), or at least use things not overly obvious (userid, password, etc).

    And perhaps add some extra values, also obfuscated to act as decoys/fakes.

    You can encrypt and or encode the variable post values within your code which the server knows how its encrypted and decrypts it on received.

    You can add double checks like a MD5 hash between 2 posted values, or even from 2 combined values (1 from a previous post) and check the hash server side again.

    You can add several methods of increasing values that do not correspond with numbers.

    A returned value double check, where the received value is send back to the app and double checked.

    A check server side that tracks 'irregular' values versus expected values. (i.e. normally only 5 points gets added, suddenly >100 gets added)

    And a lot more options to make it harder to manipulate what is send and what is accepted upon reception.

    It will never be 100% safe, but in reality, that goes for most information online, it's generally a matter of how much effort was poured into protection, and how much time and energy an abuser is willing to spent to make hos hack happen ....

  • (it's weird but i've never had access to the "Edit Post" feature for Forum posts, no matter what device (PC/Mac/Phone) and what browser (Chrome/Edge/Firefox) I use, no matter if I'm in incognito mode, if I disable all chrome extensions or not. So pardon me if there are a lot of typos as I can't edit and preview my forum posts)

    I think that's due to you needing to post more, it's a restriction for "new" users lol

    Just 9 posts, perhaps 1 more :P

  • I am not seeing many of these topics, so I'll just throw one in here, to hopefully get some more eyes on the whole suggestions platform and get more people to vote.

    The following are mostly from a personal stance:

    I made 2 smaller suggestions on: construct3-21h2.ideas.aha.io

    1.

    Resize all animations, for the purpose of easily updating the size of all the animations in a sprite, in stead of just 1 of the animations:

    construct3-21h2.ideas.aha.io/ideas/C321H2-I-346

    2.

    Export to FTP / FTPS for the purpose of quicker and easier testing for those with their own upload location because large size games can take a lot of time to upload through the remote previewer, plus some other advantages:

    construct3-21h2.ideas.aha.io/ideas/C321H2-I-345

    And this is one of personal interest, isometric tiles, posted by a guest:

    Isometric is a standard amongst 2d games, and having a decent isometric system and logic would be really nice, kinda weird it is not been build before really. And yes, we can fake isometric .... but it is definitely not the same.

    construct3-21h2.ideas.aha.io/ideas/C321H2-I-78

  • I also have unbound scrolling turned off.

    I thought this had to be turned on for scrolling near the sides of layouts.

    From the manual:

    To scroll, the size of the layout must be bigger than the project's viewport size, or the layout's Unbounded scrolling property must be enabled. Otherwise there is nowhere to scroll to and scrolling will have no effect.

  • Hmm, would storing the session ID locally really be that bad security wise? This will all be in app so URLs wont be visible to the user.

    Security is a fickle thing, over time I have come to look at it with : "What's there to steal, or take"

    If you have a simple game with no payment or purchase options, then, what's the worst they could do with the information ?

    Personally, if I were to retrieve information from a database, I wouldn't even use the session ID, and simply create a log in system over PHP and Ajax. This also isn't as secure as I'd like, but it's more standard, and gives me more options to somewhat secure my information.

  • From a construct perspective, no.

    There are options to get it working, but you'll have to resort to storing an existing session in a database on the php side, and in the CS3 app, and later use the stored ID from CS3 to contact the database, and see if it exists, and has extra session variables stored.

    Not the most ideal solution.

    I have similar problems testing a multiplayer setup :\ need to export and upload to have any sense of rapid testing effect.

    Ashley can we get an option to export HTML version to a FTP location ?

  • Just slap an ID on the inputtext, and add a css file ....

    You can style it with all the css possibilities that are out there, from animating to to fade effects, gradient coloring etc etc etc

  • Your welcome, sorry for the hassle, its rather early here ^_^