Developers to implement licencing API
- Thread starter Influxes
- Start date
-
- Tags
- api test please
- Status
PebbleHost
High performance, consistent uptime and fast support. Minecraft hosting that just works.
(I am not sure on the exact response headers and payload of the responses.) I may suggest that you implement some kind of returned value which will also be checked at the programs end. Why? So people can't just mock the API and fake return a valid response from POST /checkHWID?hwid=HWIDTOCHECk .
Am i blind or does it also not have a download? Or if hes the one hosting it i dont see what url we are supposed to send these requests to.
Also hes gonna have to do something to ensure its actually receiving it from the right server cuz people could just redirect the license checking site to something else that always says its valid.
That's exactly what I was saying. I could fuck this whole thing up by getting a valid license once, sniff the response and just redirect all API requests to my localhost API mock.
Also yeah there is nothing which states the API URL, I guess they will send it privately to anyone.
Excuse me if I am wrong, but if the point of this is to check if a HWID is whitelisted from within your software that's distributed to clients, why would it specify the same API key that's used to add/remove HWIDS?
In my opinion it would make more sense to have the API create specific applications that have tokens, then have those tokens specified in the endpoint so you can check if it is valid for a given application token...
EDIT: Nevermind, I think I misread the point of this, the implementation is still not as ideal as it could be but it's not terribly flawed (only slightly flawed)
In my opinion it would make more sense to have the API create specific applications that have tokens, then have those tokens specified in the endpoint so you can check if it is valid for a given application token...
EDIT: Nevermind, I think I misread the point of this, the implementation is still not as ideal as it could be but it's not terribly flawed (only slightly flawed)
Last edited:
If the action is successful, the program will get json back with the status of the action and any information about the successful action.[DOUBLEPOST=1569456327][/DOUBLEPOST]
It is a rest api hosted on a website of mine. It is true if someone cracks your program, they can mimic what my api responds back to break the licensing system. But let’s be honest, if someone cracks your software not much can be done to stop them from altering it.[DOUBLEPOST=1569456560][/DOUBLEPOST]
There are two API keys, one is your public key and the other your private key. Your public key goes into the actual program, and can only be used for checking if an HWID is whitelisted, and redeeming a license key. The secret key is for adding/ removing HWIDs and adding/removing license keys. My current plan is to have any program that implements this api to have its own private and public key. Therefore each program has its own HWID and license key database respectively.[DOUBLEPOST=1569456750][/DOUBLEPOST]Also, the reason I am letting people use my api for free right now, is to sort out the security flaws and bugs and see how I can fix them.
Last edited:
That makes a lot more sense (you should clarify which is which on the documentation page).
If you plan to sell this eventually it might be smarter to split a developer's dashboard into applications that each have their own private/public token, that would get a lot more developers interested in buying this and using it to secure their software.
There are certain steps the client can take to make sure that they are receiving a response from the authentic API and not from someone making a fake one just with 20 minutes of python and changes to their HOSTS file. I'd also recommend reading up on that if you plan on making this public/paid in the future.
Exactly what I was on about. Without checking and generating specific things on both your server and the program, this is next to useless for anyone who has a little bit of experience or knows how to google.
Thanks for the recommendations. Sadly this doesn’t actually have a dashboard yet, however I hope to make one. I know the documentation is sucky. I started this project about a day ago, so there is still a lot to improve. I am thinking of making it so the api responds with a number generated from a seed that both the api and the program share. Similar to what some garage doors do. But if you have any suggestions for what I can implement to improve the security, I am all ears.
UPDATE: API now receives api keys through a header, requires a timestamp, and uses https. Also, no information is received over quary strings, and is now gotten from json[DOUBLEPOST=1569520627][/DOUBLEPOST]
Is there anything else in your opinion I should add for security purposes?
^^ Updated documentation with all the calls and requirements. Along with the error codes that the API may respond with.
Is there anything else in your opinion I should add for security purposes?
^^ Updated documentation with all the calls and requirements. Along with the error codes that the API may respond with.
Last edited:
I'm not a security expert by any means, especially not with REST API security. I would recommend doing research/due diligence and reading up on how to make it as secure as possible—inevitably it will probably still be insecure but it's better to go through that and make it as good as you can.
Good luck
Thanks!I'm not a security expert by any means, especially not with REST API security. I would recommend doing research/due diligence and reading up on how to make it as secure as possible—inevitably it will probably still be insecure but it's better to go through that and make it as good as you can.
Good luck
- Status
