NYCPHP Meetup

[inforequest]

I have used Zen and ionCube on small-scale projects, and I can add:

Consider your vendor in light of your support needs - how much do you 
provide and how much do your customers need. If you will be doing the 
server setup/config then maybe there's no issue, but if the customer has 
to accomodate your use of Zend or ionCube then you may want to consider 
how each of those vendors handles inquiries (since they now become a 
contributor to your companies customer satisfaction quotient). Last 
thing you need is a great product that gets a bad rep because your 
encoder vendor had some compatibility issues.

When I was using ionCube there were some issues with the order in which 
ionCube and Zend extensions were to be installed, and when I used Zend 
there were some additional issues as well related to other products in 
use on the same server. It got messy when the customer moved from dev to 
production servers, especially.  I handled the Zend issues with Zend 
support (they responded very well) and handled the ionCube stuff via 
Internet searches. In then end my solution was dependent on end-user 
server configuration -- something to be aware of. That was a year ago.

I would recommend tying the product to domain name instead of IP. Makes 
for fewer support calls and customer inquiries (change of DNS doesn't 
require support), and perhaps most importantly ties integrity to a 
brand. IMHO companies are less inclined to try beating it  when their 
brand name may be compromised/banned. There may be security issues of 
which I am not attuned that make IP a better choice.

I would also recommend you encode only choice parts using a modular 
approach, perhaps only encoding parts that tie to IP or domain, and then 
a few random bits for obfuscation. This deters the casual cracker, and 
occupies the  determined infringer. Not sure how it plays into 
performance though.

IMHO the  Zend  solution is more likely to need an update when the Zend 
suite is updated, while the ionCube product is more stand-alone (and 
perhaps may be a better value if you only need a perpetual license for 
the encoder).

Finally I have noticed alot of back and forth banter in vendor pre-sale 
forums when encoding is part of the solution, related to how it is used, 
how it effects portability (the IP vs. Domain name thing), who supports 
the server config, etc. If you make it clear that you use encoding, 
perhaps provide sufficient info up front about how it is used or you may 
end up increasing your pre-sale support costs.

-=john

Daniel Kushner nyphp-at-websapp.com |nyphp 04/2004| wrote:

>Warning: I work for Zend Technologies !
>
>
>The Zend SafeGuard Suite includes the Encoder and licensing software
>all-in-one.
>
>http://www.zend.com/store/products/zend-safeguard-suite.php
>
>Zend enjoys giving New York PHP discounts. You can contact me off list if
>you're interested ;)
>
>Best,
>Daniel Kushner
>
>
>  
>
>>-----Original Message-----
>>From: talk-bounces at lists.nyphp.org 
>>[mailto:talk-bounces at lists.nyphp.org] On Behalf Of Dan Cech
>>Sent: Thursday, May 20, 2004 13:06
>>To: NYPHP Talk
>>Subject: [nycphp-talk] PHP License Management
>>
>>Hi all,
>>
>>I've been asked to come up with a licensing solutions for a 
>>closed-source php application, and wondered if anyone had any advice.
>>
>>The application will be licensed either in perpetuity or on a 
>>subscription basis, and each license will be tied to a 
>>particular server to make unauthorised distribution more difficult.
>>
>>The idea I came up with was to create a server app where the 
>>user could log in and view/purchase/extend licenses and 
>>manage the IP address(es) each license is tied to.
>>
>>The 'license' itself would be an encrypted token containing 
>>the client id, expiry date, ip address(es) etc signed with a 
>>private key.
>>
>>The actual software would then be encoded to protect the source from
>>(casual) prying eyes (I was thinking of using the Turck 
>>MMCache encoder for this) and include code to check the 
>>license validity and take appropriate action.
>>
>>The most obvious (to me) attack on the system is to 
>>reverse-engineer the code and remove the license check, which 
>>could be mitigated somewhat be encoding the entire app and 
>>'hiding' the check within the code.
>>
>>It seems to me like a viable solution, but I'm no security 
>>expert and would appreciate any and all comments or pointers 
>>to existing solutions.
>>
>>Dan
>>
>>_______________________________________________
>>talk mailing list
>>talk at lists.nyphp.org
>>http://lists.nyphp.org/mailman/listinfo/talk
>>
>>
>>
>>    
>>
>
>
>_______________________________________________
>talk mailing list
>talk at lists.nyphp.org
>http://lists.nyphp.org/mailman/listinfo/talk
>
>  
>