L3Y
-
Posts
112 -
Joined
-
Last visited
-
Days Won
2
Posts posted by L3Y
-
-
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
Your files are in the wrong area or your cron isn't set-up to the right location when I used Ubuntu (Debian) my files go in /var/www/ you aren't doing that.
-
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
You'd be surprised how many hosts host it on their own VPS with a control panel, and as for that issue you've added to the thread, are you using:
Centos / Ubuntu / Debian / etc.
PHP Version
-
And here is our cron :
crontab -l -u apache2 */5 * * * * /usr/bin/php /usr/share/apache2/index.php cron
-
It's probably the cron job then mate.
What control panel are you using and what's your cron job command?
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 Sorry I was probably thinking of the invoice due reminders.
Make sure you've updated it in both the HTML and text sections. The URL comes from the template, no where else.
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
Why not do what we do and use the https:// htaccess rewrite.
-
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?
-
-
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
Blesta is transparent about encryption and what algorithms are used. You will always be able to decrypt your data, with the exception of hashed data, like passwords which are bcrypted HMAC-SHA-256 hashes and are not reversible, even by Blesta.
So yes, you can get your data out.
-
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
The Form Token Is Invalid. Error
in Support
Posted
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?