We’ve kept the new v3 design under tight wraps, mainly because we love surprises of the awesome variety. If you clicked over hoping to see the entire castle you’re not alone. All will be revealed in due time.

Alright, now that we’re past the formalities, I want to show you a screen capture of the Services box. This box appears on the client page, within the admin area. (Note! 660 pixels isn’t very many. Click for a wider version.)

The first thing I notice about this is the blue color.. maybe it’s the same for you. The cool thing about the color theme is that you can change it. In the interface. It might not ship blue either, there’s some internal turmoil over this and I’ll leave it at that.

Second, you might notice the icons along the left for the services. The green check mark is pretty self-explanatory, but what about the clock icon? Scheduled for cancellation. That’s right, that service has been scheduled for cancellation for some point in the future and when that date rolls around, it’s toast.

Third, you might be thinking.. I clicked on the wider version, and it was wider.. does that mean?! Yes it does, v3 scales to fit your web browser. Boxes like the Services box scale up and down depending on your browser resolution. v3 makes the most of the real estate you give it.

I could mention what that icon is all about in the upper right, or the one that only appears in the wider screen, but I’ll let your own mind take you down that rabbit hole.

Thanks for reading, and for your interest in Blesta. We’re cranking away on v3 and we hope you’ll love it as much as we do.

If you have any thoughts you’d like to share, email me.. sales@.. well, you know the rest.

Until next time.

Security is a constantly evolving field in computing. Following Moore’s law, computational power essentially doubles every 18 months. Even brute forcing strong encryption algorithms can become, at least theoretically, feasible over the span of a decade.

With Blesta 3.0, we’re looking into the future. — way into the future. We’re designing security measures today that will easily keep data secure beyond 2030. Why? Because even if you never update your software, your data should continue to be secure long into the future.

So how do we do it? By using trusted, non-proprietary ciphers such as AES and RSA, with large keys, we’re able to protect data from brute force attacks. To encryption algorithms, the larger the key the more secure the encrypted data.

Why would you need to encrypt a credit card in such a way that it’s safe from attacks for 20+ years? The answer: You wouldn’t. Credit cards generally expire less than 10 years after issuance. But nevertheless, why take the chance?

Here’s how it works in Blesta 3.0:

Credit cards are encrypted using RSA, a public key cipher. This allows cards to be encrypted using one key (the public key), and only decrypted using a separate private key. This facilitates adding card numbers to the database without requiring admin approval or storing a private key on the system. Depending on your specific security requirements, you can choose to store the private key on your system (encrypted of course), to allow automatic payment processing, or you can choose to set a passphrase that must be entered whenever you wish a card to be decrypted.

Setting a passphrase for your private key is optional, but adds an additional layer of security. A passphrase can be added or removed at any time, without having to decrypt and re-encrypt credit cards. So your passphrase can be changed on a regular basis, which is always a good idea — especially for larger organizations.

Some merchant gateways are now allowing credit card numbers to be stored within their own secure systems. Invoking a charge is as simple as passing in a unique identifier, and the amount to be charged. We’re building support for this into version 3.0 as well..

In addition to credit cards, module data can also be encrypted

Blesta handles security in other areas well too, including XSS (Cross Site Scripting) and SQL Injection attacks and we’ll touch on these in a future article.

Blesta 3.0 is currently in active development.

Last week I discussed the new API design in Blesta 3.0.  This week I wanted to touch on the topic of two-factor authentication.

Two-factor authentication requires that a user wishing to sign into an account enter both something they know (a username and password) and something they have (a physical token).  There are many different methods of proving a user is who they say they are, but one of the best and easiest to use is one-time passwords.

Since most users reuse and tend to never update their passwords, if one system is compromised an attacker may have access to all systems the user has access to.  To solve this issue, OATH published the HMAC One-Time Password Algorithm (RFC 4226), and the TOTP addendum (a time based OTP algorithm).

TOTP requires that a user enter a 6 or 8 digit code that changes every 30 seconds, and once a code is used it can’t be used again.  All a user needs to do is share the secret key on their TOTP device with the server they want to authenticate with and they’re ready to go.

We were so excited to include TOTP, as well as Mobile-OTP, with Blesta 3.0, we had to port it over to 2.5.  And here at the office, we can’t imagine how we ever lived without it.

For the iPhone we recommend the following apps:

OATH Token – TOTP token

iOTP – Mobile OTP token

This is the first article, in what will be a series for Blesta 3.0, our next major release. When we sat down to discuss the primary goals of Blesta 3.0, one of the first topics to come up was API design.  The two major issues we discovered with the original API design (of 1.0) were that:

1. It was limited in its capabilities
2. It was difficult and cumbersome to update

By implementing Blesta on top of an MVC framework (minPHP) we were able to create an automatic API, which eliminated both of these issues entirely.  Within an MVC application the model contains all of the business logic, so the only thing required to complete the API is a controller to handle access to the various models.  Since models are objects, the API controller can instantiate and access all of the public methods within a requested model.  This facilitates requests on logical objects that may perform specific actions.

In addition, the API controller could now fulfill requests in any number of various formats (e.g. json, xml, etc.).  The syntax was simple: /api/model/method.format.

The only thing necessary to complete the RESTful design were HTTP status codes, and the API controller easily handled those.  The result is an automatic RESTful API system, that not only grants access to the Blesta core, but to the back end of any plugins installed within that copy of Blesta as well.

In case you missed it, this means that ALL public model methods will be accessible through the API. We’re really excited about the new API and how much support it lends to developers.

Blesta 3.0 is currently in active development. A release date has not yet been determined.

           _       _____  _    _ _____
          (_)     |  __ \| |  | |  __ \
 _ __ ___  _ _ __ | |__) | |__| | |__) |
| '_ ` _ \| | '_ \|  ___/|  __  |  ___/
| | | | | | | | | | |    | |  | | |
|_| |_| |_|_|_| |_|_|    |_|  |_|_|
framework

minPHP is an extremely lightweight, object oriented MVC PHP framework brought to you by the same people who developed Blesta. minPHP is free, open source software released under the MIT license.

Download it at minphp.org.

One of the most awesome things about minPHP, aside from the fact that it’s awesome in itself, is that it’s being used as the framework for Blesta 3.0. Blesta 3.0 is in active development, with a release expected in the early part of next year.

We’re excited to be able to offer something to the open source community, and if you’re a developer we hope you give minPHP a try. As an added benefit, if you’re familiar with minPHP you’ll be a Blesta 3.0 development rockstar right out of the box.

Ooh, my spider-sense is tingling.