-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [EMAIL PROTECTED] wrote: > I have this brilliant idea and wanted to confirm it's brilliance. In > looking at the Paypal IPN I notice they use fgets and fputs to send > HTML posts. I had forgotten about this since starting CakePHP, but am > renewed by the possibilities. > > What I am thinking is that each time I install my application that I > give it a unique serial number stored as a globally defined variable. > Then, when the application is first called (and it can cache the result > for a time period) it would make a fput \ fget to my server running a > CakePHP verification application. I would have tables of the uniqueids > and be able to keep them in good standing or not good standing. If not > in good standing, the return would effectively disable the application > from running. > > Does this seem workable? What are possible hiccups (other than > sometimes the fputs and fgets may not work so I would have to work in > some kind of grace mechanism. > > The reason I am thinking this is the one time cost of $300 seems crazy > to people, but if I could set them up on monthly payments and still > install the application I think I would get more people. So, this > verification application would serve to disable the program if at > anytime they stopped payment. > > Or conversly, would it be better to make a method that I could run via > an URL that would immediately disable their application. Something > whereby I would have to login to an account that I have on all > installations, run it, and disable their program until they paid. Is > this more logical? >
Are you Zend Guard'ing the source code for the application? What's to keep a customer from removing the code that implements the software lysine deficiency on their end? I considered this factor several years ago when I implemented a payment system in Perl that did some creation of XML data before sending info to the credit card processor. My answer to the question was to move a large portion of the application code to my server, which I then called via XML-RPC, and which I released and installed on the client's server once the client paid (which they did). This way, the client could not remove the call-home functionality because calling-home was the only way the app could function properly. This however, added another layer through which semi-sensitive data had to travel (not credit card numbers, but unique identifiers that related customers to items they selected for purchase). It also created a dependency on the stability of my systems, which is okay if one can ensure that stability. There is debate as to the utility and legality (in certain instances) of software lysine deficiencies. IANAL, obviously, but perhaps you can get away with it as long as it's noted in your license agreement that you reserve the right to disable application functionality for non-payment. This sort of scheme seems more feasible, and poses less of a security vulnerability, than having an account on each installation which you must login to to disable the application. Good luck, Darian - -- Darian Anthony Patrick <[EMAIL PROTECTED]> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFCYFyKpzEXPWA4IcRAtWXAJoCLhrueskAu7nTD/sz62f31TdjeACdG/Xt DubparcuuggCqKwp8oLHrGY= =DlnC -----END PGP SIGNATURE----- --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~----------~----~----~----~------~----~------~--~---
