GameJolt Integration (co-authored by GamerPablito)

[SplatterDash]

With thanks to both GamerPablito and LJ

This PR adds optional integrations with GameJolt for achievements, leaderboards and data storage in softcoded mods. The PR includes:

• Flags to be set in .ini: MOD_GAMEJOLT_GAME_ID and MOD_GAMEJOLT_TOKEN, as well as a Project.xml define to toggle GameJolt API on/off.
• Utility GJUtil.hx, to handle front-facing calls to GameJolt including logging in/out and pinging the session.
• Backend utility GameJoltSecurity.hx, to handle sending/receiving calls and token decryption. This is intentionally blocked from access in HScript and hardcode, with GameJoltSecurityPublic.hx providing a forward-facing version of the script for hardcoders.
• Implementation of HaxeFoundation's Crypto library, for encryption methods (regarding the game token). It's not a cryptocurrency module.
• Automatic handling of GameJolt sessions when switching mods and closing the program.

PR is self-marked as WIP because ideally I'd want to have full "cheese control" and be able to prevent players from injecting calls to cheese leaderboards or achievements. Down for feedback/ideas with that.

IF PR IS APPROVED: I am happy to privately send the version of GameJoltSecurity.hx that has been privated by .gitignore. Including it on this PR, or in the open-source code, is a major security risk as it reveals the encryption methods used in my testing and can allow anyone to decrypt and reveal the game key (which is bad).

[r6915ee]

I'm very skeptical of this PR. There is already a class in flixel-addons called flixel.addons.api.FlxGameJolt that already serves this purpose, at least from my understanding of what this PR adds. I also think this is something that needs to be handled solely by the mod developer, not built into the engine, considering having access to the private key allows access to destructive changes with the GameJolt API.

[ItsLJcool]

I'm very skeptical of this PR. There is already a class in flixel-addons called flixel.addons.api.FlxGameJolt that already serves this purpose, at least from my understanding of what this PR adds. I also think this is something that needs to be handled solely by the mod developer, not built into the engine, considering having access to the private key allows access to destructive changes with the GameJolt API.

The issue isn't "it already exists" the issue is it's not secure and this is a solution attempt.

I haven't read the pr yet but we chatted in DM's, the point of making GameJolt support directly for CNE is so that you can't just hijack the data stream or make your own fake requests to a GameJolt server. You can easily do that if you softcode the support and it's been a pain in the ass for me to do so.

[Raltyro]

This is sick good

[MRK2009]

Noice
That would be good for Indie Cross, etc.

[r6915ee]

I'm very skeptical of this PR. There is already a class in flixel-addons called flixel.addons.api.FlxGameJolt that already serves this purpose, at least from my understanding of what this PR adds. I also think this is something that needs to be handled solely by the mod developer, not built into the engine, considering having access to the private key allows access to destructive changes with the GameJolt API.

Okay, I don't like this response of mine, it's far too vague (and in some cases far too different from what I think now) and I've been thinking about this pull request and the response from LJ. I do think GameJolt integration is a good idea, especially for things like keeping save data in GameJolt's data store (which in my opinion would be a huge benefit) and achievements, but I do think that this pull request could have some additional security.

I believe that there should still be some restriction on what softcoded mods can do, and from my understanding of the new classes this pull request includes, that doesn't seem to happen. I think that in this case, "set" operations of any kind (such as trophy addition, data store removal, etc.) should be exclusively done by compiled code, not HScript.

A "set" operation with the way this is implemented will usually bypass the private key in its entirety. It's very easy to edit scripts to add "malevolent" sets in this case, so this can have a variety of its own complications; one thing that immediately comes to mind are the endpoints for setting items in the data store, as the GameJolt API explicitly distinguishes between the global data store and the user data store. This can also be as simple as adding achievements the player hasn't actually collected. If sets are allowed in HScript code, then that bypasses the point of the private key and allows people to cheat the API.

[SplatterDash]

Okay, I don't like this response of mine, it's far too vague (and in some cases far too different from what I think now) and I've been thinking about this pull request and the response from LJ. I do think GameJolt integration is a good idea, especially for things like keeping save data in GameJolt's data store (which in my opinion would be a huge benefit) and achievements, but I do think that this pull request could have some additional security.

I believe that there should still be some restriction on what softcoded mods can do, and from my understanding of the new classes this pull request includes, that doesn't seem to happen. I think that in this case, "set" operations of any kind (such as trophy addition, data store removal, etc.) should be exclusively done by compiled code, not HScript.

A "set" operation with the way this is implemented will usually bypass the private key in its entirety. It's very easy to edit scripts to add "malevolent" sets in this case, so this can have a variety of its own complications; one thing that immediately comes to mind are the endpoints for setting items in the data store, as the GameJolt API explicitly distinguishes between the global data store and the user data store. This can also be as simple as adding achievements the player hasn't actually collected. If sets are allowed in HScript code, then that bypasses the point of the private key and allows people to cheat the API.

In all honesty I've been worried about the lack of restrictions too, especially with softcoded mods utilizing the GJ system. That's what I'm thinking of when it comes to "cheese control" - preventing people from modifying the softcode to basically cheese achievements, leaderboards and the like. I've had a few ideas to address it, but because every one of those ideas led to me realizing "modifying this element or that code gets around it", I'm still trying to brainstorm how to tackle the issue.
Game key encryption for this PR is being finalized really soon (hopefully tonight), so once that happens I wanna focus on the restriction issue before finishing my work on this.