Re: Web Application authentication
WoW! That software costs a lot of money. SourceGuardian does the same for a fraction of that cost. I guess it is a possibility that Zend's product is better than Source Guardian's. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
Re: Web Application authentication
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zend has a small business discount program that covers Zend Guard: http://www.zend.com/store/software/zend_small_business_program Jon Bennett wrote: >> First post! > > welcome! > >> Okay, what about this: >> Make a key file on the client server with an expiration date encoded in the >> key. >> Have your program check the key's expiration date every time it runs >> When the key expires, call a page on your site to get a new key with a new >> expiration date. >> That way, their site only calls yours once a month. Just don't make the key >> encoding obvious! > > also like it. > > could you not Zend Guard just this part of the app, and bury it so > it's not obvious. > > jb > - -- 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 iD8DBQFFCsKtKpzEXPWA4IcRAqrNAJ0V96CkRzPL+D0HKNoOoNIXIt80RwCfa1GB wMM3by8agR9G1qeDOBDCLZg= =zG6/ -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 cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
Re: Web Application authentication
> First post! welcome! > Okay, what about this: > Make a key file on the client server with an expiration date encoded in the > key. > Have your program check the key's expiration date every time it runs > When the key expires, call a page on your site to get a new key with a new > expiration date. > That way, their site only calls yours once a month. Just don't make the key > encoding obvious! also like it. could you not Zend Guard just this part of the app, and bury it so it's not obvious. jb -- jon bennett t: +44 (0) 1225 341 039 w: http://www.jben.net/ iChat (AIM): jbendotnet Skype: jon-bennett --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
Re: Web Application authentication
I like it. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
Re: Web Application authentication
First post! Okay, what about this: Make a key file on the client server with an expiration date encoded in the key. Have your program check the key's expiration date every time it runs When the key expires, call a page on your site to get a new key with a new expiration date. That way, their site only calls yours once a month. Just don't make the key encoding obvious! Eric On 9/14/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: No I am not Zend Guarding it. But the people that I am installing thisapplication for don't understand HTML much less PHP and CakePHP at that. It is just that I need some method to ensure that they don'tchange passwords to their FTP server on me and stop paying and areallowed to keep using the program. Hard to make a product to competein a market that has hosted pay by month solutions if I don't offer pay by month solution as well.So, I realy like the authentication since if they removed it it won'twork, but I think for my case maybe the lysine deficiency is best.Any more thoughts? AD7Six? Nate? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
Re: Web Application authentication
The serial number verification seems like a good idea, as long as you can ensure that buyers and friends-of-buyers aren't inclined to hack it. However, I've always been more a fan of a business model that invloves (a) some or all of the software being hosted and/or (b) keeping customers dependent on you for some kind of updates, be it updates to the code itself, or some kind of data that the application depends on (i.e. a zipcode database in a mailing application). Also, people are always more inclined to pay monthly fees for an application if they know it's being continually improved, especially if their feedback is taken into consideration in that improvement. People take a sense of ownership and actual investment in the project, rather than it being simply a tool that they pay to use. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
Re: Web Application authentication
No I am not Zend Guarding it. But the people that I am installing this application for don't understand HTML much less PHP and CakePHP at that. It is just that I need some method to ensure that they don't change passwords to their FTP server on me and stop paying and are allowed to keep using the program. Hard to make a product to compete in a market that has hosted pay by month solutions if I don't offer pay by month solution as well. So, I realy like the authentication since if they removed it it won't work, but I think for my case maybe the lysine deficiency is best. Any more thoughts? AD7Six? Nate? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
Re: Web Application authentication
-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 cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
Web Application authentication
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? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~--~~~~--~~--~--~---
