I've searched the forums and think I know the answer to this but I'd just like to be clear.

As it stands NuCoder encoded files require the server extension to be installed in php.ini, correct?

NuCoder cannot yet run from 'hot loaded' extensions in a sub-directory of the source like IonCube can, correct?

There are plans to introduce 'hot loading', correct?


I love NuSphere's stuff and really want to use NuCoder but I can't consider it while it necessitates a server-extension install via php.ini, so I hope I'm correct on that last point above ... I really don't want to use another solution.

Many thanks.

Although I don't know about the support of this in NuCoder, I do know that the "hot loading" functionality in Ioncube or Zend is simply a normal piece of PHP code in front of the scripts.
It checks if the decoder extension is loaded and if not attempts to use the dl() function to load the library at runtime.

There are a number of ways to accomplish this yourself if you don't want to add it to your php.ini
For example you can create a php file that does that and define this file as an auto_prepend_file.
In Apache this can be done very easily by adding a
to your vhost (or perhaps even in a .htaccess-file)

If that is impossible you might change your site index into a "loader" and leave that unencrypted as the only one.
In my experience though, if you don't have access to the ini file because it's a shared environment, the chances that the dl() function is enabled are pretty slim as well.

My reply might not exactly be a real answer to your question, but perhaps it helps.

Thanks for your reply. That's pretty much what I was talking about: IonCube's ability to utilize runtime loading, which it can do when 'enable_dl=on' is set in php.ini (which it is on most Linux servers, although not IIS).

In such situations, one can use IonCube without any php.ini changes or .htaccess changes.

I'll look at the solutions you suggest.

Much as I want to use NuSphere's solution, my choice has to be market-driven and 'least effort on install' is really important there as my application isn't a 'techie' product. The mere thought of asking users to make a php.ini change would lose me an awful lot of customers.

I could simply not encrypt but I know of someone with a similar product who had their application stolen, so I want to encrypt and introduce licensing to help prevent that.

Thanks again for taking the time to reply and make those suggestions.

No problem, that's what this forum is for.

I do agree with your question though: this functionality should be available. I also write and sell PHP libraries and by default my customers
get a Zend-encrypted version, unless they specifically request the source code. At this moment I am considering migrating to NuCoder, but I
also see this as a bit of a disadvantage.

iirc Zend handles it in one of 3 ways, depending on the options you specify:

* Nothing, just the encoded file
* Include a short html-text in php-tags in the beginning of the encoded file stating that it is an encrypted PHP file and that you need the Zend Optimizer and then stops compilation.
* Adds some PHP code to attempt loading the optimizer at runtime.

Perhaps it's a good idea for NuCoder as well.

dl() does not add any benefits, really.
Say Apache runs 30 children processes. You dl()'ed a library into one of them. Then it will handle all subsequent requests with this library loaded. Good so far. But all other virtual hosts running under this Apache (shared env.) will run their requests with this library loaded too because they are handled by the same children processes, including one you loaded the library into.
In other words, from the admin perspectives, I see it as a hole in security. If admin of the site does not want a library to be loaded in php.ini, he/she should also disable php's dl().
So the advantage you're talking about is so slim.

Finally, good news for you is that soon we'll add an ability to use custom headers for the encoded files where auto-loading feature can be done easily.

dmitri,

I fully agree on your assessment about the dl()-functionality, that's something I personally never use anyway. Partially for the reasons you describe, partially because it's disabled in the environments you would use it most of the time anyways.

But being able to specify a custom header would be even better than what <fill in competitor> currently has to offer. I imagine that this header would by default just include a text stating where to get the decoder and then stops compiling etc and if you actually want, you could modify all of that. As usual an awesome idea and something that will make sure no one complains anymore

Btw, I assume you have all the necessaries but if you want I can get you the code how "others" handle it, so let me know if I can be of any assistance.

Is this facility in NuCoder yet?

The simple fact of the matter is, much as I'd love to use NuSphere's solution, I simply can't if it necessitates a change to php.ini to get NuCoder/PHPExpress to work. Many of my customers are with all sorts of hosting companies who simply would not consider changing php.ini for the sake of one customer who wants to use my software.

Nevertheless, with php 5.2.5 or above you have to. Since this version, php does not support dl() for modules located out of php extension_dir. So, at least you need to have the module copied there. In most (if not all) cases it means you need root privileges and it's equally hard work as performing changes in php.ini.

And yes you can have your own custom header in encoded files that will load phpexpress module using dl() function. Moreover, NuCoder version 2.0 comes with this facility built-in and inserts this header by default.

Okay thanks.