Hey all,
I currently use clientexec for my billing purposes, but the more i read the forums, i get the feeling i should upgrade to modernbill.
Is there a limit or customer number where clientexec gets overloaded and should be upgraded?
Modernbill also im told is very "heavy" and not recommended for the feint hearted.
My main reasons for having a hosting company was to supply space for my own projects, and recently helping out some friends.
But when friends friends want in on the deal, well... i think its time to get a lil more serious about the billing and operations of the business.
Should i upgrade to modernbill before my business grows, to avoid any headache or dissapointments which could happen in the future?

Bucster

Hi Bucster,
As a Modernbill reseller, I'm probably a bit biased, but I try not to be - as I also personally use Ubersmith for another business that I own. :)

Modernbill is "heavy" if all you need is your standard recurring billing with no frills, but as you grow, I think you'll find these "heavy" features will be valuable to you.

Some examples:
- Right now say you only accept Paypal payments. Then the additional invoice templates for credit card, checks, WorldPay, etc. are all useless to you. But as you grow, and obtain a merchant account - it's nice to have these available.
- You may or may not use cPanel integration currently. If you do not, I can foresee a time when you will want to provide atleast a small level of automatic account provisioning.
- With MB v5, there are unlimited possibilities of other software/scripts that you can tie the billing system into using the API. Odds are that now, this does you no good - but it may again in the future.

Admittedly, I haven't used ClientExec in about a year, so I can't speak for if/when it gets "overloaded". I can say that I haven't heard that from anyone that is currently using it.

Think about your business now, and what you want it to be. Are there shortcomings in ClientExec that you would like? Are these shortcomings available in another billing system?

Just some random thoughts, that may or may not help you ;)

modernbill - i will never touch it again. Cost my company $,$$$. Its got all the bits and bobs but it cant do what its made for.. handle billing

Hi and thank you for the comments.
Can i ask nkom, why you are against modernbill and maybe what happened.
I understand that the latest V5 wasn't stable when originally released, were you using the earlier V4 or V5?
In regards to "handle billing" was this in the automation side or manual entries, etc. Finally could i ask which billing software you opted for instead?

Bluedotted, some interesting points which are best considered earlier than later, thank you.

Bucster

Hi and thank you for the comments.
Can i ask nkom, why you are against modernbill and maybe what happened.
I understand that the latest V5 wasn't stable when originally released, were you using the earlier V4 or V5?
In regards to "handle billing" was this in the automation side or manual entries, etc. Finally could i ask which billing software you opted for instead?

Bluedotted, some interesting points which are best considered earlier than later, thank you.

Bucster

Im sure sure what way around it was.. but one of them dose not support our payment processer and the other one just did not send invoices. did not mark as paid, decided to randomly remove records. The list goes on and on, modernbill support did not do much to help the problems we had.

We use ubersmith now. Its not cheap, but we like it. support is great, they even logged into my support server root to fix a problem free of charge. Very good :agree:

Clientexec is perfectly fine, unless you need some specific feature of ModernBill that is not found in clientexec.

Personally, I would not touch ModernBill again for at least another 9 to 12 months. We switched from MB to www.awbs.com and love it.

I used MB for a few months (have never used v5), however the initial setup can be quite frustrating for many people. I have since switched to WHMCS and have been very happy since.

I tried MB for a month, and couldn't get on with the site integration, or the interface, I personally think the interface is horrible! I also tried clientexec, but couldn't get on with that either! WHMCS does me fine, but I am beginning to think that it looks a bit cheap...if you catch my drift

currently use mb v5 and so far more problem then it's worth looking at other billing systems

I've tried numerous billing setups, and have found modernbill just to be the worst of them period, from a newbie's standpoint.

Modernbill is well known for having a rather intense learning curve. If you're comfortable with spending hours learning software,then this is the choice for you. If, however, you would rather spend that time with family, friends, whatnot, then don't go down that road.

Modernbill is the only internet billing software (that I know of) that comes with "training sessions". Of course, another way for the MG moguls to make more money.

MB5 (which you'd be using if you purchased now) is just wrong on so many levels it's not even funny.

Honestly, give whmcs a shot. The setup is easy, the support is fantastic, site integration is so easy it's not even funny. All in all, it's just great!

ModernBill is for newbs or old users alike, all depending on your needs. We currently use MB 5 with only one issue with Plesk 8.1 and it is being resolved. The issue is basic, Plesk changed the command for webstats, so not a ModernBill fault.

It all depends on what your needs are though. ModernBill is more robust with more features than anything I've compared it to on the market, but it also takes more time to understand it.

It also has a true accounts receivable front end system, which for some is very important.

We originally started off with WHMautopilot, but were not happy with that. We then started looking into all kinds of different billing solutions. We also looked into MB, but found it way too bulky and did not quite do what we wanted it to.

We eventually ended up with WHMCS and it has been a very good choice. We've been using it for over a year now and the support is awesome, as well as the features.

WHMCS seems to be the new fav. I think for dedicated server/datacenter companys ubersmith is the only one you could ever think about useing. I have never tryed WHMCS.

Hey all,
Excellent feedback, thank you.
I have had a quick look at all the systems mentioned and currently lookin further into whmcs.

Thanks again.

Bucster

Modernbill can be used by a newcomer to the industry, though it is heavy but very feature enriched and you get the support for what you pay.

I'm using MB V5 right now and they have seemed to got most of the serious issues out of the way, its still quite buggy but they are not show-stoppers. MB has been releasing new versions. I would honestly wait a few more versions of MB before moving. Its just not worth it now... But i'm confident once they fix up all the bugs, the software is going to rock the industry.

I've been watching Ubersmith, and I kind of like them. They have a robust system that has proven use by some very big players in the market. They dont' overcrowed their features on the software, a few payment gateways, 1 panel gateway, 2 domain gateways etc....

I don't see why MB needs to build 18 different Payment gateways...This is why they are so slow and buggy. Everytime they make updtes, they have to update a million 3rd party intergrations they built. Just offer the top3 payment gateways and the top3 domain registries, etc... and the software will have less code and in turn be more stable.

It took me 10 min. to get used to modernbill, it's great for invoicing and works with almost all the payment processors (although I didn't mention the 1,000 other great features :)). I have used whmcs, but I personally don't like the newbie feel.

Go with modernbill, you wont regret it.

going by ur title, modernbill, in fact most common billing systems include but is not limited to ur current clientexec, whmcs, whmap, awbs etc etc. are not n00bie.

I'd say 90% of "paid" billing systems are very professional and 10% are at the ok/improving level.

MB is too technical i'd say for webhosting, i prefer to stick to simple systems like whmcs

We use ClientExec for all billing and hosting management. I've never used another backend, so I can't offer any other thoughts. I'm very happy with CE, it's features and support, and the direction it's moving in.

I've used MB about a year ago when I first started out. I like it but took me about a week to set it up. Used it for a little while but their OpenSRS plugin sucked for .ca domains and Enom had a half *** registration system for .ca names.

I decided to try something simpler and gave CE a try. It turned out pretty good and was simple to setup. A few months later I had a plugin written for OpenSRS. I've used CE for about 8 months. Then I discovered that CE doesnt encrypt domain name passwords, just the CE acccount login password. This scared me for liability reasons so I decided to go and give AWBS a try. Apperantly they say all passwords AWBS creates are encrypted and regsitrar passwords are creatred on the fly.

Will be installing AWBS tomorrow and doing a test run.

I use modernbill v4 right now and I am not 100% happy with the software. It often reports incorrectly and has billed a few of my customers twice before. The interface is just way too complex compared to what it really needs to be.

V5 is a total waste of time as I see it. I would not even touch(aka test drive) for a year.

Then I discovered that CE doesnt encrypt domain name passwords, just the CE acccount login password. This scared me for liability reasons so I decided to go and give AWBS a try. Apperantly they say all passwords AWBS creates are encrypted and regsitrar passwords are creatred on the fly. Will be installing AWBS tomorrow and doing a test run.

This is what awbs says about domain password:

The domain name passwords are different for every registrar, some are encrypted some are not and some dont have password.

So you'd better to choose a registrar who uses an encrypted password, Then you will be fine with awbs.

we use whmcs. it helped having the free trial period to test and see that it was a perfect fit.

My first billing system was ModernBill which was November, it had endless bugs, and their new version doesnt even have all that much modules. They promise a date to release a certain module and keep pushing it back, so I got tired of their BS and left. However it had too much features that was hard for me and even my staff to use, too much of a big script and hard on the server.

My 2nd one was Lpanel, which was this december... Let me tell you about these fools! Stay away from them and far away from them, their support takes 2-3 weeks to get a reply which doesnt even make sense. Poor script, no good features.

And last, WHMCS... I just moved to these people this month and I must tell you they are great. It's only 1 guy that runs this company from what I hear and his support is excellent, very very neat script with more features than I can use and also very easy and light on the server.

I have to disagree with the comment about big for the server, unless you are running some little celeron then most scripts would be big for it.

As for the training. I trained our staff in about 2 days total time on ModernBill. Yeah, they still have questions here and there but they know how to use it and can handle all there daily duties without problems.

As for the modules issue, I've never had to experience that fortunately because all the modules we use have been in the system. I.E. we prefer a real gateway, although we do offer PayPal just in case but it is definitely not a prefered payment method.

It also supports cPanel, Plesk, Helm and most of the other major control panels so no issue there.

Here's my issue with WHMCS it needs register_globals turned on which screams to me that the software is not at all well done. The time when the domain was registered was well after the use of register_globals are highly suggested not to be used.

You try to justify the use at any forum with people with PHP knowledge (IE: Sitepoint) and they'll tear you apart.

I don't care how amazing someone is in PHP there is no reason to not be using $_POST, $_GET ect. You're just asking for trouble when you are just using $blah everywhere. You WHMCS lovers can say the creator is just amazing or whatever but I guess you also probably don't keep your kernels exploit free or anything like that. I mean what are the chances someone pulls off those exploits?

I highly suggest AWBS. This system does everything and it has over impressed me with its capabilities. It even looks professional to my clients when they login. I couldn't be happier.

<---- Another unsatisfied ModernBill license holder. I bought a 250 user license. Biggest waist of money. Currently the license goes un-used. Tried to setup and use it a few times, but like others have said here I do not have the time to learn their bloated software. MB was more of a hindrance than a help.

You try to justify the use at any forum with people with PHP knowledge (IE: Sitepoint) and they'll tear you apart.

Only because they're brainwashed into thinking "globals are evil".
Globals are not, by default EVIL.
What makes globals evil is the fact that people don't secure their own code.
Of COURSE people are going to say that "globals are evil" because they're brainwashed to think this.


You WHMCS lovers can say the creator is just amazing or whatever but I guess you also probably don't keep your kernels exploit free or anything like that. I mean what are the chances someone pulls off those exploits?

And your point?
Have you personally seen the source code of WHMCS?
Do you know for a FACT that WHMCS is vulnerable?
It is possible to secure up globals so that they're not abused.
Sure, using _POST and _GET is better, but just because something uses globals does NOT make it bad software!


which screams to me that the software is not at all well done.

Of course it would, since you know everything about code, and WHMCS, right? Like I said, have you seen the source for this? No, you haven't.

Now, this isn't saying that Matt isn't WORKING on fixing the system so that these aren't required, but hey, again, you know all, right?

It's amusing when someone with so little knowledge of how something works automatically attempts to attack a product based on misinformation and misconceptions.

On the topic of "ModernBill 4 newb's", I would consider my self a newb. I had an extreamly difficult time learning how to setup and use the software. The manual and forms wern't much help, but I figured it out eventually.

My delema now is whether or not to use version 5 or 4.. I guess I'll figure that out too.

like BlueDotted, I'm an ubersmith reseller, so my views on billing software are probably a little slanted, however I would recommend taking a look at ubersmith. In my opinion, it handles billing and support quite efficiently and easily. It's got a pretty easy learning curve...and it's able to grow with you as you start accepting credit cards and get bigger in terms of clientele. I would recommend you take a look at it and see what you think. I know that we started out with ubersmith in a position very similar to yours, and ubersmith has been able to handle everything we need it to do.

Personally, I use modernbill and have to agree the learning curve is very steep. But once u get the hang of it, then it's not to bad. It's a beast of a software and it's good to know you have something that robust behind you. No doubt you would grow, and modernbill can grow with you.
If i can set it up, then I think anyone can, just takes a bit of time and patience.

PS Stay away from MB5 Stick with MB4

You make the mistake of not sanitizing one variable and someone finds it all hell breaks loose. Not having globals at all reduces the chances of such a thing happening. It also makes it easier to manage the code and well that can make things like having more one than developer a whole lot easier.

There is absolutely no reason to not be using $_POST['username'] instead of $username. Well here's an example


function login()
{
if ($username=="Blah")
{
echo "Logged In";
}
}

Simple enough right but what's $username where did it come from exactly?

Now lets make it more complex


function login()
{
if ($username=="Blah")
{
checkPerms();
}
}
function checkPerms()
{
if ($username=="Blah")
{
$isadmin=true;
}
}

This is an example of some poorly coded code but who's to say someone does not make a mistake somewhere. First what is username? it appears to be global well what happens if I define username somewhere else? $isadmin is just an example of someone forgeting to define a value for something that could potentially be dangerous. For the most part you will remember to do this but what happens if you forget one time. It could be something as simple as plugins or a config file anything. Suddenly you are open to a hole that generally speaking should not be there.


Saying this is not a hole if the code is good is being arrogant. You still run a firewall even though your software is up to date right? This is no different it's almost like a firewall in that it adds extra protection if you slip up (no one is perfect)

I may not have the WHMCS source and no one appears to right now but what happens if there is some ioncube hole where you can decode the files? What then? It did happen to Zend which in turn there ended up being source releases of things like kayako's support suite. The idea of being closed source keeps you safe is proven to be a naive way of thinking just look at microsoft products.


Oh and for the sake of arguement I already found a permission hole in the client area by using the demo on their site in all of a few minutes. I'm sure I could find others as well so right now one of your customers could potentially find the information of other customers

Well I can't edit my post now but a bit after I found the original hole I found a much larger one. I was able to find a hole which would allow me to gain access to the admin area.

I'm not exactly impressed these two holes I found as they were easy to find and are both very dangerous. I'm glad I never made such a switch I did inquire about the software. But register_globals screamed to me that this may not be security minded or even made by a person/company who is really knowledable. These were the types of holes that you just don't see in a piece of software you expect to use as a billing system.

Oh well right I have no clue what I'm talking about

Oh well right I have no clue what I'm talking about
I didn't say that problems didn't exist
What I said was that IF they were properly secured, globals are fine.
As far as the errors, we have but your word on this. I'm not saying that you're lying, or exaggerating, or not, but I AM saying that it is simply your word. Given your agenda of !globals, it would hardly be a surprise to see that you were exaggerating things.

If you've run across any sort of security breach, of course this is a bad sign, but the issue is how you address it, and more importantly how MATT addresses it. If you haven't already, please make sure to forward the details of the xploit to him, or PM them to me and I'll make sure they get sent to him, because if this does, in fact, exist, then there IS a severe problem that needs to be addressed immediately.

Globals, as they are are fine and dandy. What's NOT fine and dandy is insecure globals, which consists of about 90% of the world's code.

Just for anyone curious I posted this on a bug tracker for WHMCS. As of now there are barely any checks on who owns what when it comes to customer pages. Try for yourself something as simple as putting in an invoice id of another customer.

On top of that there is no checks or cleaning of customer data input beyond slashing values. So you can insert what you want and produce undesired results on the admin part. As of now a customer can insert javascript or normal html into their forms as a result which can lead to serious issues if the person wants to make problems.


So for those of you who made the quick switch I'd hope you don't take on customers who are a risk. On top of that users who are at all curious because this piece of software seems to be full of fun holes.

As of now there are barely any checks on who owns what when it comes to customer pages. Try for yourself something as simple as putting in an invoice id of another customer.

That is incorrect
Judging by both my own install and the install in WHMCS, you can NOT view invoices owned by other individuals. Instead, you will receive this error:

An Error Occured. Please Try Again.


You may have been able to access YOUR invoices, but accessing invoices of another customer is not reasonable or possible. I tried.

Invoices are assigned a "userid", and as such this userid is checked when the invoice is called. Now, if there was a way to CHANGE the userid manually, then yes, this might be an issue, but the userid is stored in the WHMCS cookie which is stored on the server.

Not even when logged in as admin can I vew another client's invoice through the direct invoice url.


As of now a customer can insert javascript or normal html into their forms as a result which can lead to serious issues if the person wants to make problems.

Tested and found to be incorrect
The user CAN enter javascript, php, whathaveyou into the support form, or other forms. However, said javascript is not parsed. Again, I tried this using a simple js date function. Did the JS parse? No it did not.

Again, without directly seeing the code, there would be no proof of "On top of that there is no checks or cleaning of customer data input beyond slashing values.".
I agree, removing html entities and javascript entities from the support and other forms IS a necessity, if they're allowed in the first place, but from what I can see, I have seen no holes in this.

Now, I'm not saying this isn't exploitable, but from the bug YOU specifically posted, there is no threat.
Users can NOT see other user's invoices, they can NOT change their own UIDs, they can NOT do a number of things.

So, what you've done here is try to "scare" individuals away from software with vague scare tactics which don't even work. Nice job there.

I tested on their demo which is now disabled


customer puts their name as follows


<script type="text/javascript">alert("HI");</script>



Then visit the customer list page in the admin area. You'll find a nice surprise.
If you are creative with javascript you can create some nasty things. For example use the js to do a redirect to another page in the admin area to say remove something or something stupid like that.


Invoice ID's same ID this was all done through their demo which is now disabled. Whether this was eventually fixed who knows but in the demo it was not.

As stated in the bug tracker

I visited http://demo.whmcs.com/viewinvoice.php?id=94
I then looked at the admin area and found another invoice id that being 52.

I brought up the invoice of someone elses account.

I also did this on a package upgrade and got the same results.

Invoice ID's same ID this was all done through their demo which is now disabled. Whether this was eventually fixed who knows but in the demo it was not.

This was never an issue at all. How you ended up thinking it was, or getting access to this, nobody knows, but it was never, ever a problem. Not only could it not be reproduced on THEIRS, but it could not be reproduced on mine either.

Invoices are assigned by user id, and that user id is checked on the page. If it's not right, obviously they shouldn't be shown the invoice and they aren't. No news there.

The input field issue is a case by case thing. With yours it may have worked, with others it might not. I know that it was 50/50 when I tried it, so it may just be dependent on the function.

At any cost, YES the input fields need to be sanitized, NO, private client invoices are not shown to anyone but that client.

TonyB,

Did you notify them first of the problems with their code or post here first?
If you posted here before they came up with an update then that's plain irresponsible.

It's just standard operating procedure when a possible security problem is found.

[sorry to butt in... I don't even use the software but that had to be said].

As of now there are barely any checks on who owns what when it comes to customer pages. Try for yourself something as simple as putting in an invoice id of another customer.
Just so other users aren't worried by the comments of this user, I will confirm that there are of course checks to ensure that the currently logged in client can view only their invoices and not other users of your system. The same goes for all other items in the client area. The user here must have been logged into the admin area at the same time as trying this. An admin user can view any invoice in the client area in order to print the invoice if required.

The demo is down while it is upgraded to our new V3 release and not as a result of this users comments!

Matt

I posted the invoice issue which apparently is because I was in admin and in as a client at the same time.

As for the js issue, well my bug tracker post was removed so I see no reason to not post the information here.

As for the js issue, well my bug tracker post was removed so I see no reason to not post the information here.

In regards to this:

Hi,

Thanks for the report. This security vulnerability has now been removed from the V3 files.

Regards,

Matt


Less than 20 minutes after I opened up at ticket, after you tried eploiting my own installation and found yourself banned.

oops!

Opps indeed I was just a valid customer trying to order something and my name consists of javascript code ;). I guess when the javascript code actually did execute you saw me as a threat who would have thought. Maybe I proved my point this is a hole after you discredited it as not possible that the javascript does not execute.


Maybe this will be a real eye opener to not use a piece of software that their business depends on when the company they buy it from hides their contact information on the domain the product is sold on. I thought that was one of the first rules of hosting someone who hides that information may have something to hide or may not be a credible company.

Hey, I never said there wasn't an issue with the javascript code. Check my post again, all I referred to was your false claim that register globals caused a security vulnerability allowing a client to view any clients invoice. I've not done anything to discredit anything or anyone. linux-tech opened a ticket notifying me of a security issue with HTML tags being allowed in the clients profile fields, 20 minutes later, I released a fix for it. Would have thought that was a good thing? As for suggesting we're not a creditable company because we respond to notifications of security vulnerabilities so quickly, it seems a little odd.

I released a fix for itI don't see the fix, Matt. Was it rolled into a full release or something? If so, can you say when it was done so I know I have it?

I'm referring to linux-tech claiming it does not exist.

And if you think it's only in the customer profile fields you are very mistaken.

As for a credible company I'm talking about using something like whoisguard to protect things such as where the business is located.

As for a credible company I'm talking about using something like whoisguard to protect things such as where the business is located.

NOW you're just fishing man, lay off.
There are plenty of reasons to hide whois information. I hide mine, so you're saying that I'm not a "legitmate business"? No.

Reason #1 to hide information:
DRA - Domain Registry of America
These guys are the scum of the earth for domain registrars. They specialize in gathering all the information of domain holders and sending them fake "renewal" letters attempting to gain the customers at 3-4x the actual domain price.

Reason #2 to hide information:
Email protection
There are hundreds , if not thousands or tens of thousands of sites out there that display information publicly without any sort of protection.

Reason #3 to hide information:
Controlling who gets your information and where
Again, there are countless sites out there athat make whois information public without permission or consent of the individual. Shouldn't YOU have control of your own private information?

Hiding whois information doesn't make the business any less (or more) legitimate, stop grasping @ straws there.


And if you think it's only in the customer profile fields you are very mistaken.

Here, I agree. Hopefully you cleaned up ALL of these, not just profile fields Matt.

Protecting against JS/XSS insertion attacks is pretty hard....a regex to _only_ allow A-Z is probably the best way for simple things....and for MySQL, mysql_real_escape_string() is good most of the time, though I've heard of people getting around it via CHAR()....hmmm. Should fiddle some time :p

register_globals is an interesting one - sure, it's only bad when coded mistakenly, but humans aren't perfect - so why add yet another parameter of uncertainty to the mix? :)

Protecting against JS/XSS insertion attacks is pretty hard....a regex to _only_ allow A-Z is probably the best way for simple things....and for MySQL, mysql_real_escape_string() is good most of the time, though I've heard of people getting around it via CHAR()....hmmm. Should fiddle some time :p

register_globals is an interesting one - sure, it's only bad when coded mistakenly, but humans aren't perfect - so why add yet another parameter of uncertainty to the mix? :)

Well these holes I'm finding are just not bothering to use any sort of protection beyond addslashes or the database equivalent.

These holes aren't really hard to prevent it's not like someone is doing it through javascript portions or anything of that nature. This is a simple form field such as a support ticket, customer profile ect.


Then you look at some of the other issues such as when you error on the pages such as customer profile rather than removing things such as slashes that were added when the data was put in originally it just leaves them there.

Did no one test that all? For someone selling a piece of software I expect a higher level of testing but that's just me.

register_globals thing I can argue this all day long and they still believe it's fine if you code good. Trying to manage all those globals is not exactly fun and adds a layer of possible human error like you said.

Lets just pull the assumption that all post vars are going to not want to have > and < as those strings but rather use html along with that they will also always need database escapes or addslashes. Now we could just create a simple class that runs at runtime that goes through and does this to the entire $_POST array. Suddenly we've removed the possible human error of all the form fields. Although not a great idea just a simple example.

auto_prepend_file comes in very handy :)

Beware that ModernBill V-4 is now having problems. It's not compatable on any new 64bit servers. Support says there is no fix. So if you update your server, your MB is done.

To clarify what was said, it has to do with the 64 Bit OS, not the server. You can run a 32 bit OS on a 64 bit server if you choose.

From my understanding (don't quote me on this though) the issue will be resolved in the upcoming update.