Last Updated – May 2024
The ionCube Encoder provides two ways to add licensing restrictions to encoded files. The method we encourage most is via license files as this provides the more efficient solution because you only need to encode your files once and then can generate a separate license file for each customer. The license file can then be updated without needing to re-encode each time.
However, we often see users making use of file based license restrictions where the restriction is embedded in the encoded files themselves. This can seem useful since you don’t need to provide a separate license file but because the restriction is set in the files, you would need to re-encode all the files every time for each new customer since the license restriction would be different in each set of encoded files.
Another downside of using the embedded file restrictions is highlighted in this example from our help-desk where the files are being run on the CLI:
Hello,
In a Laravel project if I set up server restriction link “domain name” for example “www.domain.com” and compile all my application with the encoder, will I be able to use php shell command?
For example in Laravel there is a php file called “artisan” that manage some activities like database migrations and optimizations.
Every time I need to update my database with a migration i need to call over shell artisan file with a command like this: php artisan migrate.
This command call al migration file (.php and encoded too) and perform changes that I need.So if I call compiled artisan with domain restriction it will not works cause I’m not calling it from an http request?
Thank you
Domain restrictions would not apply to files being run on the CLI as domains don’t exist on the command-line since they are only attached to web servers. How to deal with this situation depends on exactly how you have encoded the files.
If you have set the domain restriction in the encoded files themselves then the files will not run as the domain restriction will always be enforced but cannot be satisfied. The Encoder GUI does not provide a way around that but with the command-line encoders you can use the “–trust-unnamed-servers” option. Then the files will run with CLI PHP even though they have a domain restriction.
Using the license file method is the correct thing to do here since the Loader will then ignore the domain check (since it does not exist) and run the files.
