j3k0
commented
7 years ago Thanks, probably the doc should make that clearer. This lib aims at just working on the simplest use cases, for developers that want a working solution. When "hackers" become a problem, it means you surely have enough money in bank to dig in for a more custom solution.
For instance, you can monitor the cordova-plugin-purchase's approved() callback to validate and save the transaction receipt aside, send it to your server together with the claimed expiryDate, for validation. Make sure the server only accept to store validated expiry dates.
That alone is not enough. If the only logic your server provides is to return an expiry date, a malicious user can simply inject an "improved" loadExpiryDate method (that always returns tomorrow's date). Changing javascript files is easy.
Only if the server provides complex and required business logic, then validating the receipt server side will allow to really block paid features. In that case, I would advise to fork this lib and customize it to your needs.
By reading this documentation, you advice user to send expiricy from the application itself. It is a security issue. If i'm a bad user, i can easily make a request to the api endpoint without paying anything.
You should advice user to verify server side to check on the InAppPurchase entity (android/apple, they expose API) if the payment was successful. Or if there is any post-payment callback from these server, to just define an endpoint on their server.