thomas hock
asked on
Simple "License Key" System PHP
Hey guys, I have currently developed software (in PHP) that will be used as a service. The issue I'm facing is that the guy I'm working for is the owner but he will provide the software to multiple distributors offering the same software as SaaS. So i guess its like a chain of events? The clients pays the distributor, the distributor pays the owner. What i would like to know is - can I implement a simple way to determine whether the DISTRIBUTERS are the only ones using this service e.g they aren't doing the dodgy and giving it to a mate. I have thought about this, maybe adding a sort of IP address checker which upon activation stores the server IP address in the "main database". What is the best way to address this issue? I know licensing only goes so far and is easy to get around.
ASKER
Thanks for taking the time to reply gonzo, much appreciated. I'm going to have a look at Zend now. Cheers for the detailed and useful information.
If this is only run at one central server the interface only are API calls, aren't they? Then the open source code isn't a problem if even distributors are not given the sources to establish the same service.
Your problem rather is separating end users from distributers. IP addresses will not necessarily show that, if all requests are bundled at this one endpoint you don't see the origin IP of users.
There seems a simple solution, you're giving authentication tokens or something like that, and what can be done with them is under your full control. You can simply limit the access permission and functionalities unlocked by distributor tokens to enable generating user tokens. And tokens for end users don't unlock those permissions, but instead, open up the end user features.
What this doesn't cover is distributors creating a single end user token and using that for their customers, but that should be covered by a rate limit, a certain number of requests per day, hour, minute, so any single token only has a limited value. End users not getting their request limit then will know they're using a shared token.
It's not a simple topic even on the non-technical level, as you can see from https://www.quora.com/What-have-been-the-best-distribution-channels-for-your-SaaS
Bye, Olaf.
Your problem rather is separating end users from distributers. IP addresses will not necessarily show that, if all requests are bundled at this one endpoint you don't see the origin IP of users.
There seems a simple solution, you're giving authentication tokens or something like that, and what can be done with them is under your full control. You can simply limit the access permission and functionalities unlocked by distributor tokens to enable generating user tokens. And tokens for end users don't unlock those permissions, but instead, open up the end user features.
What this doesn't cover is distributors creating a single end user token and using that for their customers, but that should be covered by a rate limit, a certain number of requests per day, hour, minute, so any single token only has a limited value. End users not getting their request limit then will know they're using a shared token.
It's not a simple topic even on the non-technical level, as you can see from https://www.quora.com/What-have-been-the-best-distribution-channels-for-your-SaaS
Bye, Olaf.
http://ioncube.com also provides a system for encrypting PHP code.
Most hosting companies provide IonCube loader decryption support, so IonCube loader code is fairly common.
With IonCube you bake in your licensing, then encrypt your code with IonCube, then deliver the encrypted code to your SAAS provider.
This blocks most attempts at hacking code + defeating licensing.
Most hosting companies provide IonCube loader decryption support, so IonCube loader code is fairly common.
With IonCube you bake in your licensing, then encrypt your code with IonCube, then deliver the encrypted code to your SAAS provider.
This blocks most attempts at hacking code + defeating licensing.
When you say, "software" and "service" are you referring your product runs on a web server that you control or the php pages are being installed on the end users machine?
If you meant that you provide a software as a service that is resold by a middle person, then I would create a reseller area on the site that allows the distributor to purchase licenses either one-off or in bulk. Save the license codes to to a table on your db that tracks the license, the distributor, number of users authorized and fields for activation and deactivation dates. In another table tracks users. The distributor simply has to give out the license number to the user. Each time the user adds a new member, you save that member to t he user table that includes their basic contact information, activation and deactivation dates. A query in your db will do the math to show how many licenses are available.
What I have done in the past is to set a cookie on the machine that the user is logging in. The work flow was the local site admin added the user with contact information, username and temp password. The end user logged in, was asked to submit a new password, then name their machine. I saved the machine name to the table that stored only machine names and users with a hash code in the db. Then the hashed code gets stored as cookie. When the user logs in, I test the password and cookie. On subsequent pages that check authentication, both session and cookie are checked on each page load. This takes into account multiple users on one machine.
By tying your app to individual users, it will be hard to share. There will always be dishonest people and you have to balance how much energy you want to put into going after every last person. I know there are some members on this site that have shared log in information. It's not that hard to catch just by observing how things are written.
If you meant that you provide a software as a service that is resold by a middle person, then I would create a reseller area on the site that allows the distributor to purchase licenses either one-off or in bulk. Save the license codes to to a table on your db that tracks the license, the distributor, number of users authorized and fields for activation and deactivation dates. In another table tracks users. The distributor simply has to give out the license number to the user. Each time the user adds a new member, you save that member to t he user table that includes their basic contact information, activation and deactivation dates. A query in your db will do the math to show how many licenses are available.
What I have done in the past is to set a cookie on the machine that the user is logging in. The work flow was the local site admin added the user with contact information, username and temp password. The end user logged in, was asked to submit a new password, then name their machine. I saved the machine name to the table that stored only machine names and users with a hash code in the db. Then the hashed code gets stored as cookie. When the user logs in, I test the password and cookie. On subsequent pages that check authentication, both session and cookie are checked on each page load. This takes into account multiple users on one machine.
By tying your app to individual users, it will be hard to share. There will always be dishonest people and you have to balance how much energy you want to put into going after every last person. I know there are some members on this site that have shared log in information. It's not that hard to catch just by observing how things are written.
Scott brings up the same point I was making, which I could have phrased clearer.
As Scott says, There will always be dishonest people and you have to balance how much energy you want to put into going after every last person.
Easy way to deal with this is if you run the SAAS platform, so you control/enforce licensing.
If you deliver code to some 3rd party, where they run your code on their own SAAS platform, they baking in license enforcement + encrypting your code with IonCube is likely your best option.
And, if possible, host the code yourself + skip the IonCube encoding step, as IonCube is a pain to work with.
As Scott says, There will always be dishonest people and you have to balance how much energy you want to put into going after every last person.
Easy way to deal with this is if you run the SAAS platform, so you control/enforce licensing.
If you deliver code to some 3rd party, where they run your code on their own SAAS platform, they baking in license enforcement + encrypting your code with IonCube is likely your best option.
And, if possible, host the code yourself + skip the IonCube encoding step, as IonCube is a pain to work with.
@Olaf - the OP clearly states the software is going to be provided to multiple distributors who will run it as a SaaS application.
If I read the OP's question correctly (and I'm pretty sure I am - the language is pretty clear), the concern is about an authorized distributor then sharing the code with a friend by simply giving them the code and a copy of the database.
If all of the "activation" is all on the client-side, then it becomes difficult to enforce any kind of copy protection, especially with a language like PHP where it has very limited access to the hardware details. For example, if a valid license is stored in a database and that's all that's needed, then copying the database means you get a copy of the valid license, too, so it defeats the copy protection intent.
You can try to tie the license STRICTLY to environment details, like HDD serial numbers or something, like Windows does with its activation, but a standard web hosting company is going to swap out HDDs from time to time and / or change little things about their environment, which could invalidate the license even though they haven't truly violated the copy protection. So "phoning home" is sometimes the best way to deal with distribution.
David Favor brings up a good point - that ionCube is supported on a lot of hosting providers, so it's also a good option. I've never used it for encoding but I've heard good things. Some of my notes on the others:
Roadsend - Nice product if you want to distribute a PHP application as a .exe file on a thumb drive or something, since it has a built-in web server, but no longer actively developed.
Zephir - Good for compiling your own custom PHP extensions by writing code that's 99% like object-oriented PHP, but not feasible for writing an entire application in it.
All the others on my list are REALLY old and/or deprecated by now.
If I read the OP's question correctly (and I'm pretty sure I am - the language is pretty clear), the concern is about an authorized distributor then sharing the code with a friend by simply giving them the code and a copy of the database.
If all of the "activation" is all on the client-side, then it becomes difficult to enforce any kind of copy protection, especially with a language like PHP where it has very limited access to the hardware details. For example, if a valid license is stored in a database and that's all that's needed, then copying the database means you get a copy of the valid license, too, so it defeats the copy protection intent.
You can try to tie the license STRICTLY to environment details, like HDD serial numbers or something, like Windows does with its activation, but a standard web hosting company is going to swap out HDDs from time to time and / or change little things about their environment, which could invalidate the license even though they haven't truly violated the copy protection. So "phoning home" is sometimes the best way to deal with distribution.
David Favor brings up a good point - that ionCube is supported on a lot of hosting providers, so it's also a good option. I've never used it for encoding but I've heard good things. Some of my notes on the others:
Roadsend - Nice product if you want to distribute a PHP application as a .exe file on a thumb drive or something, since it has a built-in web server, but no longer actively developed.
Zephir - Good for compiling your own custom PHP extensions by writing code that's 99% like object-oriented PHP, but not feasible for writing an entire application in it.
All the others on my list are REALLY old and/or deprecated by now.
SaaS by definition means running a service, distributors may only be business partners. thomas hook is asked to clarify.
Bye, Olaf.
Bye, Olaf.
We are doing a lot of guessing without any input from the Author.
When I think of SaaS, I think of option 3. I can buy Google Apps or Salesforce from a re-seller (distributor) where the payment goes through the re-seller and that is where my relationship is. But the service is hosted by Google or Salesforce. If I have an issue, I go to my reseller who trouble shoots with me.
The point is, we have some assumptions and no input to go on. Otherwise, there are all very good options here.
- Is the end product a zipped up web app of php files that goes to the distributor who sends to the end user?
- Is the end product a zipped up web app of php files that is sold by the distributor but delivered to the end user by the developer?
- Is the end product hosted by the developer and sold by the distributor?
When I think of SaaS, I think of option 3. I can buy Google Apps or Salesforce from a re-seller (distributor) where the payment goes through the re-seller and that is where my relationship is. But the service is hosted by Google or Salesforce. If I have an issue, I go to my reseller who trouble shoots with me.
The point is, we have some assumptions and no input to go on. Otherwise, there are all very good options here.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
You can provide software as a service without providing eceiving tangible code / software
The providers might just be doing marketing for the owner,no more, no less.
Bye, Olaf.
The providers might just be doing marketing for the owner,no more, no less.
Bye, Olaf.
ASKER
Thank you for all the helpful information but gonzo has previously summarised and helped me find what i need. I will also take the other answers into consideration.
With that in mind, you can do some Google searches for PHP compiling (don't both with "obfuscation" - that makes it more difficult for someone to modify the code but it's still possible). There are a handful of options, but unfortunately many of them are not in active development or have limitations (e.g. Phalanger-compiled PHP requires the .NET / Mono framework to run the result). Your best bet, although it's not free, is to go with the industry standard for PHP, which is Zend's products (note: I do not work for them nor do I get any sort of compensation from them for this recommendation - it's just the most practical recommendation).
http://www.zend.com/en/products/zend-guard
Once you have a way to compile your programs, then you can start figuring out the best way to enforce some limitations with code that will be protected from prying eyes and from modification.
I would probably suggest doing an occasional "phone home" routine when the software is executed for the first time each day. Have your script collect a little bit of info about its current environment (e.g. HDD serial number, current path, server version, etc), the owner's "ID" (some kind of unique identifier for the distributor, like their email address or something) and send the data, along with the current date back to a script on your own server.
Your script can then record all that information in a database on your side (along with the originating IP) and if everything checks out okay, have it use a private key to take the current date and create a digital signature for it and send the signature back to the requesting script.
The requesting script can then use a public key (embedded within the compiled code so someone can't just generate their own key pair and use it to circumvent the activation) to validate the signature and if it's valid, have it save that file locally to "activate" it for another day.
If it hasn't been activated in over a week (a grace period), then just prevent the rest of the application from running until the license check works.
Now, if your distributor updates their software or their environment or whatever, then you'll be able to notice the difference in the recorded details, so if you start seeing regular usage by the same user ID but with different environments each day, you can figure that someone shared the application and you can tell your master script to choose NOT to sign the activation request for that user ID, so their script will simply stop working until they clear up the issue with you and get a new user ID / key that hasn't been shared.