SitePoint Sponsor

User Tag List

Page 3 of 3 FirstFirst 123
Results 51 to 64 of 64
  1. #51
    SitePoint Wizard triexa's Avatar
    Join Date
    Dec 2002
    Location
    Canada
    Posts
    2,476
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by RichardAnderson
    Well. I purchase alot of php scripts, and if i find that one is encoded before i buy it (and there asking the world for it!) i will not purchase it. I love to be able to learn from the code and edit the code so it suits my needs even better. If your going to offer an encoded version, make sure for double the price of the encoded version you offer an unencoded version, that sometimes helps.
    What do you consider a "very high price" for a PHP application you would consider? That was encoded... that gave you 99% source code?
    AskItOnline.com - Need answers? Ask it online.
    Create powerful online surveys with ease in minutes!
    Sign up for your FREE account today!
    Follow us on Twitter

  2. #52
    SitePoint Wizard triexa's Avatar
    Join Date
    Dec 2002
    Location
    Canada
    Posts
    2,476
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Olate
    To encode or not to encode is a difficult question. The philosophy behind PHP is open and usable by all, but that doesn't always go alongside commercial goals. When releasing a product, you have to decide how much you want to allow the customer to do with your product. If you encode 100% of your source code, although you will be protecting your work, the customer will not be able to make any changes to adapt the product, which is something that I do often. However if you compare PHP applications to those written in VB or C++, for example, you usually do not get any access to the VB/C++ source so why should it be any different for PHP products?

    With our commercial products, we decided to take the route of providing access to certain parts of the source (the payment gateway modules and templates for example) but also offering a "Developer Version" which provides 99% source code. This means that some of the important parts of our products can be customised by any license holder, but there is also a way for those who want to really customise the source to do so. With our developer license, the only file encoded is the one which handles the licensing of the product (which cannot be removed otherwise the admin panel stops working!).

    Another option that we use is to provide source code documentation (using phpDoc) and two APIs. This means that application functions can be used without seeing the source code and seems to have been a good selling point for our software.

    On the same note, providing source code is a good selling point. Quite a few of our customers like the fact that we provide (or at least provide the option) to get the source code should they need it. We're also very flexible when it comes to customers who didn't purchase the developer version asking for access to specific files - something which I would find useful if I needed to customise an encoded application.

    When we released our first product, and up until very recently, we have only used the ionCube encoder. We only just started offering the Zend Encoded version because a customer requested it. And although some people are using the Zend encoded version now it is available, we haven't noticed any increase in sales as a result. In fact, I really dislike the Zend encoder, as charmedlover pointed out my blog post!



    Ignoring the fact that the ionCube Encoder is cheaper, it is just so much better than the Zend Encoder. The encoder itself is very good - the interface is clean and easy to use (a major factor I consider with any application) and there are plenty of options for customising the encoding procedure. One problem that existed in the past was the need to upload encoded files in binary. This is still necessary with Zend but ionCube offers ASCII encoded files which means they are less likely to become corrupted by FTP or compression (e.g. in Winzip). The run time loading that was mentioned several times in this thread is also a major consideration. But not least, the support from ionCube themselves is excellent - they are very good at quick replies and do not appeat to be a "faceless corporation" like I feel Zend is. Notice how they are participating in this discussion yet you see nobody (as far as I can tell) from Zend.

    So in conclusion, encoding has worked for us. It protects our source, but we give a reasonable amount of freedom to our customers.
    I really like your whole 99% idea. However, if it is JUST your licensing that is encoded... what is to stop a use from including that license file?

    Surely the "check" must be somewhere else if you say the admin panel does not work? If you could just clarify a bit, that would be great!

    EDIT: Also, I just took a quick look at phpDoc. Can you show me something generated with it? I am a bit puzzled by its "automatic" documenting...
    AskItOnline.com - Need answers? Ask it online.
    Create powerful online surveys with ease in minutes!
    Sign up for your FREE account today!
    Follow us on Twitter

  3. #53
    SitePoint Wizard triexa's Avatar
    Join Date
    Dec 2002
    Location
    Canada
    Posts
    2,476
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ioncube
    More interesting posts in this thread from everyone. To clarify:

    SG, Zend and ionCube all require components on the server. This is the only way to get security, so if you care about that, it's really worth any inconvenience when and if it occurs. Not that this is likely anyway, but even a lost sale because someone couldn't install a decoder engine is preferable to a lost sale because someone downloaded your product off edonkey. For the sellers of more expensive systems, the end users are likely to have dedicated servers, and then installation of decoding engines is a non issue.

    SG and ionCube can have the loader engine installed either in php.ini, or from user space if the server supports it. Many do, some don't. Zend only works with a php.ini install that some will have already and some won't.

    Whereas in the past, any compiled code solution was a good bet for security, the emergence of decompiler services from Chinese and Indoniesians looking to profit and attack the PHP developer community has increased the threat to encoded scripts. This has also created a division between "strong" compiled code systems and "weak" compiled code systems. A strong solution uses a closed source executor, and this is essential.

    ionCube and Zend have closed source executors, and as far as we know, are the only ones at the moment. Other solutions rely on passing compiled code to the standard executor, and as PHP is opensource, this is easily intercepted for feeding into a decompiler.

    We released a new solution a few weeks ago that as well as new features such as encryption for any files, e.g. XML or templates, adds extra security to opcodes, capitalises further on the execution engine in the Loader, and includes new features that may defeat reconstruction of working code even if valid opcodes were discovered. No system claiming code recovery can recreate source from the latest generation ionCube enoded files. Zend are working on a similar solution.
    I do appreciate your input throughout this thread and also the e-mail replies I have received from your company. I have already indicated (in the e-mails) that I will be making the purchase of your encoder closer to the final development of the software.

    Thanks again, and to EVERYONE for their input!
    AskItOnline.com - Need answers? Ask it online.
    Create powerful online surveys with ease in minutes!
    Sign up for your FREE account today!
    Follow us on Twitter

  4. #54
    SitePoint Addict Olate's Avatar
    Join Date
    Apr 2003
    Location
    UK
    Posts
    252
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by sdesigns
    I really like your whole 99% idea. However, if it is JUST your licensing that is encoded... what is to stop a use from including that license file?

    Surely the "check" must be somewhere else if you say the admin panel does not work? If you could just clarify a bit, that would be great!
    We use our own licensing product to license our products This works by the user purchasing a license, entering a key string, then the license data is downloaded in a local file which is read on subseqent loads. The code that checks the license is within the admin.php file. If the license is valid, then nothing happens and the user can use the admin panel. But if the license is invalid then an error is shown and they can't go any further. We chose to put it in the admin panel because of the nature of our product - licensing. If the entire application stopped working, then their customers would also get errors, which isn't fair - it isn't their fault the developer stopped paying (or whatever the situation is). In our case, this works because you need the admin panel!

    In theory, you could manually access the database or work around the fact that the admin panel is disabled, but this is a lot of hassle. You can't just include the license file because it is "encrypted" and must be decypted by the licensing code, which is encoded.

    Quote Originally Posted by sdesigns
    EDIT: Also, I just took a quick look at phpDoc. Can you show me something generated with it? I am a bit puzzled by its "automatic" documenting...
    Basically you add comments like this to your source:

    PHP Code:
    /**
        * Changes the status of all licenses for a specific order 
        *
        * @param int $id Order ID
        * @param int $status New status
        * @global object database Database functions
        */
        
    function status_by_order($id$status)
        {
            global 
    $database;
            
            
    $database->query('UPDATE '.$database->prefix.'licenses {data} WHERE (order_id = '.$id.')''UPDATE', array('status' => $status));    
        } 
    In this case, the documentation will then be generated with a description of "Changes the status of all licenses for a specific order" and it will create a function prototype (like you see in the PHP manual) which looks like

    void status_by_order (int $id, int $status)

    Which you can see has been generated from the comments in the PHP. You can see the actual output of this phpDoc syntax at http://www.olate.co.uk/support/docs/...tatus_by_order

    This therefore means that the developer has all the information they need to use the functions - just include the file and you can use them. There is no need to worry about how the function works, just how to use it!

  5. #55
    SitePoint Addict
    Join Date
    Jul 2001
    Location
    New Zealand
    Posts
    340
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It really is nonsense that your product could appear on edonkey. Unless you are selling software as big as vbulletin, I doubt that even if there was a leak, it would only make it to a small group of people who wouldnt buy it anyways.

    Use vbulletin as a business model. Why do you think they do not encode their script? It does not make business sense to encode your scripts. You are more likely to lose a client because of the encryption than to have your software warez'd to some people who wouldnt buy your software anyways.

  6. #56
    SitePoint Addict Adam A Flynn's Avatar
    Join Date
    Jul 2004
    Location
    Canada
    Posts
    251
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Olate, I am still not quite sure how your system of encoding the licence file and requiring it in admin.php ensures security. Where is the mechanism to disallow access to admin.php? If it's in admin.php (which is unencoded?) couldn't it just be removed, and, if it's in the licence file, then not including the licence file would fix the problem. No?

    The only way I can think of to offer a mostly unencoded version is to encode a few critical portions of the code so that reverse engineering them from what code is open is more costly than simply buying the product. How do you secure your product without encoding critical operating processes?

  7. #57
    SitePoint Addict Olate's Avatar
    Join Date
    Apr 2003
    Location
    UK
    Posts
    252
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Adam A Flynn
    Olate, I am still not quite sure how your system of encoding the licence file and requiring it in admin.php ensures security. Where is the mechanism to disallow access to admin.php? If it's in admin.php (which is unencoded?) couldn't it just be removed, and, if it's in the licence file, then not including the licence file would fix the problem. No?
    admin.php is encoded. It is the only file which is.

  8. #58
    SitePoint Addict Adam A Flynn's Avatar
    Join Date
    Jul 2004
    Location
    Canada
    Posts
    251
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Ahh, okay, that makes sense then. Sorry about the confusion.

  9. #59
    SitePoint Enthusiast
    Join Date
    Apr 2004
    Location
    London
    Posts
    77
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Why encode

    With a focus on encoding products, it's also worth noting other reasons that users encode. These include:

    * Site designers who charge their client for site updates.

    * Shared host users protecting their scripts from other users on the machine (quite a few shared hosts have insecurities that allow users to easily browse other accounts on the same machine).

    * Shared or dedicated host users protecting their scripts from modification if hackers break in, and that might go undetected for a while.

    * Site owners protecting their scripts from unauthorised observation or changes from other users in the same organisation, either for security reasons, or from developers tinkering and circumventing rigid UAT (user acceptance test) and rollout/signoff deployment procedures. This is common in larger enterprise organisations such as banks, where regulatory issues would mandate encoded files.

    * Embedded product reverse engineering protection. We have customers using special Loaders built for embedded systems, such as network routers, that use PHP for the router help or configuration system. Knowing that the routers would be analysed by competitors, the PHP code is protected to create barriers to such reverse engineering.

    It really is nonsense that your product could appear on edonkey. Unless you are selling software as big as vbulletin
    The fact is that there are many products that are as big and also much bigger and more complex than vbulletin. Lost sales are one concern for companies, but IP theft and loss of competitive edge is another significant issue, particularly for larger organisations that will have invested 10's or 100's of thousands of dollars into development of a product.

    Whilst the popularity of PHP was inevitable thanks to the ease with which experienced and inexperienced/non-programmers alike can produce solutions quickly, the availability of solid encoding solutions is also a major contributory factor to PHP being embraced and seen as a viable solution that can be taken seriously by large enterprises, and where having unencoded scripts is simply not an option.

  10. #60
    Non-Member
    Join Date
    Oct 2005
    Posts
    0
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I wouldn't encode, you will lose customers as I don't even buy encoded products, I like to be able to run scripts on mutiple sites and servers, etc.

  11. #61
    SitePoint Addict
    Join Date
    Mar 2005
    Posts
    314
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ArcticPro
    I wouldn't encode, you will lose customers as I don't even buy encoded products, I like to be able to run scripts on mutiple sites and servers, etc.
    Sure, on a guestbook or something you can create in 20 minutes. I agree with you Who would buy an encoded version?

    What you don't realize is the way php scripts are being designed lately making it possible for clients like you to buy and modify the "output" aka HTML without seeing the sources. It doesn't matter if it's encoded, since there is always way around "encoding" that provide customers with ease of use and design flexibility (ie: template system). If you want full source, you pay extra for that or move on.

    HTML is HTML, it can't be encoded anyways. These days, script authors provide a sense of design flexibility and that's all that matters. We recently moved this way for ILance, and the results have been fantastic. Our sales doubled in the first month of the new product release at the same time our entire property is fully protected from prying eyes.

    It's not what you've done with encoding, it's how you market the product as an encoded entity to the customer. If the client can change his homepage after purchase, where is the problems? [unless that customer turns developer over night] we have a new package for him - Developer Edition sources at 3 (if not 4) times the cost of the encoded version. It's solid firms like Zend and Ioncube here to help us authors by going further to provide trials, demos, expiring licenses, and so on. It's basically where PHP meets Shareware (in a way).

    The point is there are people who don't buy encoded software, and there are people that look at it different way. "Even If I purchase this encoded version, will I still be able to do the things I want without an unencoded version?". In most cases for the average customer, it's HTML that is only of concern, and if that's the only concern, where is the problem?

    You want the code? don't want pay for it? Write your own logic. It's pretty simple.

  12. #62
    SitePoint Member
    Join Date
    Jan 2005
    Location
    Toronto
    Posts
    24
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I have bought a few different PHP scripts, some that are encoded, with call backs and some that are not encoded.

    Almost all of the encoded scripts I have come across I've had problems with. Some problems include:

    - You find a bug and it takes a while for the developer to get you a fix.
    - Their server goes down for some reason and so the callback fails on your script

    I understand why developers encode there script do to piracy but I feel that it has been blown out of per portion. Especially with scripts with niche markets.

    As a rule now I don't buy encoded scripts anymore its just to risky. I do not like trusting that someone will be around in a few years to fix/update/etc.. the script when it is my main source of income.
    Phone Service Reviews - Local, Cell and VOIP Phone Service.

  13. #63
    Non-Member spiderden's Avatar
    Join Date
    Feb 2006
    Posts
    11
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Is it necessary to encode you work?

  14. #64
    SitePoint Enthusiast
    Join Date
    Apr 2004
    Location
    London
    Posts
    77
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Silverline makes some interesting points. Calls to servers when running scripts, sometimes called a "phone home" mechanism, could cause problems, but this is not an inherent feature of most encoded systems themselves. With the ionCube solution we actually made a deliberate decision not to put such a feature in so far, although at the low level is the best place for it.

    Some 3rd party licensing solutions do offer this technique, and it is ideal for cases where software is leased rather than purchased outright, as it gives a way to shutoff a script if a customer stops payments and decides to walk away with the script. When purchasing a license for software that is perpetual, asking the provider whether the script uses a phone home mechanism or not could be a good idea to avoid possible reliability issues.

    Worrying about whether a PHP script company will be around in 6 months time is perhaps more than anything a telling comment on how developers of PHP scripts are perceived when compared to providers of software using other technologies. The "here today, gone tomorrow" perception of script developers is certainly not far off the mark in some cases, but the PHP developer community is also rich with quality products from companies that are very successful, and who are not going to pack up shop because they need to concentrate on finishing high school!

    When purchasing, use due diligence to evaluate a company and product. Check support forums, see how often updates are provided, how quickly responses are answered if at all, and whether by other members or by qualified company staff. Also review what people say about a product on the web, and evaluate all aspects. You could also ask about their policy of releasing source if they had to shutdown due to an unrecoverable disaster (e.g. death). True, none of this guarantees trouble free use of software. Having source may be tempting, and in some cases there are undeniable merits to having the source, or at least a framework within which to extend or modify functionality.

    However once the results of DD are in, whether or not a product is encoded is likely to be less relevant when compared to the performance of the company, product and their likely longevity. A company taking steps to guard its IP and revenue stream is taking positive action to help secure a long term future for themselves and their products, and with most people not wanting or being able to dedicate resources to maintaining code from a failed company if it came to that, this should be an important consideration.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •