rebus9

Running version 4.2.1. System has previously passed all PCI scans, until now. CardPointe scanner is now returning a failing result, with the vulnerability listed as "Insecure configuration of Cookie attributes". The only additional info provided is a link to: https://wiki.owasp.org/index.php/Testing_for_cookies_attributes_(OTG-SESS-002) The site is running on IIS 8.5 with only port 443 bound, so everything should be over TLS 1.2. Port 80 binding was removed. Any idea how cookies are being passed insecurely? Is there some communication via another method other than 443/TLS 1.2? Most importantly, what are suggestions on how to close this hole so the PCI scans pass?

Thanks Tyson. That extra detail was enough to get an exception from TrustWave. The exception is not permanent, but hopefully the Blesta software will have an updated jquery version before the it comes up for review/re-evaluation.

Can you ping them internally, since they are not responding here? The PCI compliance vendor (TrustWave) says what's been provided in this thread is insufficient explanation, and we're getting financially penalized for PCI non-compliance.

Paul, are you still here? This single issue failing PCI is causing us to be charged a PCI-non-compliance penalty fee by our merchant account provider.

Here's the response from Trustwave: "In order for us to properly process this dispute, we require the full jQuery version currently running on this system." Can you please provide that info, along with any notes that would be helpful to give to them to process the dispute? I already sent them the CORE-2779 link, but they want more.

If that is true, they will HAVE to update it-- and FAST. We are failing our mandatory PCI scans, and the jquery version detected is the sole reason for the failing grade. We passed on all other points. PCI scan failure means we are out of compliance, and will be charged a monthly non-compliance fee... not to mention the additional legal exposure for failing to meet standards.

Blesta 4.2.1 installed. Until now, monthly PCI scans all passed. Today, I woke up to a notification the overnight PCI scan failed: Unfortunately, Blesta doesn't run as a self-contained app (we're on Windows Server 2012 R2), and requires various 3rd party components, such as ioncube loader. Is the fail related to a component that ships inside Blesta, or one of the external components? If it helps, the full text on the PCI report is:

This is exactly what I've been waiting for. To inhibit an emailed invoice, we have to set delivery to Paper (per your instructions in another thread). But, also per your instructions, that means we have to periodically delete messages in the queue waiting to be printed. A "none" option would solve all of this.

Maybe in a future build, then. It's common for multi-service clients to have several open invoices at any given time of month. If they owe $1250 across 4 invoices, and a $310 check comes in, we (currently) include this format in the receipt email: Payment Received: $310 Balance Remaining: $940 That was based on feedback from many years ago, where customers would often ask us how much they still owed. When we added the Balance Remaining field, feedback was overwhelmingly positive. I hate to lose that functionality when we cut over to Blesta next week.

Found some docs, but didn't see a reference to available variables for email. What's the variable to show the remaining account balance (total balance of all monies still due)? When we send out payment receipts in our current system, we include both the payment amount, and any remaining balance due on the account overall. The total due and past-due amounts are shown on the client login page, so I'm assuming the total due has to be a variable available for email. A pointer to the list of available variables would be appreciated, too. (so I can feed for myself going forward)

Other emails are working (new service, payment received, etc) but Payment Due/Late notices are not sending at all. (see screenshot) Any ideas?

Some customers on auto-pay do not want invoices emailed, and for them I un-checked the "Invoice Delivery - Email" option when the recurring invoice was created. (see screenshot) Problem-- the invoices are still being sent via email overnight. Any ideas why, and what can be done to fix it? Disabling the invoice delivery email template is not an option, because some customers DO want invoices via email.

Thanks for the tip. The key to BCC to our accounts team was Staff Groups. Unfortunately, if there are multiple contacts, we get BCC'd on every copy sent out-- not just once. If 3 people at the customer's side get a copy of the invoice, our team gets 3 CC's... one for each email sent to each contact. We can live with that, I suppose-- but it would be nice in a future build if this was addressed. Our current system puts the primary contact as the TO recipient, the secondary contact as a CC, and us as a BCC-- all on the same message. (hint, hint, Blesta team) But this still leaves an unsolved problem. Assume 3 contacts: Owner/Account Holder: owner@company.com Billing person #1: billing1@company.com (additional contact) Billing person #2: billing2@company.com (additional contact) Both billing persons have been set up with login permissions and all items/permissions are checked/enabled. On the main account screen, the "Address Invoices To" option is set to Billing Person #1. When a new invoice comes out, both billing persons (#1, and #2) get a copy of the invoice. (good) The owner does not get a copy of the invoice. (bad) But when a payment is made, ONLY the owner gets a copy of the receipt. Neither billing person gets notified the payment was received. (bad) Any ideas?

I thought it was...... but when I added additional contacts to the account (contact type = billing) those contacts still do not receive payment receipt emails. Only the primary email address in the account-info section gets a copy. But the opposite is true of new invoices. When I created a new invoice, the secondary "billing" contact got the invoice but not the account owner. 1st need: I need all contacts-- primary account owner plus any additional "billing" contacts, to all get a copy of any emails sent related to billing (invoices, receipts, late notices, etc.) 2nd need: I also want our in-house accounts team to get a copy of all emails auto-generated by the system (receipts, invoices, etc.). VERY IMPORTANT. Our current system does this (it was a one-click global option) and we use it for sanity checking and verification. We don't want any emails from the system going to clients without a BCC going to our accounts team, so we know exactly what our customers are receiving. (We've caught errors this way.) .... other than that, this seems to be a pretty nice product.

Our legacy billing system supports 2 email addresses per account, which is extremely useful. Many of our high-line clients have more than 1 person responsible for accounts payable-- or in some cases, the owner wants CC'd on all billing related correspondence sent to their A/P department. Put in perspective, more than half of our clients have 2 billing email addresses tied to their account. Is there a way to associate more than 1 email address per account?

Ok, and just to be sure, this is running under IIS 8.5 on Server 2012 R2. Not linux.

I'm doing all this while logged on to the server console as the Administrator. I also did the CLI option-- see my last post. The entire /config and /cache directories (not just individual files) all have Write/Modify control for the AppPool user, IUSR, and even the Everyone group. This has to be something simple.... because the CLI is hanging on the same error (see my last post above).

Another update. Started again, fresh.... but this time I used the command line instead of web. Errored out at the same step: Attempting to write config... Ensure that the file (C:\Blesta\public_html\config\blesta-new.php) is writable. Press any key to retry. I triple-checked that the config directory has write/modify permissions for the Everyone group, the AppPool user, and IUSR. Can you think of any reason the installer shouldn't be able to write to that file?

Also.... the same tables were created again: "accounts_ach" thru "log_account_access"

Ok, sql-mode="" has been set. I deleted all Blesta files and the Blesta database and started fresh with new files, plus the 7.1 hotfix. Both the IIS DefaultAppPool user and the "Everyone" group are set to Full Control (while this problem is being worked on) on both the Config and Cache directories. Created a new database, then Launched the Blesta installer again. Got the following message (see screenshot). So I'm not immediately understanding why the installer seems to be unable to write to it. There is nothing new at all written to the PHP error log.

No other entries in the PHP error log since the white screen of death. Here's what is in the my.ini file right now: # Set the SQL mode to strict sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION" Should I turn the entire thing to an emptry strink like this: sql-mode="" or just take out STRICT_TRANS_TABLES and leave the rest in there: sql-mode="NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTUTION" ?

Yes, config\services.php exists. Here's the contents: <?php return [ 'Blesta\\Core\\ServiceProviders\\Logger', 'Blesta\\Core\\ServiceProviders\\MinphpBridge', 'Blesta\\Core\\ServiceProviders\\Pagination', 'Blesta\\Core\\ServiceProviders\\Pricing' ]; OK about mailparse. I'll get rid of the DLL since we won't be using the ticket system.

C:\Program Files\MySQL\MySQL Server 5.5\bin>mysql -u blesta -p -e "SELECT @@GLOBAL.sql_mode, @@SESSION.sql_mode;" +----------------------------------------------------------------+----------------------------------------------------------------+ | @@GLOBAL.sql_mode | @@SESSION.sql_mode | +----------------------------------------------------------------+----------------------------------------------------------------+ | STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION | STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION | +----------------------------------------------------------------+----------------------------------------------------------------+ And in the PHP error logs: A LOT of these: ------------------------------- PHP Warning: A non-numeric value encountered in C:\Blesta\public_html\iC_Loader_Install_1518794082\php_script.php on line 459 Followed by: ------------------------------- Use of undefined constant LOADER_PHP_VERSION_URL - assumed 'LOADER_PHP_VERSION_URL' in C:\Blesta\public_html\iC_Loader_Install_1518794082\php_script.php on line 223 PHP Notice: Undefined variable: is_too_recent_php in C:\Blesta\public_html\iC_Loader_Install_1518794082\php_script.php on line 256 PHP Notice: Undefined index: oscode in C:\Blesta\public_html\ioncube\loader-wizard.php on line 3567 PHP Notice: Undefined index: arch in C:\Blesta\public_html\ioncube\loader-wizard.php on line 3568 PHP Notice: Undefined index: wordsize in C:\Blesta\public_html\ioncube\loader-wizard.php on line 3569 PHP Notice: Undefined index: php_version in C:\Blesta\public_html\ioncube\loader-wizard.php on line 3570 PHP Notice: Undefined index: thread_safe in C:\Blesta\public_html\ioncube\loader-wizard.php on line 3571 PHP Notice: Undefined index: compiler in C:\Blesta\public_html\ioncube\loader-wizard.php on line 3572 PHP Notice: Undefined index: oscode in C:\Blesta\public_html\ioncube\loader-wizard.php on line 3567 PHP Notice: Undefined index: arch in C:\Blesta\public_html\ioncube\loader-wizard.php on line 3568 PHP Notice: Undefined index: wordsize in C:\Blesta\public_html\ioncube\loader-wizard.php on line 3569 PHP Notice: Undefined index: php_version in C:\Blesta\public_html\ioncube\loader-wizard.php on line 3570 PHP Notice: Undefined index: thread_safe in C:\Blesta\public_html\ioncube\loader-wizard.php on line 3571 PHP Notice: Undefined index: compiler in C:\Blesta\public_html\ioncube\loader-wizard.php on line 3572 PHP Warning: require(C:\Blesta\public_html\config\services.php): failed to open stream: No such file or directory in C:\Blesta\public_html\lib\init.php on line 10 PHP Warning: require(C:\Blesta\public_html\config\services.php): failed to open stream: No such file or directory in C:\Blesta\public_html\lib\init.php on line 10 PHP Fatal error: require(): Failed opening required 'C:\Blesta\public_html\config\services.php' (include_path='.;C:\php\pear') in C:\Blesta\public_html\lib\init.php on line 10 PHP Warning: require(C:\Blesta\public_html\config\services.php): failed to open stream: No such file or directory in C:\Blesta\public_html\lib\init.php on line 10 PHP Warning: require(C:\Blesta\public_html\config\services.php): failed to open stream: No such file or directory in C:\Blesta\public_html\lib\init.php on line 10 PHP Fatal error: require(): Failed opening required 'C:\Blesta\public_html\config\services.php' (include_path='.;C:\php\pear') in C:\Blesta\public_html\lib\init.php on line 10 I believe the warning about Pear is related to me adding the DLL for mailparse... but since I don't want Blesta to RECEIVE emails (only SEND them to customers) can I leave out mailparse? NOTE: Using PHP Thread-Safe was recommended AGAINST in WIndows.... (noticed threadsafe mentioned in the error log above)... and is DISABLED in my install.

Yes-- I absolutely copied the files from "hotfix-php71" into the Blesta install BEFORE kicking off the configuration.

Unable to get Blesta to config. Running through the web installer for the app, all I get is a blank white screen after entering in the info requested and clicking the Start Install button. Environment is Windows Server 2012 R2 PHP 7.1 MySQL 5.5 IonCube Loader for 7.1 (Windows VC14 Non-TS 64 bit from here: https://www.ioncube.com/loaders.php ) Modified php.ini for the DLL per instructions (zend_extension = "C:\Program Files\PHP\v7.1\ext\\ioncube_loader_win_7.1.dll") is at top of .ini. phpinfo() shows: API Extensions: mysqli.pdo_mysql PDO drivers: mysql, sqlite cUURL Support: enabled cURL Information: 7.54.1 OpenSSL Support: enabled OpenSSL Library Version: OpenSSL/1.0.2k Used PHPmyAdmin to create a Blesta database in MySQL and created a user with full permissions on it. Everything seems to meet the minimum requirements. Deleted all Blesta files and replaced with a fresh copy from the ZIP downloaded from Blesta for eval. Same results. Some DATABASE tables appear to have been created, from "accounts_ach" thru "log_account_access" (alphabetical order)... so at least SOME of the install routines fired off. Advice, next steps?