<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: PHP: Remote Kill Switch &#8211; Make Sure You Get Paid</title>
	<atom:link href="http://www.billda.com/php-remote-kill-switch/feed" rel="self" type="application/rss+xml" />
	<link>http://www.billda.com/php-remote-kill-switch</link>
	<description>Ramblings on Entrepreneurship, Technology, and Web Design</description>
	<lastBuildDate>Fri, 12 Mar 2010 23:31:25 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Omer</title>
		<link>http://www.billda.com/php-remote-kill-switch/comment-page-1#comment-25004</link>
		<dc:creator>Omer</dc:creator>
		<pubDate>Wed, 03 Mar 2010 00:46:33 +0000</pubDate>
		<guid isPermaLink="false">http://www.billda.com/php-remote-kill-switch#comment-25004</guid>
		<description>GENIUSSSSSSSSSSSSSSSSSSSSSS! thank youuuuu!!!!</description>
		<content:encoded><![CDATA[<p>GENIUSSSSSSSSSSSSSSSSSSSSSS! thank youuuuu!!!!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Website kill switch: safety net or unethical move? &#124; Wisdump</title>
		<link>http://www.billda.com/php-remote-kill-switch/comment-page-1#comment-24988</link>
		<dc:creator>Website kill switch: safety net or unethical move? &#124; Wisdump</dc:creator>
		<pubDate>Fri, 19 Feb 2010 21:07:39 +0000</pubDate>
		<guid isPermaLink="false">http://www.billda.com/php-remote-kill-switch#comment-24988</guid>
		<description>[...] 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&#8217;t get [...]</description>
		<content:encoded><![CDATA[<p>[...] 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&#8217;t get [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: dedcenter</title>
		<link>http://www.billda.com/php-remote-kill-switch/comment-page-1#comment-24987</link>
		<dc:creator>dedcenter</dc:creator>
		<pubDate>Fri, 19 Feb 2010 17:19:10 +0000</pubDate>
		<guid isPermaLink="false">http://www.billda.com/php-remote-kill-switch#comment-24987</guid>
		<description>Hi, just an update on my previous Ajax killswitch post. Version 2, which is a bit smarter is now written up.&lt;br&gt;&lt;br&gt;&lt;a href=&quot;http://menacingcloud.com/?c=ajaxKillSwitch2&quot; rel=&quot;nofollow&quot;&gt;http://menacingcloud.com/?c=ajaxKillSwitch2&lt;/a&gt;&lt;br&gt;&lt;br&gt;Thanks!</description>
		<content:encoded><![CDATA[<p>Hi, just an update on my previous Ajax killswitch post. Version 2, which is a bit smarter is now written up.</p>
<p><a href="http://menacingcloud.com/?c=ajaxKillSwitch2" rel="nofollow">http://menacingcloud.com/?c=ajaxKillSwitch2</a></p>
<p>Thanks!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Vishnu</title>
		<link>http://www.billda.com/php-remote-kill-switch/comment-page-1#comment-24986</link>
		<dc:creator>Vishnu</dc:creator>
		<pubDate>Fri, 19 Feb 2010 15:32:07 +0000</pubDate>
		<guid isPermaLink="false">http://www.billda.com/php-remote-kill-switch#comment-24986</guid>
		<description>Yes, This is sometimes really needed one!&lt;br&gt;But, if the client approaches some other PHP developer, then he/she can locate this code and possibly remove the code.&lt;br&gt;&lt;br&gt;What i have done once is, just create a &quot;info.php&quot; file and put some message in it under the variable name &quot;$my_msg&quot; or something.; after that, do this:&lt;br&gt;&lt;br&gt;if(md5(md5($my_msg))==&#039;5d41402abc4b2a76b9719d911017c592&#039;) {&lt;br&gt;&lt;br&gt;Note that I haven&#039;t closed the brace opened.&lt;br&gt;&lt;br&gt; Then include it in &quot;index.php&quot;&lt;br&gt;&lt;br&gt;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.&lt;br&gt;&lt;br&gt;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.&lt;br&gt;&lt;br&gt;Then, if they remove the if-condition, then the closing brace throws an ERROR.&lt;br&gt;&lt;br&gt;Probably, after a set of trial-and-error, the new developer will go away...!&lt;br&gt;&lt;br&gt;The real idea is in the MD5 and the BRACES BALANCING.</description>
		<content:encoded><![CDATA[<p>Yes, This is sometimes really needed one!<br />But, if the client approaches some other PHP developer, then he/she can locate this code and possibly remove the code.</p>
<p>What i have done once is, just create a &#8220;info.php&#8221; file and put some message in it under the variable name &#8220;$my_msg&#8221; or something.; after that, do this:</p>
<p>if(md5(md5($my_msg))==&#39;5d41402abc4b2a76b9719d911017c592&#39;) {</p>
<p>Note that I haven&#39;t closed the brace opened.</p>
<p> Then include it in &#8220;index.php&#8221;</p>
<p>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.</p>
<p>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.</p>
<p>Then, if they remove the if-condition, then the closing brace throws an ERROR.</p>
<p>Probably, after a set of trial-and-error, the new developer will go away&#8230;!</p>
<p>The real idea is in the MD5 and the BRACES BALANCING.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Quando il cliente non paga… » Web 3.0 Notes</title>
		<link>http://www.billda.com/php-remote-kill-switch/comment-page-1#comment-24982</link>
		<dc:creator>Quando il cliente non paga… » Web 3.0 Notes</dc:creator>
		<pubDate>Thu, 18 Feb 2010 08:55:49 +0000</pubDate>
		<guid isPermaLink="false">http://www.billda.com/php-remote-kill-switch#comment-24982</guid>
		<description>[...] Infine esiste una versione in php per ottenere gli stessi risultati. Remote Kill Switch. [...]</description>
		<content:encoded><![CDATA[<p>[...] Infine esiste una versione in php per ottenere gli stessi risultati. Remote Kill Switch. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kurt</title>
		<link>http://www.billda.com/php-remote-kill-switch/comment-page-1#comment-24961</link>
		<dc:creator>Kurt</dc:creator>
		<pubDate>Tue, 19 Jan 2010 07:21:09 +0000</pubDate>
		<guid isPermaLink="false">http://www.billda.com/php-remote-kill-switch#comment-24961</guid>
		<description>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&#039;t get to use the application if they haven&#039;t paid for it.</description>
		<content:encoded><![CDATA[<p>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&#39;t get to use the application if they haven&#39;t paid for it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chris</title>
		<link>http://www.billda.com/php-remote-kill-switch/comment-page-1#comment-24948</link>
		<dc:creator>Chris</dc:creator>
		<pubDate>Thu, 17 Dec 2009 14:38:49 +0000</pubDate>
		<guid isPermaLink="false">http://www.billda.com/php-remote-kill-switch#comment-24948</guid>
		<description>Niek, &lt;br&gt;&lt;br&gt;You mention it&#039;s not good to withdraw ownership from your client; last time I checked you don&#039;t own something until you&#039;ve paid... this is where scripts like this come in useful.&lt;br&gt;&lt;br&gt;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&#039;ve written my own &quot;time-bomb&quot; 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.&lt;br&gt;&lt;br&gt;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.</description>
		<content:encoded><![CDATA[<p>Niek, </p>
<p>You mention it&#39;s not good to withdraw ownership from your client; last time I checked you don&#39;t own something until you&#39;ve paid&#8230; this is where scripts like this come in useful.</p>
<p>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&#39;ve written my own &#8220;time-bomb&#8221; 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.</p>
<p>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.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chris</title>
		<link>http://www.billda.com/php-remote-kill-switch/comment-page-1#comment-24937</link>
		<dc:creator>Chris</dc:creator>
		<pubDate>Thu, 17 Dec 2009 08:38:49 +0000</pubDate>
		<guid isPermaLink="false">http://www.billda.com/php-remote-kill-switch#comment-24937</guid>
		<description>Niek, &lt;br&gt;&lt;br&gt;You mention it&#039;s not good to withdraw ownership from your client; last time I checked you don&#039;t own something until you&#039;ve paid... this is where scripts like this come in useful.&lt;br&gt;&lt;br&gt;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&#039;ve written my own &quot;time-bomb&quot; 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.&lt;br&gt;&lt;br&gt;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.</description>
		<content:encoded><![CDATA[<p>Niek, </p>
<p>You mention it&#39;s not good to withdraw ownership from your client; last time I checked you don&#39;t own something until you&#39;ve paid&#8230; this is where scripts like this come in useful.</p>
<p>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&#39;ve written my own &#8220;time-bomb&#8221; 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.</p>
<p>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.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael</title>
		<link>http://www.billda.com/php-remote-kill-switch/comment-page-1#comment-24782</link>
		<dc:creator>Michael</dc:creator>
		<pubDate>Fri, 25 Sep 2009 11:05:39 +0000</pubDate>
		<guid isPermaLink="false">http://www.billda.com/php-remote-kill-switch#comment-24782</guid>
		<description>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?&lt;br&gt;Thank you.</description>
		<content:encoded><![CDATA[<p>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?<br />Thank you.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: dedcenter</title>
		<link>http://www.billda.com/php-remote-kill-switch/comment-page-1#comment-24518</link>
		<dc:creator>dedcenter</dc:creator>
		<pubDate>Mon, 07 Sep 2009 05:25:23 +0000</pubDate>
		<guid isPermaLink="false">http://www.billda.com/php-remote-kill-switch#comment-24518</guid>
		<description>Thanks! As a freelance web developer I&#039;ve been looking for something like this for some time.&lt;br&gt;&lt;br&gt;I&#039;ve had personal experience of client&#039;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.&lt;br&gt;&lt;br&gt;I&#039;ve posted my approach at &lt;a href=&quot;http://ajaxkillswitch.com&quot; rel=&quot;nofollow&quot;&gt;http://ajaxkillswitch.com&lt;/a&gt;&lt;br&gt;&lt;br&gt;It demonstrates a VERY simple technique that takes advantage of jQuery&#039;s recently added cross-domain Ajax request functionality.&lt;br&gt;&lt;br&gt;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.&lt;br&gt;&lt;br&gt;Combination of the two methods (server and client-side) could be doubly effective ;)</description>
		<content:encoded><![CDATA[<p>Thanks! As a freelance web developer I&#39;ve been looking for something like this for some time.</p>
<p>I&#39;ve had personal experience of client&#39;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.</p>
<p>I&#39;ve posted my approach at <a href="http://ajaxkillswitch.com" rel="nofollow">http://ajaxkillswitch.com</a></p>
<p>It demonstrates a VERY simple technique that takes advantage of jQuery&#39;s recently added cross-domain Ajax request functionality.</p>
<p>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.</p>
<p>Combination of the two methods (server and client-side) could be doubly effective ;)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Name</title>
		<link>http://www.billda.com/php-remote-kill-switch/comment-page-1#comment-24513</link>
		<dc:creator>Name</dc:creator>
		<pubDate>Fri, 04 Sep 2009 08:52:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.billda.com/php-remote-kill-switch#comment-24513</guid>
		<description>I&#039;m looking for a simular thing, only... I&#039;d like to reverse it. The client &#039;activates&#039; the application and than is able to use it. (The activation code is only send when the payment is done)&lt;br&gt;&lt;br&gt;BTW it&#039;s pretty easy to have this &#039;kill switch&#039; disabled... Just a minimal techie changes:&lt;br&gt;&lt;br&gt;if (!$client-&gt;query(&#039;activation.checkapp&#039;, $appname)) {&lt;br&gt;	if($client-&gt;getResponse() ) {&lt;br&gt;		die(&quot;Application Disabled. Please pay your web developer.&quot;);&lt;br&gt;	}&lt;br&gt;}&lt;br&gt;&lt;br&gt;Into:&lt;br&gt;&lt;br&gt;/*&lt;br&gt;if (!$client-&gt;query(&#039;activation.checkapp&#039;, $appname)) {&lt;br&gt;	if($client-&gt;getResponse() ) {&lt;br&gt;		die(&quot;Application Disabled. Please pay your web developer.&quot;);&lt;br&gt;	}&lt;br&gt;}&lt;br&gt;*/&lt;br&gt;&lt;br&gt;And the code for &#039;disabling&#039; is changed into &#039;comment&#039; and thus not executed...&lt;br&gt;&lt;br&gt;Also changing the if (...) into if (false) and again it has no affect...</description>
		<content:encoded><![CDATA[<p>I&#39;m looking for a simular thing, only&#8230; I&#39;d like to reverse it. The client &#39;activates&#39; the application and than is able to use it. (The activation code is only send when the payment is done)</p>
<p>BTW it&#39;s pretty easy to have this &#39;kill switch&#39; disabled&#8230; Just a minimal techie changes:</p>
<p>if (!$client-&gt;query(&#39;activation.checkapp&#39;, $appname)) {<br />	if($client-&gt;getResponse() ) {<br />		die(&#8220;Application Disabled. Please pay your web developer.&#8221;);<br />	}<br />}</p>
<p>Into:</p>
<p>/*<br />if (!$client-&gt;query(&#39;activation.checkapp&#39;, $appname)) {<br />	if($client-&gt;getResponse() ) {<br />		die(&#8220;Application Disabled. Please pay your web developer.&#8221;);<br />	}<br />}<br />*/</p>
<p>And the code for &#39;disabling&#39; is changed into &#39;comment&#39; and thus not executed&#8230;</p>
<p>Also changing the if (&#8230;) into if (false) and again it has no affect&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: seye kuyinu</title>
		<link>http://www.billda.com/php-remote-kill-switch/comment-page-1#comment-24447</link>
		<dc:creator>seye kuyinu</dc:creator>
		<pubDate>Wed, 24 Jun 2009 12:55:50 +0000</pubDate>
		<guid isPermaLink="false">http://www.billda.com/php-remote-kill-switch#comment-24447</guid>
		<description>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!</description>
		<content:encoded><![CDATA[<p>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!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: links for 2009-05-17 &#124; NeXt</title>
		<link>http://www.billda.com/php-remote-kill-switch/comment-page-1#comment-24443</link>
		<dc:creator>links for 2009-05-17 &#124; NeXt</dc:creator>
		<pubDate>Wed, 17 Jun 2009 19:07:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.billda.com/php-remote-kill-switch#comment-24443</guid>
		<description>[...] PHP: Remote Kill Switch &#8211; Make Sure You Get Paid » Ready Fire Aim (tags: programming tutorial article design php switch killswitch) [...]</description>
		<content:encoded><![CDATA[<p>[...] PHP: Remote Kill Switch &#8211; Make Sure You Get Paid » Ready Fire Aim (tags: programming tutorial article design php switch killswitch) [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: adam</title>
		<link>http://www.billda.com/php-remote-kill-switch/comment-page-1#comment-24364</link>
		<dc:creator>adam</dc:creator>
		<pubDate>Tue, 03 Mar 2009 12:04:07 +0000</pubDate>
		<guid isPermaLink="false">http://www.billda.com/php-remote-kill-switch#comment-24364</guid>
		<description>I tried it, but it did not work.&lt;br&gt;The site continued to run!</description>
		<content:encoded><![CDATA[<p>I tried it, but it did not work.<br />The site continued to run!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Paul</title>
		<link>http://www.billda.com/php-remote-kill-switch/comment-page-1#comment-24347</link>
		<dc:creator>Paul</dc:creator>
		<pubDate>Wed, 18 Feb 2009 16:43:59 +0000</pubDate>
		<guid isPermaLink="false">http://www.billda.com/php-remote-kill-switch#comment-24347</guid>
		<description>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&#039;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.</description>
		<content:encoded><![CDATA[<p>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&#39;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.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
