Best way to implement a registration setup in setup

[Da9L]

And by registration setup i mean..

 

I've developed a PHP application that i wish to sell. So i need some sort of way to make sure that my system only works if the user is registered / has paid for the app.. This is an area i have no experience in so im looking for advice and best practices.

 

Im thinking an API key that the user only gets when they pay, and the system then validates this key up against a server of mine, when its entered into the app. But should this check happen everytime the app is run or a specific task is run ? Or is there another more appropriate way to do this ?

 

Thanks ! 

 

EDIT: Lol sorry for title typo

Edited March 4, 2016 by Da9L

[Destramic]

well i have no real exprience what so ever when it comes to api's...but if someone is paying for a key then it makes sense to register the key to a site...ie:

 

phpfreaks.com = phpfreakskey

 

this way you can ensure the key is correct and also that the request for your api is phpfreaks.com, ensuring another site isn't using the key.

 

you'd simply have to create a page www.yoursite.com/api.php?key=phpfreakskey and then validate the key and where the request is sent from....if all checks out then the data can be sent

 

 

process seems simple to me but i may be overlooking things..

 

what does your api do exactly?

Edited March 5, 2016 by Destramic

[QuickOldCar]

There is just so much to explain and write about this topic.

I sent you a PM and willing to give you the grand tour through teamviewer on my server of how I do it. It would be easier to explain and show it.

 

A lot of people use oauth for their api security but am not too sure about it's current security the latest version.

I build my own REST api's.

 

The way I go about it is to make a front door script first.

This would be the api.myserver.com , api.myserver.com/script/ , api.myserver.com?app=cool_app_name address or however would like to structure it.

Will do all checks needed such as check if is a valid public or private key, use that key to query and find that user, if user paid up or not, domain protection and so on.

 

If all the above criteria is met you would include your application script so they can use it, otherwise access denied message.

 

For api systems I usually use json responses as default. Since is a REST design can do multiple header requests for which format a client would like to use.

If the client wanted something like xml or html, I would fetch the json file and output their format choice.

I usually cache json files to eliminate excessive usage.

If no cache file exists would get live data...creates the new json cache file, otherwise use the data from json cache. Is an expire time on the file.

 

To answer some of your questions:

You would need a user registration and login system

Once user pays you assign them a randomly made hashed key incorporating something such as a user id or username as salts to ensure is unique, store that under their users account in the database.

You have another column for that user in your database if payment is made or not using 0/1 or n/y values.