Hi,

I wrote a small web hosting billing system in PHP, everything is done, except i want to creat licences for it. It dont want my code to be free. I want to issue lincense's for each download and they should enter it while installing their on their site. Help appreciated.

erm... i guess theres many ways you could do this.

BUT NONE will be completely effective if someone wants to nick your software they probally could. - look at Vbulletin..

Right well with regards to registration,
i would suggest on install having a userid and a passcode, and maybe have it so the script accepts these checks it against YOUR database on your server and if valid allows the rest of the script to install.

and on your site on the download/buy section, have it so once payment is done they enter all their info (like email, name, and what ever else you want)
you then have the script add the user to your database, and also generate some random string of letters and numbers and then save that with the users info and email it to the new user,

then they can use it to install the software.

also "call home" features would help, like have it on successful install send back the domain and IP address of both the user and the server and add them to your client database.

this way, you can see if someone from the same ip (so usually the same person) has installed it on multiple domains.
if they use the same secret code.

You must understand tho, someone could get hold of the script and if they know how just remove all the call home bits, and install it. and you wont know.

But its problly unlikely.

Hope this helps

Talkupation apprieciated.

BTW.. im looking for a billing system for my hosting site which is going to be relaunched.

can i get a demo and price?

here is the thing it is code it can be changed easily so your best bet is installing the code their server not allowing downloads or send it by email when purchased because code is easily changed when you have the code and if you keep part of it on your server to verify the code someone will just NULL that part of the code maybe rise your price $5 more to help pay for piracy issues infact did you know out of every 2 programs installed one is pirated out of all the installs statistic wise.

Yes as GHT said.. it can be removed or "NULL" ed

ok what i would suggest is use a good mix.

so you could keep the .zip/.rar or whatever compression your useing.
have like i said the script generate a unique passcode for the user, which gives them access to the download page

where you could have something like :

PHP Code:

<?php
if(isset($_POST['submit']))
{
$email = (isset($_POST['email']))  ? mysql_real_escape_string($_POST['email'], $link_db) :'';
$passcode = (isset($_POST['passcode'])) ? mysql_real_escape_string($_POST['passcode'], $link_db) : '';
 
$result = mysql_query("SELECT * FROM clients WHERE email='$email' AND passcode='$passcode' ", $link_db)
or die("ERROR: could not retrieve info. contact admin" .mysql_error());
 
$num_rows = mysql_num_rows($result);
 
if($num_rows=1)
{
 
header('Content-type: application/zip');
 
#File name.
header('Content-Disposition: attachment; filename="download_billing_system.zip"');
 
readfile('/home/USERNAME/securefiles/mybillingsystem.zip'); 
# this is the hidden source i would suggest having this stored #BEFORE your public_html/www folder so it can only be accessed #through PHP
 
}
 
else {
echo 'there was a error with your email/passcode! <br />
you must use the same email and passcode provided at registration.';
}
 
}
else {
echo '
<form method="post" action="">
Email: 
<input type="text" name="email" size="30" />
<br />
Enter your passcode: 
<input type="text" name="passcode" size="30" maxlength="30" /><br/ >
<input type="submit" value="Verify" name="submit" />
</form>';
}
 
?>

ok, so the above rather longer than i expected script firstly has a simple form where user inputs their email and passcode.

this is then checked against your database where their email and the generated passcode was stored after payment was successful.

if it matches, then the download will pop up. and they can then begin to download.

during the reg process where you gather this info, you should check the email is theirs.

then like i said above i would suggest the call home thing as well, this way its the little extra layer of protection.

so if/when someone who has brought your script decides he wants to share he would also have to share his passcode and email.

and if like i said above you have on the script the call home thing which will clock up how many installs this guys had, (which you could also have a thing email you is a user installs it more than X times..)

you can see whos installing it a few more times than you like, and could block and remove that email and passcode from the DB

like GHT said someone could remove the call home, but they would have to buy it first.

and to be honest i dont think many people would first buy/get hold of your script, go thro it all to remove the call home to use it.

and if you that amazingly worried someone would, then frankly dont even sell it.

you could also use the same script above but as GHT said use it to email the script to the person

IF you need anymore info or anything just ask


Dan
Talkupation apprieciated

you could also use zend guard to protect the code so the user can't change anything. http://www.zend.com/store/software/zend_guard

People are going to find this a pretty funny suggestion ... but head over to msdn ( Microsoft Developer Network ) and download the shareware starter kit. I'm not sure how much will translate without project mono, but it has all of the licensing and whatnot built in. It's free, so you might as well look the code over and see if there are any ideas worth borrowing.

It seems once again we have a fly-by question.. by someone who hasnt checked back

Have you considered in using SourceGuardian.com? It uses a Zend-based engine but it doesn't require additional software installed on the server - basic php installation. It also includes licensing support ( as far as I know ). It's cheaper than Zend Guard but more expensive than IonCube PHP Encoder. But I'd pay a couple of bucks extra to ensure hassle-free installations for my customers.

Your comment about Source Guardian not needing anything server-side intrigued me so I checked it out...

On http://sourceguardian.com/faq/index.php they say:
- Requires no additional software to run on the server
- Requires no changes to the webserver or default PHP installation

but then on http://sourceguardian.com/ixeds/index.htm they say:
Encoded scripts protected by SourceGuardian for PHP require loaders to run.

Can anyone explain this discrepancy for me please?

Originally Posted by TwistMyArm

Encoded scripts protected by SourceGuardian for PHP require loaders to run.

Can anyone explain this discrepancy for me please?

Encoding systems for PHP fall broadly into two types; those that trivially hide source code and rely on restoring it at runtime to process with calls to eval(), and those that compile to bytecode. PHP itself compiles to bytecode at runtime, and the compiled code systems take advantage of this to precompile code and protect the bytecode. SG is a compiled code system, and as with all such systems, a component is needed on the server to process the code.

However, despite needing software on the server, SG and ourselves offer a feature that we call runtime installation as a way for the loading component to be installed on the fly from the user's own area as opposed to it being installed in the php.ini file. So not needing installation on the server actually means not needing to edit the php.ini file, which is how we word things in our blurb. This uses a feature in PHP called dl() that can install a module on demand. There are a few prerequisites for this to be possible, but in our experience it often is and it has been great for users on the shared hosts who may not like to install any additional modules themselves. Although Zend Optimiser isn't always popular with hosts because it can slow machines down and increase load, if you search forums such as WHT, you'll find that hosts tend to support ionCube and Zend encoded files as standard or will add support if required.

There was a comment about SG using a Zend based engine. This is true, but not in its own component, and this is where we find some other distinctions. Compiled code systems themselves break down into two sub categories; those that restore compiled code to be processed by the standard opensource engine, and those that contain their own engine. SG and most others restore native bytecode, which is simple to do but does nothing to hide the bytecode, and Zend and ionCube use their own execution engines that are derived from the standard engine but where additional features have been added. In our case we use this to do things such as keeping the bytecode away from the standard PHP function table and to allow the execution engine to execute mangled bytecode rather than native bytecode. Zend use a modified engine in part as the bytecode is extended to support some of the code optimisations.

Other benefits that come from encoding include being able to create license files or to restrict the files themselves. For example you might want to make files stop working after a certain time, or to make them usable only on particular machines.

The original poster asked about protecting PHP, but what about template files, XML and other metadata? If you have them then it can be useful to protect those files too, and you'll find some products offer that type of feature as well. We were the first to introduce the idea back in Jan 2006, and possibly some other encoding products have followed our lead with this since. To decrypt the encrypted files you would call a Loader API function from an encoded PHP file, and for completeness, we added a way to encrypt data too so that you could write back encrypted config files for example. You may have heard of the popular template engine called Smarty, and we published a simple patch that shows how you can use both plain and encrypted templates with Smarty. View the patch

As well as the obvious area of protecting code for sale, web developers can benefit from encoding as can website owners, particluarly those on shared servers where security is not always what it should be. Hope this info helps give some clarity, and if you have queries about encoding technologies then feel free to followup or get in touch directly and we'll be happy to help.

So not needing installation on the server actually means not needing to edit the php.ini file, which is how we word things in our blurb.

Ahh... that makes more sense, thanks. Thanks, too, for the extra information: it's definitely an interesting area of research I think.