Cody

Plugin coming on Monday. See this thread.

There have been a number of threads lately with users asking how to create a shared login system with Blesta. That is, how to log a user into Blesta from Joomla, or Wordpress, or some other system. Since the plugin to do such a thing is so simple, we decided it'd be best if we just create the plugin. So I spent the last 45 minutes or so working on it, and it's about 90% complete. It just needs the management capabilities to configure the shared secret value from within the plugin management interface, and a little more testing. Look for it on Monday, November 25. UPDATE: The plugin is now available. Extract to /plugins/. Documentation on using the shared login plugin can be found here. shared_login.zip

What do you mean by "local traffic"? The only thing I would consider "local traffic" is traffic over my LAN. Anything over the Internet is not local. I have a higher degree of trust in an entity that can prove to me who they are through a mutually trusted third party, than I do for an entity that can't or won't do that. That's really what it comes down to. Regarding backbone traffic, that's completely transparent to both ends of the connection. It doesn't matter to me whether or not the backbone(s) transporting my data to the server encrypts their traffic because by the time it reaches the server the packets are as I sent them. Yes, and that's something I rely on.

Slashdot is where I read it. +1

Why would proxies need to filter traffic? I don't know of any open web proxy that forces users to use unencrypted connections. TOR is a proxy network that, in addition to forcing HTTPS (where possible), encrypts every packet in multiple layers of encryption. While HTTPS may not be perfect, the key exchange (Diffie-Hellman) is still the best way of allowing two anonymous users to exchange encryption keys. While some trust is required, it's infinitely less trust than would be required when transmitting plain-text over the Internet.

Almost all modern CPUs support hardware accelerated encryption. The iPhone5s even does this. Encryption is not necessarily a time consuming process. Block ciphers work by encrypting small pieces (usually 16-bytes) of data at a time, so can easily be streamed. Keep in mind the maximum TCP packet size is 64 KB. Will encryption ever be as fast as plain-text? No, but soon the differences will be negligible and there will be simply no reason not to use it.

I've created the unit tests to process all exchange rate processors. We'll be moving to a daily build process soon which will help us catch these types of issues right away.

There are a number of ways shared login could be handled using a plugin. I mentioned one of them in another thread. Using a plugin would be the most preferable way as it would not require any changes in Blesta. But for those who don't want to or can't create a plugin, disabling CSRF check on client login is the best solution. Another simple way of implementing shared login through a plugin would be to have the plugin generate a unique, time-restricted token for a given user, then redirect the user to the plugin with the token (which could then forward the user to a separate page), or perform an AJAX request on the plugin URL.

Updated to use google's new currency API. CORE-879 fixed in 3.0.7. Overwrite the attached file to use the new API in /components/exchange_rates/google_finance/ google_finance.php

All good points.

Make sure your root web directory is set correctly under [settings] > [system] > [General] > [basic Setup].

You shouldn't haven't to make any code changes in Blesta. In fact, I'd strongly recommend that you don't. What I would do is perform an AJAX request from the user's browser to https://shop.example.com/client/login/ using the user's credentials. To do this, all you need to do is update /config/blesta.php and change Configure::set("Blesta.csrf_bypass", array()); to Configure::set("Blesta.csrf_bypass", array("client_login::index")); If you're feeling fancy, you could create a plugin that you contact via the API that will invoke Users::login() and return the Session ID (Session::getSid()). Then from your caller, you could simply call set_cookie("blesta_sid", "the_session_id", 0, "/", "shop.example.com");

That's an interesting issue. I can tell you there's no easy work around since Blesta will only renew a service if the service could be invoiced. This technique allows Blesta to perform catch up invoicing should the cron be disabled for any amount of time. I wonder if it makes sense for the service that's generating invoices that you don't want to be generated to just be set up as "One-time"? In 3.1 you can tie into the Invoices.add event and void the invoice immediately after it's created, though.

Paul is referring to disabling CSRF token validation for the client login page only. Disabling CSRF token validation on a login form does not introduce any security vulnerabilities. At best an attacker that knows a particular user's login credentials could trick that (or another) user into logging into that system. Of course, if your login credentials are known to an attacker you have bigger problems to worry about.

WHMCS does not validate CSRF tokens on login.

If you have purchased multi-company you may request multi-company for your dev license as well.

Closed as duplicate post.

Well, it's been more than 2 weeks and still no patch from them. I would think, given the severity of the issues we presented to them that they would have released a patch by now. Perhaps those 34 exploits have caused too much work for them?

If you already have services in there that are stored without an order-id then they're not properly formatted to be used as active services. You should mark them as pending, then change them to active (whilst unchecking "use module"). That should correct them.

Version 3.0.6 is now available. You can download it in the Client Area. This is a patch release that corrects issues with 3.0.0. Patching Blesta See Patching Blesta in the User Manual for instructions. Release Notes - Blesta Core - Version 3.0.6 ## Version 3.0.6 2013-11-13 ### Bug * [CORE-611] - Logicboxes Module: Add order-id field to Manage Settings * [CORE-844] - Copy contact information when paying as an unauthenticated client does not work * [CORE-845] - Service pagination results in 404 * [CORE-846] - Client Group 'Allow Clients To Cancel Services' setting is unused and defaults to the company setting instead * [CORE-847] - Subsequent addon services use the qty value of an addon service added before it if one does not exist * [CORE-854] - Plesk: Service plans may not be fetched if using a reseller account * [CORE-856] - Cron: Service renew date may update if add invoice fails * [CORE-858] - Recurring coupons are not applied * [CORE-859] - Currencies::add() should always return void * [CORE-860] - Import Manager: Blesta 2.5 migrator creates error if currency already exists * [CORE-863] - Resetting password shows success message when no username is given * [CORE-864] - Cannot delete a pending or in review service from the billing section * [CORE-865] - Order plugin: Order form package WYSIWYG descriptions inheriting invalid styles for OL, UL * [CORE-866] - Adding service with a coupon resets coupon used quantity to 1 * [CORE-868] - Coupon discount not affected by service quantity * [CORE-869] - Create Client Group missing "Suspend Services Days After Due" select values * [CORE-870] - Authorize.net gateway does not set x_invoice_num * [CORE-871] - Transactions::getTotalCredit() lists $currency as optional * [CORE-872] - API fails to return false equivalent values * [CORE-875] - Delete client group always reassigns clients to group ID 1 ---

Yes, forgot to update the date. There are speed improvements as mentioned in the "What's new" section for b8.

Moved to bugs. Looks like a couple separate issues here: 1. Documentation error ($currency is not optional). CORE-871. 2. API is failing to output results that are equivalent to false (e.g. 0, false, null), returning void instead. CORE-872. Both fixed in 3.0.6.

Updated migrator now available. Get beta version 8 here.

It's always better to create an override CSS file. Then edit the appropriate structure.pdt file to include. We have plans to add support for setting custom CSS/javascript files to load into structure.pdt without editing structure.pdt.

We'll try to duplicate and come up with a fix.