Jump to content

Biscuit1001

Members
  • Posts

    9
  • Joined

  • Last visited

Posts posted by Biscuit1001

  1. I considered Blesta a couple years ago and decided against it, though I couldn't remember why, but there was something that really put me off then. I think I may have just found what it was.

     

    Looking at the source code of your own site, which runs WordPress

    <meta name="generator" content="WordPress 3.4.2"/>

    I thought, wow, there's no way they could be running such an old, out-dated and unsecure version of WordPress...especially with all the focus on the security of the Blesta software. I realize the two could very well be mutually exclusive, but it's not a good sign.

     

    I went to Sucuri to do a site check, and I urge you to do the same:

     

    http://sitecheck.sucuri.net/results/www.blesta.com

     

    post-3993-0-64161500-1382752096_thumb.pn

     

    post-3993-0-29684900-1382752406_thumb.pn

     

    Malware is found specifically in the resellers section.  Malware entry: MW:EXPLOITKIT:BLACKHOLE1

     

    I've never found Sucuri to be wrong, but I'm not ruling out that possibility. According to Sucuri you ARE running WordPress 3.4.2. PLEASE tell me that's not true, that Sucuri is somehow wrong. Because if it is true... with all due respect you have no room to be criticizing any other billing systems' code. Running such an outdated install of WordPress is beyond a rookie mistake.

     

    Again, let me make my position clear: I'm really hoping this IS a false positive or in error. According to Google, your site is clean.

     

    http://safebrowsing.clients.google.com/safebrowsing/diagnostic?site=blesta.com

     

    Sucuri may possibly be making assumptions based on the severely outdated WP Generator tag left behind (though that in itself is a boneheaded move...sorry, but it is).

  2. I am also interested to know if you have any recommended live chat software as we are using the WHMCS chat addon via their stardevelop partnership.

     

    I've been really happy with OCC (OnlineChatCenters). Goofy name, but it just plain works. Took me a while to get used to hosted (though we migrated to hosted for a reason, and away from LiveZilla that we used for years), but it works well, very quick response and light resource usage, and is very reasonably priced.

     

    In WHMCS it was relatively easy to set up a connection between the LiveChat transcripts (a new support department) and WHMCS. I'm assuming it will be the same with Blesta. You don't get the full intergration as with Stardevelop, but you get a much better Chat system IMO.

  3. For those of you not seeing tickets imported. Check the support_tickets table in Blesta to see if it's empty. Most likely the reason you don't see any tickets is because the migrator will import your WHMCS admin users and assign them to necessary departments (it does nothing with the user you are currently logged in as). Log out and log back in with your WHMCS admin user (that was imported).

     

    Also, double check the Support Manager settings for Support Departments and ensure all of the correct staff users belong to the appropriate staff departments.

     

    i believe in one of your posts you said the best way to import would be to import into a clean/new install of Blesta. I'm wondering though, would it be better to first create the admins, packages, support departments, etc in Blesta? Or would that be counter-productive?

  4. Ugh, I kind of wish someone else was having the troubles I am.  Any chance you can shoot me a copy of your my.cnf and php.ini?

    Are you importing a copy of your full whmcs database, or are you using a smaller test database?

    email: my username @lithiumhosting.com

     

    *sticks nose into thread for a second*

     

    Hi there, we shared some tweets today, re "that other company" :)

     

    Back on topic, I'm wondering if breaking the importer down into just doing a table at a time (or a few related ones) might work? I don't know if that's even possible, just a random idea I'm throwing out there. I've had to do that with other applications and very large databases.

  5. Report it ethically, and document contact; then go public if, and only if, the exploit isn't patched, AND make that clear in your public disclosure.

     

    That's the way it's always been done, that's the right way to do it, and I couldn't respect anyone going about it any other way than ethically.

     

    I'm here as a prospective customer/refugee-from-the-name-that-shall-not-be-mentioned... but let me say this. I won't buy anything from a company who isn't ethical and I don't respect their practices. Think about it: not doing things "the right way" is what might sink that other ship. Don't be that guy.

×
×
  • Create New...