Only use IonCube on license related files.

[microvb]

While it is understandable that WHMCS is encoded to protect from piracy and to ensure license validation, this prevents a lot of customization and the freedom of exploring code where there may be no documentation available or the documentation is insufficient.

 

I propose that WHMCS open the source on all files except for those specifically pertaining to licensing and protection of their intellectual property.

 

More specifically, the sources that I am requesting be opened are :

 

Any controlling file that handles passing variables to the smarty template system.

Any controlling file pertaining to plugins that enhance the security of the system (such as database insertion points, sanitization of variables, anti-fraud mechanisms, 3rd party calls to open sourced systems [paypal, opensrs, etc] )

 

Presently, WHMCS is 99.9% encoded where less than a handful of files are open, under the pretense that everything is 'customizable' by simply editing/creating a template or writing a new plugin. The problem with this logic is that it is not 'customizable'. At best, one can integrate whmcs into their website in a hybrid scenario by copy/paste of the header/footer for the 'main' site. The actual placement and organization of content is not modifyable due to the smarty variables being inside closed source files. For example, you will never be able to natively list domains and services owned inside `clientareahome.tpl` because the variables that control that data are not populated with the information even though both pages call `clientarea.php`.

 

As for the security side of things, while WHMCS does do a fantastic job of keeping on top of things, the methods for manipulating the data are not optimal (mysqlslowquery) and use of older methods for database connectivity are in use. While I can not determine whether stored procedures are in use, I can say that mysqli__ and PDO__ are not the dominant force in connection profiles. It would be nice to be able to make these types of adjustments.

 

I have also seen several complains about lack of documentation for XYZ plugin development, which is valid -- and while it is understandable that you can not document every single line of code or mechanism or give code examples on how to use your system --- a simple solution would be to open up that area so that it can be expanded upon freely, and by your example using the Live plugins/modules/etc rather than hacking the system to bits to 'figure it out' by guessing.

Edited May 7, 2014 by microvb

[edvan.com.br]

While it is understandable that WHMCS is encoded to protect from piracy and to ensure license validation, this prevents a lot of customization and the freedom of exploring code where there may be no documentation available or the documentation is insufficient.

 

I propose that WHMCS open the source on all files except for those specifically pertaining to licensing and protection of their intellectual property.

 

More specifically, the sources that I am requesting be opened are :

 

Any controlling file that handles passing variables to the smarty template system.

Any controlling file pertaining to plugins that enhance the security of the system (such as database insertion points, sanitization of variables, anti-fraud mechanisms, 3rd party calls to open sourced systems [paypal, opensrs, etc] )

 

Presently, WHMCS is 99.9% encoded where less than a handful of files are open, under the pretense that everything is 'customizable' by simply editing/creating a template or writing a new plugin. The problem with this logic is that it is not 'customizable'. At best, one can integrate whmcs into their website in a hybrid scenario by copy/paste of the header/footer for the 'main' site. The actual placement and organization of content is not modifyable due to the smarty variables being inside closed source files. For example, you will never be able to natively list domains and services owned inside `clientareahome.tpl` because the variables that control that data are not populated with the information even though both pages call `clientarea.php`.

 

As for the security side of things, while WHMCS does do a fantastic job of keeping on top of things, the methods for manipulating the data are not optimal (mysqlslowquery) and use of older methods for database connectivity are in use. While I can not determine whether stored procedures are in use, I can say that mysqli__ and PDO__ are not the dominant force in connection profiles. It would be nice to be able to make these types of adjustments.

 

I have also seen several complains about lack of documentation for XYZ plugin development, which is valid -- and while it is understandable that you can not document every single line of code or mechanism or give code examples on how to use your system --- a simple solution would be to open up that area so that it can be expanded upon freely, and by your example using the Live plugins/modules/etc rather than hacking the system to bits to 'figure it out' by guessing.

 

I honestly do not believe that WHMCS.com adopt this standard. In this market only Blesta had such courage!

[microvb]

@edvan.com.br

 

I prefer to think that WHMCS is not as terrible as you think and that with enough feedback on this, that they have within their skilled developer team the ability to adjust this so that they can provide a more flexible product. They have the right idea with using Smarty as their template engine, however the flexibility that Smarty provides is subjugated by the locked down method used on the variables being passed to the template.

 

Further, as you mentioned, the competition is doing this so that combined with customer feedback here should provide enough reason to open the source up --- of course still protecting the licensing components so that continues to thwart piracy. Win win for everyone.

[vec]

they are newer going to do this, worthless to talk about

[JulesR]

I love this idea but I really doubt it's ever going to happen. Before this could happen WHMCS would have to hire third party code auditors to evaluate and scrutinize their code. Judging by some of the previous vulnerabilities that have been released, it's in a pretty bad way and opening the source to the public would be embarrassing and a major security concern. That said, they've made some big changes recently and I imagine they're in the process of restructuring significant parts of it to bring it more in line in terms of security and current PHP and MySQL implementations.

 

Piracy is a non-issue here. WHMCS has been nulled and decoded constantly and consistently throughout its history. Ioncube encoding is at this point merely an annoyance for legitimate purchasers or license holders who wish to make fixes or enhancements, and it does absolutely nothing to deter those who want to obtain the software illegitimately and simply not pay for it. Piracy will never be eliminated, and sending DMCA takedowns (which is what WHMCS do when they receive a report via the license verification system currently in place) is about the only action they can take.

 

Perhaps the most significant reason (in my mind) why this won't happen though is the massive support overhead that will be generated from people who have broken the core WHMCS code, or are otherwise running modified code. WHMCS will likely (and rightly should) refuse to provide support to people who have modified the code, which will cause problems for those who have made significant changes because they'd be forced to either go it alone or roll back to a default installation and lose their changes. It's understandable that WHMCS could not be expected to provide support for modified code, and trying to diagnose what issues are core code related and what issues are caused by users trying to make their own changes could be significant and, let's face it, a waste of their time.

 

The solution to this, however, would be some kind of overrides or global hooks system where users could override essentially all functions of the software with their own code, separate from modifying the base code of WHMCS. Think of it similar to how hooks currently function but on a complete scale rather than a handful of points. This would also prevent WHMCS core code updates from overriding any custom changes and make everything far easier to manage. The problem with this (as if there aren't enough problems already) is likely an entire rewrite of the code to incorporate such a system.

 

I've lost track of the number of times I've found a trivial yet annoying bug in WHMCS which I could fix myself within minutes of finding it. Submitting a ticket to get these bugs resolved is a horrible and lengthy process I try to avoid. Additionally, the 'requests' feature of WHMCS is flawed and not enough attention is paid to it at present. Something certainly needs to change.

 

In my mind the future is going to be a fully open source product that everyone can contribute to. The days of closed source projects is coming to an end. An open source public contribution based system (like a project on GitHub, for example) would allow quick fixes, quick enhancements and constant evolution and expansion to incorporate newer technologies. Right now we're stuck at the mercy of WHMCS and their support and developers. Waiting several weeks or even months in some cases for bug fixes is inexcusable in this day and age and they need to address this.