There are two prevailing factors that determine how well a software product can adapt, improve, and be extended without imploding in on itself. They are:

1. Coupling, and
2. Cohesion

Coupling represents how dependent a given module is on other modules within the system (I use the term “module” in this article in an abstract sense to describe an object or set of objects that are designed to accomplish some task). A loosely coupled module doesn’t rely or expose much of its inner workings to other modules. Conversely, a tightly coupled module relies heavily on other modules and may expose portions of its inner workings so that other modules may interact with it.

Version 3 of Blesta is built on top of an MVC (Model-View-Controller) framework, which, as the name suggests, separates control into three distinct areas. Building off of an MVC framework (in our case, minPHP) gives us the discipline needed to maintain a loosely coupled system. But it’s not without its challenges. For example, as I’ve mentioned in a previous article explaining data validation, error handling can be handled in a number of ways, but the best way is this through message passing. This allows the errors of a model to be accessed and interpreted without the controller having any direct knowledge of the model or how it works, and vice versa, thus maintaining a loosely coupled relationship.

Cohesion relates to how well the various functional elements of a module are related. High cohesion requires that the module be, in a sense, single-minded. In other words, a class may have high cohesion if all of its methods are closely related. Low cohesion means that a module attempts to accomplish too many tasks, or relates to multiple distinct sets of data.

When designing a modular system, we strive for high cohesion because it improves readability and comprehension of a particular module. If a module attempts too much it becomes bloated, disorganized, and difficult to maintain.

This works hand in hand with coupling. As each module becomes more refined it generally becomes more independent, or loosely coupled. A perfect example of this is the payment gateway system in version 3, which consists of four merchant gateway interfaces (Credit Card, ACH, off-site Credit Card, and off-site ACH). Each interface is designed to accomplish a distinct set of actions (high cohesion), and each payment gateway is thereby only associated with the rest of the system through the implemented interfaces (low coupling). This allows us to create a wide variety of payment gateways that can process credit cards only, or ACH payments only, or any other combination of interfaces without requiring any changes to any other parts of the system.

Tags: blesta 3.0 | cohesion | coupling | design | minphp | version 3

ACLs (Access Control Lists) allow refined control over resources in Blesta v3. There are a few notable differences in the way ACLs are implemented in Blesta vs other applications.

1. Plugins can easily register resources into the permission system to be controlled within the Staff Groups settings page for seamless integration.
2. The permission system automatically ties into the primary and secondary navigation elements, so even custom controllers can take advantage of the ACL.
3. The ACL library can be invoked directly for even more refined control. You can design your own hierarchy of permissions and explicitly deny or allow any resource.

In this video, I touch on some of the basics. The ACL currently has 87 resources, but we’ll likely have over 100 in the initial release for the core. The Order and Support plugins will add to that.

Tags: Access Control List | ACL | blesta 3.0 | staff | staff groups | version 3

i18n, or internationalization, is the process of adapting software to be deployed around the world. Since version 1.0 we’ve dedicated a large portion of our time to making Blesta an international product. And in version 3 we’ve gone even further by enhancing our multi-language support.

To start, you’ll notice language definitions are now diffused across multiple files. This serves two purposes. First, it promotes congruency between objects and their associated language (each Controller and Model has its own language file). Secondly, it allows us to load only content that is relative to the resource being requested. This saves memory, speeds up load times, and makes development much easier.

Syntax support has also been greatly improved. Previous versions supported tag replacement, but many phrases and sentences were graphed or concatenated together. This meant that some translations were left with incorrect syntax or awkward phrasing. We were able to do away with that thanks to minPHP’s Language support.

Here’s an example, flashing a success message after having saved a staff group:

// Success
$this->flashMessage("message", Language::_("AdminSystemStaff.!success.group_updated", true, $this->post['name']));
$this->redirect($this->base_uri . "settings/system/staff/groups/");

Here’s the related language definition:

$lang['AdminSystemStaff.!success.group_updated'] = "The staff group, %1\$s, has been successfully updated!";

And the visual result:

In addition, version 3 offers automatic fall-back language support in the case of missing definitions.

And finally, we’re introducing translation support for modules, gateways, plugins, and widgets. Everything is translatable. Let’s see how long it takes the competition to catch on.

Tags: blesta 3.0 | i18n | internationalization | minphp | version 3

In this developer commentary, I give an in depth look at how AJAX events are handled in version 3 and how you can include them in your own widgets or plugins.

The technology employed here allows us to seamlessly update the state of the browser when performing AJAX requests. This permits the user to navigate using the browser’s back and forward buttons while at the same time offering backward compatibility with normal requests for the same resource.

The context of this video is technical in nature and best suited for viewers with a strong understanding of PHP, minPHP, javascript, and jQuery.

Click the icon in the bottom right of the video player to go full screen.

Tags: ajax | behind the scenes | blesta 3.0 | developer commentary | minphp | version 3

Blesta 3 offers a huge collection of programming tools for developers. From encryption to session handling, and everything in between. Today we’ll focus on the ins and outs of input validation using the Input component packaged with minPHP.

Input validation in version 3 is clear, concise, and modular. Rules reside within the business logic (the model). The benefit of this design is three fold:

1. No (or at least reduced) redundancy
2. Increased readability/writability
3. Reduced testing/less bugs

Some may argue the benefits of input validation from the first source (i.e. the controller). The folly of this design is its complexity and redundancy. Suppose a client can sign up through an order form, through a signup form, or be created by a staff member. Now you have three locations to test, update, and debug each time a business rule changes (for example, phone number is now required). Now suppose you need clients to be created through an API. Adding a fourth set of rules is just plain silly. A client is a client, regardless of where they originate, so why not consolidate all of this?

“Well, Cody,” you might say, “a phone number is only required when a client places an order so we need separate rules.” Hogwash! Add a parameter to your Clients::add() method to identify a signup via order to set the phone number rule as required.

Let’s look at a few examples.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

<?php
// /app/models/clients.php
class Clients extends AppModel {
	public function __construct() {
		Loader::loadComponents($this, array("Input"));
	}
 
	public function add(array $input) {
		// Input is coming straight from POST
		$rules = array(
			'first_name' => array(
				'empty' => array(
					'rule' => "isEmpty",
					'negate' => true,
					'message' => $this->_("Clients.!error.first_name.empty"),
					'post_format' => "trim"
				)
			),
			'last_name' => array(
				'empty' => array(
					'rule' => "isEmpty",
					'negate' => true,
					'message' => $this->_("Clients.!error.last_name.empty"),
					'post_format' => "trim"
				)
			),
			'email' => array(
				'format' => array(
					'rule' => "isEmail",
					'message' => $this->_("Client.!error.email.format"),
					'post_format' => "trim"
				)
			)
		);
 
		$this->Input->setRules($rules);
		if ($this->Input->validates($input)) {
			// Insert into the database, email, or do anything else needed when a client is added
		}
	}
}
?>

Let’s break this down.

• Line 5 loads the Input component (in reality this is already done in AppModel, but you ought to know how it happens)
• Lines 10 – 34 define our rules. For those who’ve worked with cakePHP this will look somewhat familiar.
• Lines 11, 19, and 27 are the indexes of the input data from our input array parameter. Evaluating arrays would look something like ‘addresses[]‘, or ‘addresses[][city]‘, etc.
• Lines 12, 20, and 28 begin individual rule sets. The labels here are superfluous (we could use numerically indexed elements instead), but these help us understand what’s expected of the rule. Any number of rule sets can be added.
• Each rule contains two necessary components:
  1. The ‘rule’ index, and
  2. The ‘message’ index
• The first defines how the input is evaluated. If the rule returns true the validation passes, if false, the validation fails. The message is what’s set for the error upon failure. In this example, and throughout Blesta, messages are language definitions which are translated before being set ($this->_() maps to Language::_()).
• Lines 14 and 22 tell the “isEmpty” rule to negate the response. Obviously we don’t want to require first and last names to be empty. Instead we want to ensure non-emptiness.
• Lines 16, 24, and 31 perform a formatting action on data after the rule is evaluated. Conversely, there’s a ‘pre_format’ action that formats the data before the rule is evaluated. Both ‘pre_action’ and ‘post_action’ work just like ‘rule’.
• Line 36 prepares the rules for evaluation
• Line 37 runs the validation, setting any errors that are encountered into the Input object, accessed via Input::errors(). AppModel defines a public method called “errors” to grant access to these errors from our controllers. As you’ve probably deduced, Input::validates() returns boolean true if validation was a success and false otherwise.

In the above example, all of the rules are defined within the Input component, but rules can consist of PHP functions (as seen on line 16), callbacks, or even boolean values. In addition, a rule can also define parameters. In any case, however, the first parameter to the rule is always the input value.

Below we look at an example of a rule set where the phone number is conditionally dependent on a method parameter, with a more complex rule.

35
36
37
38
39
40
41
42
43
44

		if ($order_signup) {
			$rules['phone'] = array(
				'format' => array(
					'rule' => array(array($this, "isPhone"), $input['country']),
					'if_set' => true,
					'message' => $this->_("Client.!error.phone.format"),
					'final' => true
				)
			);
		}

Notice we now have a couple new actions. The ‘if_set’ action allows the rule to be executed if and only if the field is set. The ‘final’ action tells us that if this rule does not pass evaluation then there’s no point in evaluating any other rules. Similarly, there’s another action called ‘last’ that will cease evaluating rules within a particular rule set (that is, for a single field).

Our rule is to execute a public class method and pass an additional parameter which will help us determine the correct format for the phone number based on the country. The signature of Clients::isPhone would look something like this:

public function isPhone($number, $country)

As you’ve seen, the Input component allows us to reuse code (one of the main goals behind object oriented programming), reduce redundancy, and create readable rules quickly and easily.

Tags: blesta 3.0 | data validation | input | minphp | version 3

Browsers have come a long way in preventing malicious scripts from compromising a user’s system, but XSS (Cross Site Scripting) still poses a security threat for developers. In version 3, we make use of a couple libraries packaged with the minPHP framework and recommend you do the same with your plugins, modules, or gateways. They are the Html and Form helpers.

In the previous article I showed how to eliminate SQL inection, but what do you do when a user submits some XSS code through a web form? Obviously parameter binding won’t help you there, so what do you do? Nothing. Well, at least for now, and here’s why:

1. Sanitizing input for XSS is expensive (both computationally, and economically). Web technologies change very frequently. What if W3C decides to add an “ontrippleclick” event?
2. Not all form data will end up in an HTML document. Some data is destined for emails or 3rd party APIs.
3. Sanitizing may make the data less or unsearchable by the database engine.

So when do we deal with this potentially hazardous data? Why, when we render it of course. And here’s how that’s done:

<div>Name: <?php $this->Html->_($name);?></div>

In the above example, Html::_() both sanitizes and prints the data, but we can force it to return the sanitized output by setting the 2nd parameter to false. Neat-o.

When used in a form, the Form helper will take care of drawing the form field and sanitizing the data.

<div>Name: <?php echo $this->Form->fieldText($name);?></div>

One thing to note is that we’re not destroying the XSS, we’re simply treating it as plain-text within an HTML document. While this takes care of most scenarios, there are some instances the Html helper can’t help you with. One such case is in dealing with the href attribute of an anchor tag. As a programmer you simply need to be aware of such pitfalls and address them accordingly.

Tags: blesta 3.0 | minphp | version 3 | xss

SQL injection is a serious concern for developers, and there are a number of ways of dealing with it; however the best, and most proven method, is through parameter binding. What parameter binding does is substitute variable data within a query with parameters, which are then replaced by the database driver during query execution. Since the database driver is intimately aware of which parts of the query are parameters it can parse the query and then execute it with the bound parameters safely set.

The framework that Blesta 3 is built on, minPHP, handles parameter binding through use of the PDO extension. But because writing queries is tedious and prone to typos, minPHP offers a database access object to interface with PDO in the Record class.

A query that would otherwise looks like this…

 
$this->query("SELECT `users`.`first_name`, `users`.`last_name` FROM `users` WHERE `id`=?", 3);

becomes…

 
$this->Record->select(array("users.first_name","users.last_name"))->from("users")->where("id", "=", 3);

No need to worry about syntax, semantics, escaping data, or back-ticks. That’s all handled by the computer, which loves performing tedious operations over and over.

We’ll look at how to overcome cross site scripting (XSS) vulnerabilities next week.

Tags: blesta 3.0 | minphp | security | sql injection

We’ve got a video for you today, the first in what will likely be a larger series. This video focuses on the aspect of manual invoice creation. (Not to be confused with automatic, recurring service invoice creation, which Blesta handles well too)

There are a few notable new features in v3 from previous versions.

1. Draft Invoices, with automatic saving
2. Voided Invoices (replaces deleting invoices)
3. Quantities, including fractional quantities
4. Sub-total, tax, and total preview
5. Line item drag-n-drop sorting
6. Additional optional invoice delivery methods, like Interfax and PostalMethods
7. Standalone recurring invoices (Do not require a package or service)
8. Dynamic custom invoice numbering system (prefix/suffix, etc)
9. Invoice delivery logging, date/time and method of each delivery

*Please note that features are subject to change. Blesta v3 is currently in active development.

Turn your sound on, and let us know what you think.

Tags: blesta 3.0

Blesta treats mountains like so much dirt! –I have a framed copy of a magazine ad in my office that has a similar slogan. First 2 people to send me a picture of that ad get a free owned license of Blesta! sales -at- blesta.com UPDATE! Both licenses have now been claimed. Thanks to all who participated!

When can I rock out with v3?

Let’s give it some context. v3 is a complete, ground-up rewrite. All of the back-end, and all of the front-end. It’s completely object-oriented. It’s powerful, and intuitive, and customizable, and developer friendly. It has a ton of new and improved features, many of which we couldn’t even consider adding to the old codebase, due to inherent limitations.

It’s coming together really, really well. I’m excited, it looks amazing. It’s the best thing we’ve ever done. But, we still have some work to do, we’re not quite there yet. We have internal goals and deadlines, and we have a pretty good idea when v3 will be ready.. but the last thing we want to do is take shortcuts and fall short of the standard we’ve set to make a deadline. So, we’re keeping those internals confidential for the time being, they are afterall subject to change, if it favors a better product.

But, I promise to keep you in the loop as much as I can. As we get closer and closer we’ll start streaming out information more quickly. I really cannot wait to get v3 in your hands.

Alright, now it’s time for some dessert.

This is a (scaled down, I know) screenshot of the Client Overview page. While this is an entirely new and improved design, it still feels like Blesta, and most actions are performed here just like 2.x. As soon as you get your hands on v3, you’ll feel right at home. Completely rewritten, yes. New and improved features, yes.. but it’s still Blesta, it feels like Blesta.

You may have noticed that the colors have changed slightly. The default color scheme is going to be this shade of blue, the official Blesta blue. Bolder.

One thing I don’t believe I’ve mentioned is how dynamic the new interface is. Staff can customize their experience with drag-n-drop elements that we call widgets. Changes are persistent, so when you come back those windows will be just where you left them. We realize different staff members have different responsibilities, so it only makes sense that the interface should adjust.

That reminds me.. we’ve talked a little bit about color themes. Here’s a few that will likely be shipping with Blesta. Them aren’t images either, these colors are made up purely of glorious hex codes which means a limit of 16 million colors. I call it gradient magic. Whoa I feel like I just lined up some ipods.

I’ll have more for you soon.

Thanks for reading, the future looks great!

Tags: blesta 3.0

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.

Tags: blesta 3.0 | design

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.

Tags: AES | blesta 3.0 | encryption | RSA | security

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

Tags: blesta 2.5 | blesta 3.0 | Mobile OTP | OTP | TOTP

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.

Tags: api | blesta 3.0 | minphp | MVC | REST

           _       _____  _    _ _____
          (_)     |  __ \| |  | |  __ \
 _ __ ___  _ _ __ | |__) | |__| | |__) |
| '_ ` _ \| | '_ \|  ___/|  __  |  ___/
| | | | | | | | | | |    | |  | | |
|_| |_| |_|_|_| |_|_|    |_|  |_|_|
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.

Tags: blesta 3.0 | minphp | php framework

Suhosin is a (somewhat) commonly installed PHP module used by shared hosting providers to prevent (to some degree) malicious PHP code from compromising a shared environment.  Sounds great, but the problem is it spreads its tentacles into areas where, if unaware of its presence, can cause some very unexpected results.

This was the case in Blesta, until recently.

The issue experienced in Blesta was related to session handling.  Blesta uses a database to maintain session information, for added security and to permit load balancing.  Normally, a session ends when the user closes their browser, however it can be revive if a cookie is stored on the user’s machine and is then read when they revist the site.  But because Suhosin encrypts session data by default, our revival code had access to only encrypted data.  Essentially, the session couldn’t be revived.  The only way to decrypt the data is to have Suhosin do it.  So what we did was rename the session prior to starting it, which tricks PHP into thinking the session never ended, and so Suhosin takes over and decrypts the Session just in time.

The psuedo code looks something like this:

$session_id = $_COOKIE['session_id'];

session_name($session_id);

session_start();