Leaderboard

You left no alternatives when you incorrectly made assumptions and ignored help. Did you bother to look through your logs as suggested? Suhosin does what it is configured to do, it doesn't know what's valid or not. I would ask for you to post your rules to help future customers who use Suhosin.

Hi. Just to know. I installed the 3.0.1 version succesfully. I'm still on tests to learn how it works (since I am more familiarized with WHMCS). So, Before beginning the migration of info to Blesta, I wanted to know if BLESTA 3, in addition of QUANTUM GATEWAY plugin, would have ability to use also the CDG Quantum VAULT gateway version? I mean, using just TOKENIZATION, to use their vault DB rather than storing the CC encrypted on Blesta DB, for recurring automatic billing/payments. I know WHMCS does that (since they have 2 separate plugins, one for REGULAR Quantum and other for QUANTUM VAULT, same scenario like Authorize.net AIM, ARB, CIM, etc) In case Blesta doens't support that yet, will it be added at least in the near future / update? BTW, I use to have 2 kind of customers, one that accept automatic recurring charges to their CC, and the other group prefers to pay MANUALLY each cycle with no automation, so That's why I use both services: Vault-Token and Regular Gateway in same Billing platform (WHMCS for now) Thanks for your response.

Overwriting everything worked, it seems files got deleted I guess. Thank you

Multicraft is currently scheduled for development, and is assigned to task CORE-61. It's tentatively set for a 3.2 release and I'm personally looking forward to being able to build this one. Do you have an "in" with a lot of these minecraft server providers? If they are willing to switch to Blesta if we had support, that would probably move it up the priority list.

Multicraft is planned, we have a dev license but have not installed it yet. TCAdmin and Multicraft are the two first modules for the GSP market that we're planning to release. I don't have an ETA yet, but it's planned.

Yeah, I removed those tags after the first try I think and it still throws the error. I just double checked the html and text (they are identical) and there are no "/" anywhere in the tags. There also isn't a / in the password. about the counters...gotcha If you want, I'm more than happy to give you access to my install if you need to poke around.

It is possible to reveal the original passwords using hashcat, but not something worth even trying. It would be much much easier to update authentication in Blesta to allow WHMCS client passwords to work. /app/models/users.php (line 234) from: elseif (Configure::get("Blesta.auth_legacy_passwords") && $user->password == md5($vars['password'])) { to: elseif (Configure::get("Blesta.auth_legacy_passwords") && ($user->password == md5($vars['password']) || ($parts = explode(":", $user->password) && $parts[0] == md5($parts[1] . $vars['password'])))) {

No. MD5 is strictly one-way. I think the best route is to simply reset all passwords on migration and send a mass email to your client base advising them of the change.

There's already as task (CORE-468) to allow credits to be used to make purchases and manually apply payment to invoices, scheduled for version 3.2.

Latest version of the migrator is up (b5). You can get it here, direct download here. Changes include: Sets country to US if not set (clients, contacts, payment accounts). Sets first/last name for payment accounts to unknown if not set. Decodes HTML entities. Imports invoice credits as in house credits.

The importer is designed to be run only on a fresh (not previously imported) database. As per the instructions when running the importer, back up your Blesta database first, then import. If you run into errors, restore your database before attempting to run the importer again. There's no need to reinstall, just restore your database. Why are you required to import into a fresh database each time? Because the migrator must map data from WHMCS into Blesta which it does by storing references in memory. If you run the importer more than once then the references created during the first import are not available upon the second run, making it impossible to reconcile that data.

What do your service creation and package welcome email templates look like?

Any error that states "Invalid parameter number: number of bound variables..." is simply caused by the previous error. In your case: That sounds like you tried to import into an already populated database, where a client could not be imported due to it already existing.

I think that would be the safest bet, to be honest. I've noticed issues in our imported support tickets, as well.

You've got to be kidding... WHMCS stores HTML entities in the database?! I wonder how many fields are encoded? Invoice Lines Company Name ??? Maybe we'll just need to decode everything.

It looks like a email template issue mate, try this: http://www.blesta.com/forums/index.php?/topic/1089-suspend-error/#entry8902 If not hopefully Paul, Cody or Tyson can help, but I think it's a Email template issue.

Import went smoothly here.

Your as bad as me LOL, from WH** -> Blesta 2.5 -> Blesta 3.0 B7 haha. Glad you had a save journey through them.

So it was a server issue (Suhosin is something on the server). Anyway glad you solved it.

Glad you were able to isolate it to Suhosin. If you were able to narrow it down to a particular rule or reason we'd love to know so we can try to work around it in the future. We set up a server with suhosin on it specifically for identifying these kinds of issues, but we admittedly haven't done very extensive testing with suhosin. I'll see if we can replicate this in that environment. Thanks!

Just migrated from HB -> WHMCS -> Blesta Not too bad.

I don't think you understand, this isn't a simple form issue. Let's take a look at how the token is generated. public function getCsrfToken($key) { $session_id = session_id(); // Prefer computing CSRF using HMAC if (function_exists("hash_hmac")) return hash_hmac("sha256", $session_id, $key); // Sha256 hash is the next best thing if (function_exists("hash")) return hash("sha256", $key . $session_id); // Regretably, fallback to md5 return md5($key . $session_id); Verifying is simple public function verifyCsrfToken($key = null, $csrf_token = null) { if ($key == null) $key = $this->csrf_token_key; if ($csrf_token === null && isset($_POST[$this->csrf_token_name])) $csrf_token = $_POST[$this->csrf_token_name]; return $this->getCsrfToken($key) == $csrf_token; } The installer shouldn't have anything to do with it. What do your error logs say? PHP should be throwing some sort of error if you are missing something So what are you running? OS, PHP version, openssl, etc..