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.
thomas hockAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Your first and biggest problem is that PHP applications are intended to be executed from source, so unless you compile your application, any other measures you take can be easily circumvented by the end user because they have the power to change the code.

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).

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.
thomas hockAuthor Commented:
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.
Olaf DoschkeSoftware DeveloperCommented:
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

Bye, Olaf.
Build an E-Commerce Site with Angular 5

Learn how to build an E-Commerce site with Angular 5, a JavaScript framework used by developers to build web, desktop, and mobile applications.

David FavorLinux/LXD/WordPress/Hosting SavantCommented: 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.
Scott FellDeveloper & EE ModeratorCommented:
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.
David FavorLinux/LXD/WordPress/Hosting SavantCommented:
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.
@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.
Olaf DoschkeSoftware DeveloperCommented:
SaaS by definition means running a service, distributors may only be business partners. thomas hook is asked to clarify.

Bye, Olaf.
Scott FellDeveloper & EE ModeratorCommented:
We are doing a lot of guessing without any input from the Author.

  1. Is the end product a zipped up web app of php files that goes to the distributor who sends to the end user?
  2. 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?
  3. 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.
I don't understand the confusion - there aren't a lot of assumptions here.

"the owner ... will  provide the software to multiple distributors"
"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"

These 2 statements clearly indicate the distributors are receiving tangible code / software. What do they do with it? They offer it as SaaS:

"distributors offering the same software as SaaS. "

So it can't be #1, because there's concern about disitributors "giving it to a mate", so clearly the software is provided to and is staying with the distributors (supporting the statement about Saas).

It can't be #2 for the same reason.

#3. Can't be this one because the software is being provided by the distributor and hosted as SaaS.

So it's #4:
Product is developed by OP "Developer" for his client "Owner", who sells the product to Distributors. Distributors sell the product as a SaaS offering, where the distributors host the service.

Also, the distributors aren't the end users. The OP indicated that "clients" are end users who pay the distributors, who then pay the owner. So it's not a central API scenario.

There are a lot of ways the OP could have worded it if it were any other way...

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Olaf DoschkeSoftware DeveloperCommented:
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.
thomas hockAuthor Commented:
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.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.