L3Y

Hi, Instead, i disabled the plugin in the plugin table : mysql> select * from plugins; +----+------------------+------------+---------------------+---------+---------+ | id | dir | company_id | name | version | enabled | +----+------------------+------------+---------------------+---------+---------+ | | phpids | 1 | PHPIDS | 1.1.0 | 0 | +----+------------------+---------- .but it still doesn't work. Something else i can try / look?

Hi, I have the error "The form token is invalid" everywhere (admin and client area). Nobody is able to work and no customer are able to login. Need to fix this asap Symptoms : We did not made changes on the server : still the same php still the same apache. There is absolutely no errors in the logs (server side, and blesta) If i change Configure::set("Blesta.verify_csrf_token", true); to Configure::set("Blesta.verify_csrf_token", false); then i am just unable to login. It doesn't work more. When the csrf tokens are disabled, and i try to login, it doesn't let me login, but it doesn't show any error either. And there is no errors in the logs, server side. I also tried to disable modsecurity and enable log reporting with Configure::errorReporting but it still don't change anything, and i still don't see any errors, and i am still unable to login. Recent changes made in Blesta : The problem started 1 day after i upgraded Blesta from 3.4.0 to 3.4.3 - don't think it's related since yesterday, it was working fine for all day. Yesterday, we enabled phpids after the Blesta upgrade : please advise on how to disable this through the mysql command line if you want me to test without phpids. I don't know if this issue may be related or not with phpids. Someone know a solution? Thank you, Carl

We are running latest version of php 5.3 with ioncube, on apache 2.4

Yup : even our key file, so i deleted it from our database log table Why does it output so much infos btw? There is not way to delete this from the blesta admin panel logs without going to run commands on mysql

Yup. I just tried. I see the output. There don't seems to be any tag or link in this. I don't see anything strange with the debug output. I removed it from the email template

Hi, Our files are in the correct place. This is only a path. A path can be documented, and used everywhere, and this is not related to our path. It,s the default on apache : http://linux.about.com/od/ubusrv_doc/a/ubusg25t05.htm and also : i did not provided my real path cause this is an example on a forum

I see the urls in the emails were working even if they included the root path after the domain because of this : RedirectMatch ^/$ /beta/index.php (this redirect / to the client path) but i don't think the htaccess may be related to the tag in the email template (well : i doubt )

Any clue someone?

I know but... apt-get install and yum install aren't so complicated and a virtualhost is not a monster

And here is our cron : crontab -l -u apache2 */5 * * * * /usr/bin/php /usr/share/apache2/index.php cron

Why should i be using a control panel for Blesta? if you are a hosting provider, then you shouldn't need that! We will never do this I already verfied this. All our emails are corrects. The link i can see everywhere is : <a href="https://{payment_url}">Pay Now</a> but all we are getting in the email is : <a href="https:///">Pay Now</a> After a couple more verifications i can see Blesta CRON is sending emails with the relative path : https://mydomain/usr/share/apache2/beta/pay/method/4880/?sid=tuweiutmu..... ... ... The root path i am using is : /usr/share/apache2/ ...same as in our virtualhost. DocumentRoot "/usr/share/apache2/" Thank you, Carl

Hi, It's already enabled. ...and the link is https

Hi, The "Invoice delivery (paid)" template do not need <a href="https://{payment_url}">Pay Now</a> ...because it's already paid. We don't have any "Pay now" link in this one. I am talking about the "Invoice Delivery (Unpaid)" template. I have many unpaid invoices in a test account, and of course i am testing with the unpaid invoices. If i send the invoice from the admin, then it doesn't add the link. Instead, all we see in the email is : <a href="https:///">Pay Now</a> while this should be : <a href="https://{payment_url}">Pay Now</a> Our root path is correct (the server virtualhost root) Our domain is in the company config. We were still running on 3.4.0 , even after an upgrade to 3.4.3, i am still having this problem. Thank you, Carl

Hi, Every emails sent out by the cron job are fine, but email sent from the admin area have links like this one : <a href="https:///">Pay Now</a> I checked, and i am having the correct root path in the General settings (not the path to blesta, but the real server relative path) I also verified the company parameters, and i can see our correct hostname. I verified and in the email template the link is : <a href="https://{payment_url}">Pay Now</a> I do not see any problem, except i cannot send emails with links ONLY from the admin panel, if i re-send the email manally. What am i missing? Thank you, Car

So if i understand correctly this feature will only encrypt the key i have in /config/blesta.php ...then should i require to export the data, and the passphrase is set, i only need to decrypt the key using the passphrase, and then decrypt the data using AppModel::systemDecrypt Sounds good. I am looking at our database : most of the fields are encrypted, even without the passphrase. But : what if a Blesta customer need to perform a quick security audit on he's database? He will only see encrypted data. What if there is a hack somewhere, in those encrypted fields? Most serious solutions deliver a tool to decrypt the database : https://support.office.com/en-ie/article/Encrypt-a-database-by-using-a-database-password-fe1cc5fe-f9a5-4784-b090-fdb2673457ab#bm3 There is nothing to worry about allowing your customers to manage their data. You'll be creating trust by doing this, because you know you don't have to be afraid : your customer like Blesta, and they will stick to it. This is not only a question of being able to switch to another solution : it's a security question. If you provide a feature to easily encrypt, you should also provide a feature to easily decrypt. That's my opinion Thank you for reading! Cheers! Carl

omg! Their website is still running a version from 2013 of Wordpress : <meta name="generator" content="WordPress 3.5.1" /> <link rel='canonical' href='https://phpids.org/' /> Am i missing something?

I can provide them with a free ssl if they need.

Hi, Possible for you to tell me more about phpids? I can see their ssl certificate on their website is expired since more than 600 days. It was added to Blesta before their SSL expired. Right now, it seems like their website is dead. Are you maintaining this vendor code in Blesta, or if we rely only on vendor's updates? Their ssl expired on 08/05/2013 I know we can surf on their website by removing the https:// but the last update on their website was on October 8, 2012. Am i missing something? Should i care about something before i enable this security feature? As far as i can see it also had security issues in the past. What's your opinion on this dear community? Am i just too much paranoid ? Thank you, Carl

Hi, What if i don't want all the suggested fields to be encrypted, but only some of them. ...is there any ways for me to choose what i want to encrypt? Also : do you think it may be possible for us to add a password field to the database backup feature? I mean : we need a password to modify some fields in the admin, but we don't require any password to export the database I think it would me much better to ask for a password to export it, and also ask for another password if you require to decrypt the db, to work a little on your data. What if someday a disaster happen and we require to do a quick change on our encryption key? Thank you for reading, and taking a couple minutes of your precious time to answer me Cheers and long life to Blesta : i'm already addicted to this little smiley : Carl

Hi, Thank you. But can you please clarify more how i can recover the data once it's encrypted? This is an important point : before you encrypt your data, to make sure at 100% you will be able to decrypt it! Thank you, Carl

Hi, I have a question about the Encryption : http://docs.blesta.com/display/user/Encryption Let's say we encrypt our data. Is it still possible for us to go 100% custom later ? I mean : is it possible for us to migrate to another platform? Is there any way to get back our data as it was before in case if we see problems? What if we require to change the encryption passphrase someday - how can this be done? I know we can migrate from whm** and get back our encrypted data. I know Blesta is far better on this. I'm affraid we may not be able to get back our data if we use this feature. Someone can tell me more about this? Thank you, Carl

Hi, I've opened a ticket, but i've got no reply after 4 days. I'll keep an eye on Blesta for sure, but it seems like too many parts are still in Beta. Also, i found a couple of warnings from NAXSI that may indicate a couple of XSS in the admin. I just found 1 for whmcs, while i found many for Blesta. It's a very promessing piece of software. ..Good luck to Blesta I'll keep an eye on this for sure, and get back once the importer, opensrs, globalsign, and a couple of other things will be working.

I tried with the one that came with Blesta first. I got this error : http://www.blesta.com/forums/index.php?/topic/3426-whmcs-import-error-option-pricing-id-cannot-be-nul-migration-from-whmcs-5310-to-blesta-32/ The solution i found was to use the whmcs_migrator_b8.zip plugin component. It performed the upgrade. I choosed to automatically create the packages at import when i tried. Now, we started over from scratch, with a backup dump of a fresh Blesta install. We are currently creating our packages manually, and will attempt to also link packages manually during the import. Since i only saw errors in packages (registration duration and pricing) i assume if we create them first it may work. I'll update this ticket right after i finished to re-create our bunch of products. Thank you

Hi, I'm using the version whmcs_migrator_b8.zip from this page : http://www.blesta.com/forums/index.php?/topic/960-whmcs-migrator-beta-updated-2013-11-12/?hl=whmcs%20import It worked before while testing... ...but no longer... thank you, Carl

Hi, I'm having no luck with the import tool. We are having more than 50 products, and over 75 domain TLD's to configure. ...i need help to automate this a little Makes about 3 days i am working on our migration, and now i realize it created all 3 year package as if the client purchased for 9 years. 4 years registrations are now 7 years, etc ... etc... Also, the package prices are looking messy. Everything is mixed up, and the amounts are not the correct ones. Any fix for this? All the rest worked fine and I have already configured everything, so i would prefer a solution where i won't have to re-configure everything, if possible I did not verified our packages prices after the migration. I assumed a bit too much it was going to work out the box Thank you, Carl p.s.: even if it did not worked, Blesta importer is still better than a WHM** importer we used there is a long time. After our migration, if we were deleting a product, it was also deleting a random customer profile (and of course if was deleting all the data from the hosting server). If a client was asking for a cancellation, it was deleting the account of another customer also