Web Developers: Have you ever gotten to the end of a project, and had a client withhold the last of your fee to exact additional changes or features that were not in the original plan? Perhaps a client that decided your work “wasn’t what we expected” and tried to withhold payment?
Well worry no more. Put the power back in your hands with a Remote Kill Switch. The idea is this: you build into their website a small function that checks with a server you control to make sure the client’s account is in good standing. If it is, the site loads as normal. If not, their site doesn’t load, and they get a message asking for payment.
We’ll accomplish this with a little PHP and a protocol called XML-RPC (remote procedure call). Your client’s server will transmit an XML encoded, unique string identifying itself to your server. Your server will check to see if that unique string is one you’ve specified as disabled. If there is a match, it responds with a XML encoded string telling the client’s server to disable the application.
Sound like something you’d want to implement? Here’s how it breaks down:
Part One: Your server. You’ll need a fairly reliable host, and a fast one at that. You don’t want to slow down the remote application load with requests to your server. However, the below code is set to continue loading the remote application even if it does not receive a response from your server, ensuring that downtime on your end does not cause downtime on their end.
Part Two: The code on your end. Also known as the RPC server. Create a new file and paste the following:
require('XMLRPC.inc.php');
function checkapp($the_app)
{
$deactivateMe = ""; // to disable a webapp, enter it's short code here
if (isset($the_app) && $the_app == $deactivateMe)
return true; // Application Disabled
else
return false; // All systems go
}
$server = new IXR_Server(array('activation.checkapp' => 'checkapp'));
You’ll also need to download XMLRPC.inc.php and upload it to your webserver in the same directory as the file you created above. You will need to change the file extension from .php.txt to .php.
Part Three: The client code. Also known as the RPC client. Insert this code in your client’s site, preferably toward the beginning of execution:
require('XMLRPC.inc.php');
$appname = "UNIQUE_APP_SHORTCODE";
$client = new IXR_Client('http://path_to_file_created_earlier.php');
if (!$client->query('activation.checkapp', $appname)) {
if($client->getResponse() )
{
die("Application Disabled. Please pay your web developer.");
}
}
Again, download XMLRPC.inc.php and upload it to the server in the same directory as the file you created above. This library is required both by the client to make the request, and the server to respond to it.
That’s it! If the client ever doesn’t pay you, and you want to shutdown the site you developed for them, just set $deactivateMe in Step 1 to the “UNIQUE_APP_SHORTCODE” you entered in the code in Step 3.
You can see that the above setup allows you to protect multiple web apps at once, just remember what shortcodes you assigned at what sites! I recommend keeping them in comments at the top of your XML-RPC server PHP file. However, a limitation of my code is that you can only disable one remote site at a time. I’m sure my code could be expanded to use an array that would allow you to disable multiple sites at once.
I realize that this is significantly more technical than my typical fare (which I will return to next post), but I hope it’s helpful to some people, if only as a demonstration. Feel free to rip my code apart in the comments, I’m sure I’ve left something out.
Disclaimers and warnings: You use the above code at your own risk. It is probably buggy and insecure (though it does work). I take no liability for any harm that should befall your data, your bank account, or your person as a result of implementing this idea. You should obviously remove the activation check as soon as the client has paid you for your work. It’s definitely unethical (and insecure) to leave this backdoor in place after you have finished the project. Also, this kind of system won’t work against someone who knows anything about how their site is programmed. But then again, those people probably wouldn’t be hiring freelance web developers would they?
Did this post help you? If it did, I'd love it if you'd sign up for my newsletter. I send out non-public stories, coaching tips, tricks, and funny stories every week. Enter your email address below.
The file attached is undownloadable. I am quite interested to see this code in action. I think you have to name the name .phps or .txt or something else for people to download the file, and not execute it like a .php file. Thanks.
The file attached is undownloadable. I am quite interested to see this code in action. I think you have to name the name .phps or .txt or something else for people to download the file, and not execute it like a .php file. Thanks.
Imran,
Thanks for saying something. The file should be good to go now. Let me know if you have any further problems.
– Bill
Imran, thanks for saying something. The file should be good to go now. Let me know if you have any further problems.
– Bill
Bill how does this whole process wrk
Any ideas for an ASP application?
John I don't know ASP, but if you had access to a PHP host, you could leave
the “server” module unchanged, and you'd only have to rewrite the “client”
bit in ASP and work it into whatever final code you have…the HTTP
responses can still be understood by ASP I believe…
Any ideas for an ASP application?
John I don’t know ASP, but if you had access to a PHP host, you could leavernthe “server” module unchanged, and you’d only have to rewrite the “client”rnbit in ASP and work it into whatever final code you have…the HTTPrnresponses can still be understood by ASP I believe…
Thank you. I discount.
I've been in this bussines for 6 years now and I've never met any clients who did not pay(and yes I had some major disagreements with them). It is simply a matter of doing your job well and thoroughly. When you have a disagreement with a client you settle it, like adults, not with some nifty remote killswitch trick. I find this unethical.
Assuming you've probably documented the project scope, the clients needs and you gave regular updates to them about the project on which you received feedback(you communicate clearly and regularly with them). You also will have a legal agreement/sales contact or whatsoever which states scope, deadlines, mutual expectations and prices/payment.
This will avoid any “kill switch” constructions, backdoors and unethical control of clients property(the switch will still be in placeeven when a client has paid his bills). I personally find this bad webdevelopment practice.
i have to disagree with you strongly. i’ve been a freelance developer for 5 years now. MOST clients pay. but i have had a few clients (one of them a reputable non-profit which i won’t mention by name) either incredibly late on payment to the point of absurdity (and only after a lot of calling and emailing and threatening) or just decide not to pay. i use contracts but contracts are only useful if you are actually going to litigate which for most freelance developers isn’t really an option.
i even had one client lie and say they had no idea they contracted my services even though i had emails proving they did so.
the bottom line is that people sometimes try to take advantage of freelancers even if the freelancer does his/her work. i have friends in the graphic design world who have the same problems. its almost a universal fact.
so its totally worth having a method to protect yourself. i don’t see how it is unethical to disable a site you built if you are not getting paid for your time.
i’m afraid i don’t understand how you don’t see the sense in that.
I agree with Gabriel. Technically if you built some code into it, it’s not theirs. It is still your code until they pay for it.
I’m going to have to agree Gabriel here. If you’ve developed code for a customer and they’ve refused payment the code really doesn’t belong to them until they’ve met their financial obligations outlined in the project proposal and scope. This is a nice fail safe that unfortunately we’ve had to come to because some customers don’t value services rendered as much as they did at the outset of the project. If you don’t pay the electric bill the power gets shut down. If you don’t pay for your cable, you don’t watch TV. If you don’t pay for your software development services it’s perfectly acceptable that the code ceases to function.
I’ve been in this bussines for 6 years now and I’ve never met any clients who did not pay(and yes I had some major disagreements with them). It is simply a matter of doing your job well and thoroughly. When you have a disagreement with a client you settle it, like adults, not with some nifty remote killswitch trick. I find this unethical. rnrnAssuming you’ve probably documented the project scope, the clients needs and you gave regular updates to them about the project on which you received feedback(you communicate clearly and regularly with them). You also will have a legal agreement/sales contact or whatsoever which states scope, deadlines, mutual expectations and prices/payment.rnrnThis will avoid any “kill switch” constructions, backdoors and unethical control of clients property(the switch will still be in placeeven when a client has paid his bills). I personally find this bad webdevelopment practice.
Nick,rnrnI agree – everyone would prefer not to resort to things like this. The unfortunate reality though is that some clients don’t pay – I’m glad you haven’t personally experienced it. rnrnAs I mentioned in the disclaimer in the post, any and all backdoor code should be removed as soon as a client has paid his final bill, and certainly before the site goes live.rnrnAny technical measures are a safety net in case normal methods of recourse break down.
I have had a major chain (300 plus stores) reject final payments once we handed over the project. Obviously we accepted money to start the project and some money during development. But the bulk of it was rejected as soon as they got the working build of the system. We, the development firm, were timely and professional. But for an established company they had some shady division head try to take advantage. (Which is more unethical than us using scripts to ensure agreed upon payment.)
Had we not put in custom in-house obfuscated code that verified timestamp of an overdue payment and server IP we might of lost thousands of dollars worth of man hours we put into the project. Luckily doing a process like this got the client to pay up and we updated the system to not include this code. They claimed they simply lost contact and we rejected payments. Yet, this is not what happened and we were notified same day the code took their system off-line to the same phone number we been telling them to contact us at.
So yes, this type of thing DOES happen. Not all the time. But it does weather the client is big or small and has no baring on how “right” we do things.
In the end such code is removed upon successful payment. But we have recovered thousands of dollars and many meals for our families by putting in such a safety net.
It’s like providing someone a car. If you do not pay for it. The loaner tries to recover. It is not ethical to keep the car you did not pay for. And it is unfair to the loaner. This is no different. Especially considering the hours developers can put into a project.
I feel much better putting in such code and not going broke over such abuse. However, it is clearly stated in our contractual agreement our services and products could be revoked / suspended due to non-payment.
Nick,
I agree – everyone would prefer not to resort to things like this. The unfortunate reality though is that some clients don't pay – I'm glad you haven't personally experienced it.
As I mentioned in the disclaimer in the post, any and all backdoor code should be removed as soon as a client has paid his final bill, and certainly before the site goes live.
Any technical measures are a safety net in case normal methods of recourse break down.
Niek, you're very naive. I've been at this twice as long as you have and guess what, one day you'll understand. No matter how brilliant you think you are at handling a client, sometimes they're just a loser and nothing you do will help. Services are withheld for lack of payment every day. Try stopping payment on your phone bill and see what happens. This is no different.
the idea of this killswitch is pretty nifty.
Nice job.
although you'll probably have their ftp info
and can just remove the unpaid for content.
any laws/regulations on digital content that is on a clients server?
that would be interesting to read up on
I have to admit I have often thought about implementing a “fail safe” policy like this but fortunately never really felt I had a need.
There is of course a number of obvious issues with having this sort of thing in your code:
1. Unless you “kill switch” actually removes some critical part (or all) of the application it could easily be enabled by anyone that was slightly tech-savy.
2. Implementing the “kill switch” to prevent it being enabled again could potentially leave a big security hole (there's ways around this of course).
2. If your client ever found out about the “malicious” code (whether it was used or not) it would cause massive problems.
Niek, you’re very naive. I’ve been at this twice as long as you have and guess what, one day you’ll understand. No matter how brilliant you think you are at handling a client, sometimes they’re just a loser and nothing you do will help. Services are withheld for lack of payment every day. Try stopping payment on your phone bill and see what happens. This is no different.rnrn
Naive, maybe. I’ve had bussines conflicts with clients, I’ve had difficulties with getting my money but I still got paid within a couple of months. rnrnI still maintain the opinion that when you do your stuff right and check your clients financial situation especially when you’re talking about large amounts of money. You won’t need something as unethical as this. Backdoors are bad programming practice. It’s comparable to rootkits or DRM. You can’t withdraw ownership from your client. It’s a matter of bussiness and people skill. I’m not saying that the chances are zero to encounter lousy clients. You can always ultimately resort to legal action (that is if you have legal proof, which also helps with negotiating payment ;))
Niek, nnYou mention it’s not good to withdraw ownership from your client; last time I checked you don’t own something until you’ve paid… this is where scripts like this come in useful.nnI have experienced a number of clients who, despite my doing a very professional job, have basically been con-artists and ripped me off. Including clients who have changed their FTP passwords. To this end I’ve written my own “time-bomb” script which I can use to remove MY files from my clients servers should I need to. Once the client has paid, I remove my time-bomb and the protection is removed.nnThe point being, until the client has paid, they do not own the files I have developed for them and therefore I have the right to do as I wish with MY files.nn
the idea of this killswitch is pretty nifty.rnNice job.rnrnalthough you’ll probably have their ftp infornand can just remove the unpaid for content.rnrn any laws/regulations on digital content that is on a clients server?rnthat would be interesting to read up on
I have to admit I have often thought about implementing a “fail safe” policy like this but fortunately never really felt I had a need.rnrnThere is of course a number of obvious issues with having this sort of thing in your code:rnrn1. Unless you “kill switch” actually removes some critical part (or all) of the application it could easily be enabled by anyone that was slightly tech-savy.rnrn2. Implementing the “kill switch” to prevent it being enabled again could potentially leave a big security hole (there’s ways around this of course).rnrn2. If your client ever found out about the “malicious” code (whether it was used or not) it would cause massive problems.
Agreed with the comments about this being unethical behaviour. If a client doesn't pay, it's probably due to bad project management, if it's not, then it's a matter for the law.
Agreed with the comments about this being unethical behaviour. If a client doesn’t pay, it’s probably due to bad project management, if it’s not, then it’s a matter for the law.
Well, Melbourne web design, what will be your next step when the law sides with the moneybags, and not you the web designer? This is common in my country, Nigeria.
Despite excellent project management, on-time delivery, signed agreements, some companies just love to owe.Bill, this killswitch is the answer to my worries. Thank you very much for sharing.
So if your server is down for some reason, all your clients's websites are down as well, asking for payment? way the go 🙂
So if your server is down for some reason, all your clients’s websites are down as well, asking for payment? way the go 🙂
If you’ll read in “Part One” of the tutorial, you’ll notice that the code is configured such that if it does not receive a response from your server, it will default to allowing the web app to run. It has to specifically receive the “halt” signal in order to disable the app. Thus, downtime on your end does not cause downtime on the client’s end.nnAgain I’d like to reiterate – the killswitch is a safety net in case negotiations with the client break down. You should remove it as soon as you’ve been paid.
Naive, maybe. I've had bussines conflicts with clients, I've had difficulties with getting my money but I still got paid within a couple of months.
I still maintain the opinion that when you do your stuff right and check your clients financial situation especially when you're talking about large amounts of money. You won't need something as unethical as this. Backdoors are bad programming practice. It's comparable to rootkits or DRM. You can't withdraw ownership from your client. It's a matter of bussiness and people skill. I'm not saying that the chances are zero to encounter lousy clients. You can always ultimately resort to legal action (that is if you have legal proof, which also helps with negotiating payment ;))
i dont personally agree with a killswitch but i understand why. what i do is i only host the site on my servers until the payment is in full. then i move it over.
on another note. the code should default to allowing the site to run if it takes too long to contact your site or the site is not available.
If you'll read in “Part One” of the tutorial, you'll notice that the code is configured such that if it does not receive a response from your server, it will default to allowing the web app to run. It has to specifically receive the “halt” signal in order to disable the app.
Again I'd like to reiterate – the killswitch is a safety net in case negotiations with the client break down. You should remove it as soon as you've been paid.
i dont personally agree with a killswitch but i understand why. what i do is i only host the site on my servers until the payment is in full. then i move it over. rnrnon another note. the code should default to allowing the site to run if it takes too long to contact your site or the site is not available.
So far I've had two instances where I had problems with the client paying me. Not because I didn't do my job well enough, not because I didn't deliver in time, but simply because said client changed his mind and demanded me to 'obey' him, or I wouldn't get my money. I have a similar piece of code (somewhat obfuscated in a file that appears and is in fact part of the rest of the website) that achieves this remote kill switch also. I normally never implement it, but for these two instances I added the code after the problems occurred, and I felt like I was going to loose the money *and* the work already delivered.
I hate to go this far, and luckily I never actually had to disable any website (the threat alone worked), but to me in these 'worst case scenarios' it makes me a feel a bit better knowing that they can't just change their FTP info and call it a day, without ever paying me.
That said, you might want to change the warning message to display a more general warning. Even though you only save this as a last resort, it would be much better if possible visitors don't see this warning of the client having to pay you (which could ruin their business), but instead show a more general, please contact support or the like message.
Oh, and it would also help to not let the code talk with your server at *every* load. Maybe do it like wordpress does it's version checks; only 2 times a day (and in wordpress' case, only the admin panel does the checks).
Thanks for the post!
-Dave
So far I’ve had two instances where I had problems with the client paying me. Not because I didn’t do my job well enough, not because I didn’t deliver in time, but simply because said client changed his mind and demanded me to ‘obey’ him, or I wouldn’t get my money. I have a similar piece of code (somewhat obfuscated in a file that appears and is in fact part of the rest of the website) that achieves this remote kill switch also. I normally never implement it, but for these two instances I added the code after the problems occurred, and I felt like I was going to loose the money *and* the work already delivered.rnrnI hate to go this far, and luckily I never actually had to disable any website (the threat alone worked), but to me in these ‘worst case scenarios’ it makes me a feel a bit better knowing that they can’t just change their FTP info and call it a day, without ever paying me. rnrnThat said, you might want to change the warning message to display a more general warning. Even though you only save this as a last resort, it would be much better if possible visitors don’t see this warning of the client having to pay you (which could ruin their business), but instead show a more general, please contact support or the like message.rnrnOh, and it would also help to not let the code talk with your server at *every* load. Maybe do it like wordpress does it’s version checks; only 2 times a day (and in wordpress’ case, only the admin panel does the checks).rnrnThanks for the post!rnrn-Dave
(1) PHP is uncompiled. (2) the code, such as it is, would disable the site in the event that YOUR server is unreachable. Not cool, not ethical and not terribly clever, either. How about a simple DDOS attack. Much more fun to engineer, anyway. 🙂
(1) PHP is uncompiled. (2) the code, such as it is, would disable the site in the event that YOUR server is unreachable. Not cool, not ethical and not terribly clever, either. How about a simple DDOS attack. Much more fun to engineer, anyway. 🙂
Interesting article. In order to protect yourself you may want to look into the legal issues more closely. At the very least I would suggest modifying your EULA or services agreement. to state that for licensing purposes software will validate itself against a license server to ensure that license is valid. In the event that license is not valid software may cease to function.
Interesting article. In order to protect yourself you may want to look into the legal issues more closely. At the very least I would suggest modifying your EULA or services agreement. to state that for licensing purposes software will validate itself against a license server to ensure that license is valid. In the event that license is not valid software may cease to function. rnrn
hahaha… that's really genius man 😀
thanks for that
hahaha… that’s really genius man :Drnthanks for that
@Van: That's SO slick!
@Van: That’s SO slick!
if the site has flash on the homepage, and top of every subpage, then you can simply have it load a swf from your server. If the swf isn't there, then nothing happens at all. If you have a client problem you can make the swf be whatever you want. It could be a link to your site, it could have a warning message, it could be just a few pixels for the client to notice.
if the site has flash on the homepage, and top of every subpage, then you can simply have it load a swf from your server. If the swf isn’t there, then nothing happens at all. If you have a client problem you can make the swf be whatever you want. It could be a link to your site, it could have a warning message, it could be just a few pixels for the client to notice.
I tried it, but it did not work.
The site continued to run!
I tried it, but it did not work.rnThe site continued to run!
I think this is nice! For those who disagree with this. I believe this is just a tutorail meant to highlight some of the uses of XML RPC. And of course there are different types of clients AND THERE ARE DIFFERENT TYPES OF SERVICES THAT CAN BE RENDERED WHICH COULD MAKE THIS INVALUABLE!
I think this is nice! For those who disagree with this. I believe this is just a tutorail meant to highlight some of the uses of XML RPC. And of course there are different types of clients AND THERE ARE DIFFERENT TYPES OF SERVICES THAT CAN BE RENDERED WHICH COULD MAKE THIS INVALUABLE!
I'm looking for a simular thing, only… I'd like to reverse it. The client 'activates' the application and than is able to use it. (The activation code is only send when the payment is done)
BTW it's pretty easy to have this 'kill switch' disabled… Just a minimal techie changes:
if (!$client->query('activation.checkapp', $appname)) {
if($client->getResponse() ) {
die(“Application Disabled. Please pay your web developer.”);
}
}
Into:
/*
if (!$client->query('activation.checkapp', $appname)) {
if($client->getResponse() ) {
die(“Application Disabled. Please pay your web developer.”);
}
}
*/
And the code for 'disabling' is changed into 'comment' and thus not executed…
Also changing the if (…) into if (false) and again it has no affect…
I’m looking for a simular thing, only… I’d like to reverse it. The client ‘activates’ the application and than is able to use it. (The activation code is only send when the payment is done)rnrnBTW it’s pretty easy to have this ‘kill switch’ disabled… Just a minimal techie changes:rnrnif (!(‘activation.checkapp’, )) {rntif(() ) {rnttdie(“Application Disabled. Please pay your web developer.”);rnt}rn}rnrnInto:rnrn/*rnif (!(‘activation.checkapp’, )) {rntif(() ) {rnttdie(“Application Disabled. Please pay your web developer.”);rnt}rn}rn*/rnrnAnd the code for ‘disabling’ is changed into ‘comment’ and thus not executed…rnrnAlso changing the if (…) into if (false) and again it has no affect…
Thanks! As a freelance web developer I’ve been looking for something like this for some time.rnrnI’ve had personal experience of client’s withholding payment for the full spectrum of possible reasons! In my opinion it is nice to have a kill switch option, but understand those that are worried by its ethical implications.rnrnI’ve posted my approach at http://ajaxkillswitch.comrnrnIt demonstrates a VERY simple technique that takes advantage of jQuery’s recently added cross-domain Ajax request functionality.rnrnThe advantage to the JavaScript Ajax kill switch is that it is independent of the server-side implementation. This makes it useful for even standard HTML websites.rnrnCombination of the two methods (server and client-side) could be doubly effective 😉
Thanks! As a freelance web developer I've been looking for something like this for some time.
I've had personal experience of client's withholding payment for the full spectrum of possible reasons! In my opinion it is nice to have a kill switch option, but understand those that are worried by its ethical implications.
I've posted my approach at http://ajaxkillswitch.com
It demonstrates a VERY simple technique that takes advantage of jQuery's recently added cross-domain Ajax request functionality.
The advantage to the JavaScript Ajax kill switch is that it is independent of the server-side implementation. This makes it useful for even standard HTML websites.
Combination of the two methods (server and client-side) could be doubly effective 😉
Hello, this seems usefull, but what about if the client gives de code source on his side to a developer that removes from the system the client code? Then our switch will loose the effect?rnThank you.
Hello, this seems usefull, but what about if the client gives de code source on his side to a developer that removes from the system the client code? Then our switch will loose the effect?
Thank you.
Niek,
You mention it's not good to withdraw ownership from your client; last time I checked you don't own something until you've paid… this is where scripts like this come in useful.
I have experienced a number of clients who, despite my doing a very professional job, have basically been con-artists and ripped me off. Including clients who have changed their FTP passwords. To this end I've written my own “time-bomb” script which I can use to remove MY files from my clients servers should I need to. Once the client has paid, I remove my time-bomb and the protection is removed.
The point being, until the client has paid, they do not own the files I have developed for them and therefore I have the right to do as I wish with MY files.
Niek,
You mention it's not good to withdraw ownership from your client; last time I checked you don't own something until you've paid… this is where scripts like this come in useful.
I have experienced a number of clients who, despite my doing a very professional job, have basically been con-artists and ripped me off. Including clients who have changed their FTP passwords. To this end I've written my own “time-bomb” script which I can use to remove MY files from my clients servers should I need to. Once the client has paid, I remove my time-bomb and the protection is removed.
The point being, until the client has paid, they do not own the files I have developed for them and therefore I have the right to do as I wish with MY files.
Something like this could be very handy if you have developed a digital product, such as a php application that is for sale, and the purchase was made, the application downloaded after payment, then the payment was charged back as a result of credit card fraud or other reason some weeks later. You could then disable the application for the fraudulent purchasers server, provided you collected the relevant details at the time of purchase. They shouldn’t get to use the application if they haven’t paid for it.
Something like this could be very handy if you have developed a digital product, such as a php application that is for sale, and the purchase was made, the application downloaded after payment, then the payment was charged back as a result of credit card fraud or other reason some weeks later. You could then disable the application for the fraudulent purchasers server, provided you collected the relevant details at the time of purchase. They shouldn't get to use the application if they haven't paid for it.
Yes, This is sometimes really needed one!nBut, if the client approaches some other PHP developer, then he/she can locate this code and possibly remove the code.nnWhat i have done once is, just create a “info.php” file and put some message in it under the variable name “” or something.; after that, do this:nnif(md5(md5())==’5d41402abc4b2a76b9719d911017c592′) {nnNote that I haven’t closed the brace opened.nn Then include it in “index.php”nnAfter that I will write all the HTML codes, CSS, and other includes. The index.php will include many other PHP files, and it may go into 3 or 4 levels of include. And I will put the closing brace for the above code somewhere in the include files, just mimicking like a for-loop close brace.nnNow, If they edit the variable , then MD5 changes, thus no-output! OK, they may change the condition in the if-condition. So I will write a complex set of 3-4 if-conditions.nnThen, if they remove the if-condition, then the closing brace throws an ERROR.nnProbably, after a set of trial-and-error, the new developer will go away…!nnThe real idea is in the MD5 and the BRACES BALANCING.
Hi, just an update on my previous Ajax killswitch post. Version 2, which is a bit smarter is now written up.nnhttp://menacingcloud.com/?c=ajaxKillSwitch2nnThanks!
Yes, This is sometimes really needed one!
But, if the client approaches some other PHP developer, then he/she can locate this code and possibly remove the code.
What i have done once is, just create a “info.php” file and put some message in it under the variable name “$my_msg” or something.; after that, do this:
if(md5(md5($my_msg))=='5d41402abc4b2a76b9719d911017c592') {
Note that I haven't closed the brace opened.
Then include it in “index.php”
After that I will write all the HTML codes, CSS, and other includes. The index.php will include many other PHP files, and it may go into 3 or 4 levels of include. And I will put the closing brace for the above code somewhere in the include files, just mimicking like a for-loop close brace.
Now, If they edit the variable $my_msg, then MD5 changes, thus no-output! OK, they may change the condition in the if-condition. So I will write a complex set of 3-4 if-conditions.
Then, if they remove the if-condition, then the closing brace throws an ERROR.
Probably, after a set of trial-and-error, the new developer will go away…!
The real idea is in the MD5 and the BRACES BALANCING.
Hi, just an update on my previous Ajax killswitch post. Version 2, which is a bit smarter is now written up.
http://menacingcloud.com/?c=ajaxKillSwitch2
Thanks!
[…] solution: a remote kill switch, which gives web designers a back door into a client website via PHP, AJAX or CSS to disable it in case something goes wrong, i.e., one doesn’t get […]
GENIUSSSSSSSSSSSSSSSSSSSSSS! thank youuuuu!!!!
GENIUSSSSSSSSSSSSSSSSSSSSSS! thank youuuuu!!!!
It seems that the existence of this code should be a part of your ‘standard’ agreement … agreed to by the client … before work begins. If they won’t agree to it, either don’t start or take the chance and don’t include the code. Business is about managing risks. Use good judgment and manage this one.nnIn this case, you’ll have to more finely arrange the deliverable / payment schedule so there is a dramatically reduced possibility of you being left to flap in the breeze. nnThe reason I say this is because of the legalities concerning disabling code on some else’s computer. I’m pretty certain that this is frowned on. If they simply change your password and this code fires off, you have circumvented their security. Right? nnIn fact, that is the precise purpose of this code. nnI can see a web developer or two doing a slow roast on the spit of justice. nnDocument, document, document, sue. nnBut don’t break the law or you’ll not only end up not getting paid for this work, but you’ll lose out on future work while you are in the can and for a long time afterward.nnBe careful, kids; it’s a jungle out there.
Instead of selling your code you should consider providing a license. With a license you can maintain full control over your work and ability to revoke, suspend it at will.nnAfter many years of coding I have managed to accumulate a sizable code library. I always provide a software license. If asked, I tell them my many years of experience, the library and why I license. By reusing code I can also work faster, cheaper with solid results. nnAs more time passes, the less inclined someone is to pay. There is nothing unethical about suspending a site as long as it is part of the contract. I am currently dealing with a client that is 2-weeks late on his bill. Not all clients are honest so I prefer to be prepared just in case. 30 days overdue is my limit.
It seems that the existence of this code should be a part of your 'standard' agreement … agreed to by the client … before work begins. If they won't agree to it, either don't start or take the chance and don't include the code. Business is about managing risks. Use good judgment and manage this one.
In this case, you'll have to more finely arrange the deliverable / payment schedule so there is a dramatically reduced possibility of you being left to flap in the breeze.
The reason I say this is because of the legalities concerning disabling code on some else's computer. I'm pretty certain that this is frowned on. If they simply change your password and this code fires off, you have circumvented their security. Right?
In fact, that is the precise purpose of this code.
I can see a web developer or two doing a slow roast on the spit of justice.
Document, document, document, sue.
But don't break the law or you'll not only end up not getting paid for this work, but you'll lose out on future work while you are in the can and for a long time afterward.
Be careful, kids; it's a jungle out there.
Instead of selling your code you should consider providing a license. With a license you can maintain full control over your work and ability to revoke, suspend it at will.
After many years of coding I have managed to accumulate a sizable code library. I always provide a software license. If asked, I tell them my many years of experience, the library and why I license. By reusing code I can also work faster, cheaper with solid results.
As more time passes, the less inclined someone is to pay. There is nothing unethical about suspending a site as long as it is part of the contract. I am currently dealing with a client that is 2-weeks late on his bill. Not all clients are honest so I prefer to be prepared just in case. 30 days overdue is my limit.
It took me a long time to get this to work successfully. The only way it would function is if I remove the exclamation mark in the client code on line 4:nnBefore:n if (!…nAfter:n if (…nnI am not sure why this works. Could you please advise if this a suitable fix?
It took me a long time to get this to work successfully. The only way it would function is if I remove the exclamation mark in the client code on line 4:nnBefore:n if (!…nAfter:n if (…nnI am not sure why this works. Could you please advise if this a suitable fix?
I know this is a long time ago, but thanks for that! I couldn’t figure it out either but that did it.
One suggestion:nnThe action which happens once the app is enabled is determined on the client side:nndie(“Application Disabled. Please pay your web developer.”);nnI think this action should be moved to the server side. It would give the developer more control over the action.
One suggestion:nnThe action which happens once the app is enabled is determined on the client side:nndie(“Application Disabled. Please pay your web developer.”);nnI think this action should be moved to the server side. It would give the developer more control over the action.
doesnt CSS have a killswitch like this too?
Yes, you can also accomplish this with CSS. Checkout the tutorial here: http://csskillswitch.com/
Thank you for taking the time to create this! I’ve got a situation where I am writing code on a client’s server and there is a chance that once I’m done, he may change the passwords(I don’t know him well, and the project is comission based), so this is perfect for my situation. I know you have come under fire for this, but I wanted to express my appreciation for your time 😀
Thanks for the kind words – glad I was able to help 🙂
Excellent! I had already written something similar myself several years ago that also incorporates unique serial key checking and application / module updates and version control.
My new employer is using it to handle User Authentication over the new CMS I have written for them – although many other PHP developers are looking down on me for attempting to lock down the ‘Open Source’ PHP!
Hi, what if they live in China and pay their bill with a credit card, but then they do a charge back? If you remove the code after they pay, then what is the use if they do a charge back?
Robert – obviously you shouldn’t remove the code until you have the funds secured. Still, you can never be fully protected if someone is actively trying to defraud you – in that case, you should take it up with your credit card processor.
Or you could just keep the code on your own server until they pay.
Hei.
This code i just not working for me.
I tried it like 100 times now and still it work normally like this code doesn’t even exist.
But when i use the stupid method: if (file_get_contents(“http://mydomain.com/kill.txt”)) die(“kill message”); and put one character in the kill.txt on http://mydomain.com/kill.txt the site stop running as i would want this to do.
Just this code is not doing it. Maybe any suggestions?