Features Requests / Possible Bugs

[usrbinsam]

Features Requests / Possible Bugs

[allanice001]

Examples of the above

User: sam

$ curl localhost:5001/api/check -X GET -d token=3CQ08J7RFCVA6M5RCH5QL5UXH -d user=sam -d machine=ryujin
{"result": "ok"}

User: paul

curl localhost:5001/api/check -X GET -d token=3CQ08J7RFCVA6M5RCH5QL5UXH -d user=paul -d machine=ryujin
{"result": "ok"}

Machine: peanut

$ curl localhost:5001/api/check -X GET -d token=3CQ08J7RFCVA6M5RCH5QL5UXH -d user=paul -d machine=peanut
{"result": "ok"}

Machine: raisin

$ curl localhost:5001/api/check -X GET -d token=3CQ08J7RFCVA6M5RCH5QL5UXH -d user=paul -d machine=raisin
{"result": "ok"}

[usrbinsam]

Yes this, this is intentional. Anyone can rename their computer or user name on a machine. Machine name and username are only memo fields to help you with fraud detection to who is using your software and on what machine.

The only way to really prevent key stealing would be to seed an activation hash using hardware IDs and the activation key on the licensed machine and upon first activation, store that on the DB side and on each check, send the hash and make sure it matches what was sent for the first ever activation.

The problem with is if it’s hard coded into a public library, anyone can come to this repository and see how it works and crack your software.

I do have a Client-Side library for this on the TODO list but it’s not done yet.

This is why the username and machine name exists, to help you manage fraud in the meantime.

[usrbinsam]

You can achieve this with the hwid parameter. If supplied, the key can only be checked on that one machine. I will have to come back around and store multiple activations on the same key in a table to allow one key to be used on multiple machines.