entiretwix / ccash

an external ledger for in-game economies, running on a webserver with a RESTful API, exceptionally fast and lightweight written in C++

• solution

• connected services

  • how to create
    • explanation
    • API Libraries
    • endpoints
  • existing services

• features

  • user side
  • implementation

• building

• FAQ

• Versions

ccash's Issues

I don't see enough Rust

Let's just rewrite everything in Rust shall we?

Return Values are Ambiguous

Return values from multiple endpoints, especially from sending funds, are very ambiguous. It is difficult to tell what went wrong when errors are in binary format. Thus, I suggest a new error system in which number codes are utilized. This will not only be easy to implement at minimal performance cost but will also increase code clarity and decrease the aforementioned ambiguity.

Unkown Bug deletes overrides save data with null

Docker Instructions are outdated

After the refactor docker Instructions were neglected and small tweaks need to be made

Logs Loaded incorrectly as blank

[BUG] SegFault from invalid json input

invalid json input of """:"user",":"user", to add user is able to seg fault the server

move build args to config file

[BUG] Github Auto Build has some problems

Compliance with RFC Documents and Endpoint Suggestions

Normally, POST requests are meant to "provide partial modifications to a resource" and thus their bodies should be sparse and the known resource should be declared within the URI. Thus, the request body of a PATCH request should not be required to again hold the name.

Another endpoint I would suggest a change for is the POST request to get logs. Obviously this should be a GET request as we are acquiring information rather than giving it.

Furthermore, DELETE requests are suggested to have the target within their URI rather than within the body of the request.

Finally, I have a couple more suggestions that do not need to be considered at all. For the above changes and those stated in my other issue from today, a new API version should be introduced so as to not ruin compatibility and allow a movement whenever connected services are ready to do so. I request that this new version begin to follow a common scheme with the endpoint beginning as such: /api/V2. This can be accomplished by placing the class V2 within the namespace api which can also be used for subsequent versions and changes.

FInally, I would like to suggest a different way to authorize requests. After all my talk about following convention, I would like to suggest the use of a new header: "Password" (creative, eh.) This would hold the non-encrypted password without any other information. Using a header would most likely be much faster than using JSON if we take into account parsing it then accessing by string keys, and thus we will reduce the need for JSON in many endpoints. Admin passwords should have their own header called "Admin-Password" in case of an endpoint that needs both a user and administrator password in the future.

Thanks for being so supportive of suggestions thus far.

[BUG] ImpactBal int64_t

while very unlikely, it is possible to overflow a users balance (stored as uint32_t) with a sufficiently large ImpactBal amount argument