I’m a fan of all operating systems, Windows, Linux, and OSX. I just happen to make all these videos I post on a Macbook.. an old late 2006 model, that just couldn’t keep up anymore. I’ve had to retire it, and am excited to be doing these on a new Macbook Pro. I haven’t missed the spinning pinwheels of death one bit. Hopefully this means I can up the production value a bit.. only time will tell.

So this week, just a quick sneak peak at a feature that a lot of people have been asking for.. We call it, Loginless Payments. It’s difficult enough at times to get customers to pay, so this is all about making it as easy as possible to collect, and providing a great customer experience at the same time. A customer may have forgot their password to login, but it’s no longer an obstacle because we have eliminated that step entirely.

When a customer gets an invoice in their email, a special link is provided to pay that invoice. It doesn’t log them into their client area, but it does let them pay without having to login. This link is included in all payment reminders and late notices as well. Click, pay, done.

The video is below, as usual you can make the video full screen, and be sure to turn on your sound (And turn it up! This one turned out a little on the quiet side for some reason).

Tags: client area | loginless | payment | payments | video

In the last developer commentary we took a look at creating a Merchant Gateway to process credit card payments in version 3. Today we’ll do the same for a Non-Merchant Gateway, which allows you to accept payments processed on the payment gateway processor’s own site (think PayPal).

Non-Merchant gateways are really quite basic. There are essentially two elements at play:

1. Creating an HTML form to handle the payment button (NonmerchantGateway::buildProcess() method)
2. Processing logic to handle the payment notification response from the gateway processor (NonmerchantGateway::validate() method)

The video is below, as usual you can make the video full screen, and be sure to turn on your sound.

Tags: gateways | nonmerchant | paypal | v3 | version 3

It’s been a busy week, which is pretty normal.. but extra busy because we’re a man down right now. Tyson does great work here, and the Superior Court of California thought he would do a great job as a juror too. I’m sure he will, and we hope to have him back from jury duty next week to hear all about it. (And also to get back to cranking on Blesta!)

I get a lot of email and phone calls about Blesta, and in talking with people, certain things start to stand out.. like the incredible need for a downloads section in the client area. I was happy to tell several people this week that it will be included in v3.

And then I realized that we haven’t really mentioned this before.

The download manager is a plugin, and here’s what it looks like installed in the staff interface..

Here’s the link it registers in the client interface where all the downloady-goodness appears..

Other plugins can register links here too. So there you have it! Downloads ship with v3.

Thanks for reading, I hope you have a wonderful weekend!

Tags: download manager | downloads | v3 | version 3

Cody did a developer commentary a couple weeks ago on Merchant Gateways, you might find it interesting if you’re a developer (Hey maybe even if you aren’t!).

If you’ve been following us for a while, you’ve already seen parts of the dashboard (For the 1st time in the Staff Calendar video). This time, I wanted to dig in a little deeper and show you how it works, and how flexible & customizable it really is.

If you stick with me, I have some new themes to show you toward the end too.

Some notable items..

1. The dashboard consists largely of widgets. Widgets are plugins which can be created by developers, dropped in and installed.
2. Widgets can be moved around, minimized and customized, unique to the staff account. Everything stays where you left it.
3. Since widgets are plugins, they can register and be included in the staff group ACL (Access Control List). This provides for better separation of staff roles.
4. GeoIP can be enabled in the settings, giving Blesta and all plugins access to geolocation data. The System Overview widget we’ll ship with makes use of it.
5. Drag and drop is awesome.
6. Themes are now extremely flexible, we’ve improved them more since the video we did on them. If you really want to get crazy you can (Warning, may induce vomiting).

The video is below, as usual you can make the video full screen, and be sure to turn on your sound.

Tags: dashboard | plugins | v3 | version 3 | widgets

In this developer commentary, I give a quick tutorial on creating a merchant gateway that supports credit card payments.

As you’ll see in the video, I’ve created a demo gateway to help streamline the process. This, and other payment gateway demos will be made available to developers at the launch of alpha, along with our detailed developer documentation.

We’re really excited about the payment gateway architecture, and after watching this tutorial I hope you will be too. If you’d like to learn more about why the gateway system is designed the way it is, read my post on Designing a Modular System.

Tags: behind the scenes | developer commentary | gateways | payment gateways | v3 | version 3

Last weeks post was titled Tangible Invoices. If you haven’t read it yet, you should check it out, we’re doing some exciting things.

We’ve been slammed lately, code sprinting toward alpha, but I wanted to take a break today and show you something new. So, this week a video on the client area, and some notable items.

1. All new, simple, unique, clean, and professional design built with usability in mind.
2. Staff can login as the client, and return to that client’s profile in the staff interface when done.
3. Fixed width interface, designed with customization in mind. (More on this in the future!)
4. Reminders to pay displayed prominently if any invoices are open. (You’re running a business, right? Get paid, your customer can worry about registering a new domain second. :D)
5. Helpful tooltips and notices displayed throughout.

This is a very basic overview of the core of the client area. Not shown are the ticket system, order system, or portal.. and some other things. (We’ll save those for later.)

The video is below, as usual you can make the video full screen, and be sure to turn on your sound.

Tags: client area | v3 | version 3

If you’ve been following us for long, you know we talk a lot about invoices. Most recently we did a video about Invoice Customization, and our amazing Invoice Auto-Save feature.

From the beginning Blesta has supported paper invoices. Some clients, typically business clients, want to receive their invoices in the mail. For those clients, Blesta can queue up invoices for print. A staff member logs in, prints them out, stuffs them in envelopes, applies postage and drops them in the mail.

v3 has this ability too, but can optionally do so much more. What if your billing staff didn’t have to print out anything? What if Blesta printed, stuffed, and mailed the invoice by itself? In v3, it essentially can, through Postal Methods. Automating the tangible.

Of course invoices by email have long been widely accepted. However, some companies still prefer to receive invoices in the mail — and, if it means you get paid on time, it’s worth just mailing them the invoice. It’s about meeting them where they are. Whether email, postal mail, or fax, Blesta can send out invoices automatically or with just a couple of clicks.

Yet another reason Blesta is the professional choice.

Isn’t that invoice beautiful? It looks great, and it was sent automatically. Did I mention you can include a return envelope too?

Even though more than 95% of our own invoices are sent out via email, this is a feature I’m personally looking forward to in v3.

On another note, we’re getting close to an alpha release. It’s a private release intended for developers only. If you want to build an extension for v3 for your own use to prepare for the upcoming release, or to sell, you might qualify. Extensions include modules, gateways, plugins, and widgets. If you think you should be included in the alpha, email sales at blesta.com and let’s chat.

Tags: blesta 3.0 | invoices | postal methods | v3

With a private alpha release due out soon, we’re gearing up to help developers take full advantage of the 3.0 platform. Our goal is to make it as easy as possible to build really advanced plugins, widgets, gateways, and modules. To facilitate that we’ve written some detailed interfaces and libraries, as well as put together a pretty in-depth developer manual. And while the v3 source is almost entirely open, I figured what the heck, how about some source code documentation? So I created Doctorate.

Doctorate is a simple plugin for minPHP that documents source code using Reflection. Being able to read the source documentation without actually having to open the source code is a huge advantage. But because the Blesta API is just a simple access wrapper for the Models it’s a huge time saver for us. It would take months to document every API request (there are hundreds and hundreds), but Doctorate does it automatically.

Here is a sneak peak of the source code documentation from Doctorate…

Here is a sneak peak at the developer manual…

So when can you expect to get your hands on the developer manual and source documentation? If you’ve made it onto our developer list you can take advantage of these resources as soon as alpha is released. When 3.0 goes into beta we’ll make the documentation public.

Tags: doctorate | documentation | minphp | v3 | version 3

We’ve talked about payments before, but this week I wanted to go a little more in depth. The way payments are handled and applied by a billing system is important, things need to be accounted for.

Some popular billing systems do really strange things, like..

1. Create a new invoice when someone attempts to pay multiple open invoices for the sum of those invoices, and when that invoice is paid mark the others as paid.
2. Allow staff to mark an invoice as paid without recording a transaction.

Simply put, this leads to an accounting nightmare. If an invoice is marked paid, surely there should be a history of how and when that invoice was paid, right? Absolutely! Blesta handles this well in v3, but that’s not a new feature!.. We’ve been accounting for everything since the beginning.

Good billing software will let you pay a single invoice with multiple payments, and pay multiple invoices with a single payment. It should keep track of how much of which payments were applied to which invoices.

In this screenshot you can see that 2 payments were made to a single invoice, and the invoice still isn’t paid in full yet. (Click image to see full size)

It all comes down to this: We want to do things right, and we spend the extra time to do it right when others don’t. It’s this way with everything we do. We engage every feature with purpose and forethought. It’s about creating great software whether we sell a thousand copies or a million copies.

Tags: blesta 3.0 | payments | v3

As lead developer, my primary focus has been on designing an efficient system. Since our primary data store (where we make the most reads/writes) is the database, naturally this is where the smallest change can have the biggest impact. I’ve already discussed a number of changes we’ve made to the database system including switching to InnoDB and the use of PDO. The last is the use of unbuffered queries.

Buffered Queries

Buffered queries fetch (e.g. buffer) all records into memory from the database server and automatically close the cursor, allowing other queries to be executed. You might take this for granted. For example, you may have something like:

// What looks like 'nested' queries...
$statment = mysql_query($sql);
while ($data = mysql_fetch_assoc($statment)) {
    $statment2 = mysql_query($sql2);
    while ($data2 = mysql_fetch_assoc($statment2)) {
        ...
    }
}

This might be all fine and dandy, but assume that the first query finds 1,000,000 rows. If each row contained just 1 KB of data, that’s 976 MB of memory consumed! Keep in mind that the memory is consumed at mysql_query(), so it doesn’t matter how many rows you actually fetch (using mysql_fetch_*). Moreover, the memory isn’t freed until the program terminates or you explicitly invoke mysql_free_result().

Unbuffered Queries

Unbuffered queries, on the other hand, are not buffered into memory. Each row remains on the database server until fetched. This can drastically reduce memory consumption on the web server.

The only downside is that you can’t create what look like “nested” queries (as in my example above). But that really isn’t a downside at all, because it forces you to look at better methods for fetching or querying data. Like limiting your result set and fetching all results.

The Record component in Blesta, in conjunction with PDO, make unbuffered query support almost seamless. You really only need to be concerned about closing the cursor if you’re explicitly working with PDOStatement objects.

// Manually work with the statement...
$users = array();
$user_stmt = $this->Record->select()->from("users")->getStatement();
foreach ($user_stmt as $user) {
    $users[] = $user;
}
$user_stmt->closeCursor();
 
// Or just let the Record component to handle it all...
$users = $this->Record->select()->from("users")->fetchAll();

While the benefit of unbuffered queries may not be entirely evident on small data sets, there’s no doubting it improves efficiency. And that’s what creating an enterprise-level application is all about.

Tags: blesta 3.0 | database | minphp | queries | v3

I came into work this morning with literally no idea what the video was going to be about today. I have a list of topics, but nothing felt right and then I realized we haven’t really talked about currencies much. It’s part of a larger topic, Internationalization, and with what we’re doing with language support and the translator it only makes sense that we should discuss currencies.

Of course, a big part of currencies is multi-currency support and v2.5 has it, but it’s much improved in v3. In v2.5, multi-currency has to be explicitly enabled and everything revolves around the default currency. While v2.5 can accept payments in many currencies, clients are billed based on the exchange rate to the default currency. So, the biggest difference between v2.5 and v3 is that prices can be specified at the package level for each individual currency, effectively fixing prices. Only when a price is not available for the currency does the exchange rate come into play.

1. Prices can be set for each currency at the package level, which overrides the exchange rate.
2. Multi-currency doesn’t need to be enabled, just use it if you want to use it.
3. Exchange rates can be fetched from Foxrate, Yahoo Finance, or Google Finance.
4. Exchange rate updates can be disabled and exchange rates manually updated.
5. New package period options Day, Week, and Year in addition to Monthly and One Time.
6. Cancellation fees can be assessed and configured at the package level.

Interesting fact! With Day, Week, Month, and Year package period options now available, terms can range between 1 and 65535 (2¹⁶ – 1) which equates to 65535 * 4 + 1, or 262,141 possible service terms available. So much for just monthly, quarterly, semi-annual, and annual huh? Do your own thing.

The video is below, as usual you can make the video full screen, and be sure to turn on your sound.

Tags: currencies | multi-currency | pricing | v3 | version 3

In January we announced the availability of a language crowdsourcing project, the Blesta Translator. The goal of the project is to facilitate the translation of Blesta into many languages, and to ship these languages with Blesta, starting with version 3.

This week we made a few additional changes live, and they are –

1. Added Nederlands, NL (nl_nl) to the list of available languages
2. Added a machine translation (Google) for reference
3. Added “In Order” and “For Confirmation” translation methods
4. Added some context to language strings including terms, filename, and type

#2 Machine Translation

The machine translation is available for all translation methods, “Random”, “In Order”, and “For Confirmation”. By default it is not displayed, but will be shown when a link is clicked. The idea is that it may be useful to see the Google translation, but that it shouldn’t be relied on, or copied without forethought.

#3 Additional Translation Methods

The goal of the translator isn’t simply to get translations, but to get good translations.

When different people translate a term identically, it has a higher weight than terms that are only translated by one person. Such terms become “confirmed”, and are trusted to be more accurate. So, the “For Confirmation” translation method displays the best possible translations by other people. One of these translations can be accepted by clicking on it. Alternatively a different translation may be entered like normal.

The “In Order” translation method is pretty self-explanatory, terms are given in alphabetical order with the goal of completing a translation. This means that some terms may be skipped initially until the translation is completed as a whole. Once the translation is completed, terms that were intentionally skipped will be presented.

The end goal is to make several translations available. A version translated wholly by a specific person, a confirmed only translation that may be missing some terms (missing terms are shown in the default language), or a complete translation consisting of confirmed only or both confirmed and unconfirmed terms. The latter are the ones we will include with Blesta by default, but all will be available for direct download in the future.

Thanks for reading! If you know another language, please sign-up and contribute

Video next week? Probably.

Tags: blesta 3.0 | language | translator | version 3

Part of my job in the development of v3 is to take a step back and consider how each and every feature in Blesta can be improved over previous versions. Lots of thought, and many discussions surround even the simplest details of both the external and internal workings of Blesta, the visible and invisible.

Today I want to compare and contrast, and reveal how we handle automation in v3.

v2

Version 2 has a Cron Status & Setup page, under Settings > API/Cron Settings. The intent of this page is to show you when the cron last ran, how to set up your cron, and provide a method by which to run the cron manually. We were the first to secure the cron with a key, preventing it from being run by unauthorized users. Overall very basic, and it works pretty well.

v3

Version 3 does everything mentioned above, but in a simpler, more intuitive way — with the addition of being able to update the cron key right here. This key is now separate from the API key, which it shared in v2.

This is a good replacement for v2, and we could have stopped there.. but like I said in the opening, a lot of thought, many discussions.. and I’ll add, a lot of planning and development time goes into each and every feature.

One thing that bothers me a lot with v2 is that I can’t set exactly when I want a particular task to execute. Some tasks run once daily, some run every x minutes. The daily tasks run every day at midnight, and for the most part, the more frequent ones are at the mercy of how often the cron is scheduled to run.

This creates some issues, first of all is that midnight emails probably don’t have the highest read rate. Secondly, midnight account suspensions for non-payment result in emergency tickets at a time when most of your staff is sleeping or in the shower.

So, the actual cron job should run every 5 minutes, and you should be able to schedule when each task runs. Right? We think so. It’s almost common sense, but nobody has done it until now.

…

Above is what Invoice Creation and Auto Debit tasks look like. In this case, we have them both set up to run at 2pm daily. These are 2 tasks out of more than a dozen.

What about more frequent tasks?

This option illustrates how paid pending services, such as exist when a new order is placed, are provisioned.. every 5 minutes.

In addition to being able to schedule each task, they can also be explicitly disabled.

Developer Candy: Plugins can register automation tasks.

Another important thing to note is that all the times are in your local timezone — or whatever you set your timezone to be, regardless of the server time. Additionally, all dates and times in Blesta everywhere are stored in the database as and converted from UTC, which means you can change your timezone without affecting the stored value.

The default options will be perfect for most people, and there will be no real necessity to dig in and tweak these around.. Really, it’s not that important, but I wanted to show you for two reasons. 1. It’s a neat, practical feature and more importantly.. 2. It gives you a glimpse into how we work, how detail oriented we are, and how serious we are when it comes to usability.

Hope you have a nice weekend. Speaking of weekends…

Nerd Alert: If you play a game called Minecraft, we’ve got a Minecraft server up and running at 74.80.216.146. Come join us, some of our friends, and some of their friends as we build random stuff. HostMaster = Me, Awesomisitist = Tyson, Codelphious = Cody.

Tags: automation | blesta 3.0 | cron | v3

Cody posted an article last week on Software Licensing, which I found amazing. Be sure to check it out if you haven’t already.

This week I’ve got another video, and it’s all about options available for invoices. There are many improvements in v3 when it comes to invoices, so I thought you might like to see what we’ve got cookin.

1. Two all newly designed invoice templates available.
2. Invoice formats are now available. Add a prefix, suffix, and/or the year to invoice numbers.
3. Set or change the next invoice number anytime.
4. Have invoice numbers increment 1 at a time or in multiples, ie Invoice # 5, 7, 9.
5. Pad invoices to a specific length, ie Invoice # 00001, or xxxx1.
6. Add your logo, a background image, and company name and address to invoices.
7. US Letter, and A4 paper sizes now supported.
8. A PAID watermark can now be displayed on paid invoices.

Invoices are flexible yet simple, fully internationalized, clean, and they print beautifully. I’m really happy with the changes we’ve made to invoices since 2.x and I hope you are too!

The video is below, as usual you can make the video full screen, and be sure to turn on your sound.

Tags: blesta 3.0 | customization | invoice | pdf | version 3

Software licensing offers software developers a means of ensuring their product is not installed without prior authorization (generally by purchasing the product). Some competing products offer licensing modules to facilitate the deployment of such software, but their designs are critically flawed in a number of ways. Today I’ll describe the software licensing scheme we use in Blesta 3.0, and why it works. But first, let’s take a look at the problem.

To ensure an installation is allowed to run it needs to established its authenticity. This is generally done by “calling home.” That is, by contacting the licensing server. Information returned from the licensing server varies, but generally contains data about how, when, and where the software can run.

The naive approach

It goes without saying that if the license data can be tampered with one can easily bypass the license check. To resolve this, others have devised a scheme whereby the data is hashed using a shared secret salt know by the licensing server and by the product. When the product receives the license data it creates a hash from the data using the shared secret salt and compares that hash with the one that accompanied the data. If the two hashes match the data is trusted, otherwise the data is rejected.

Some systems don’t even bother sending the original hash of the data and instead compute and store the hash upon arrival for future reference. These systems are even less secure.

There are a number of exploits with these systems:

• Because the same shared secret is used to generate the hash across all installations it may be possible to obtain the shared secret
• Because the hashing method generally used is insecure it may be possible to tamper with the data and still produce the same hash (i.e. a hash collision)
• Because the data passed across the line is unencrypted or poorly encrypted it may be intercepted and the licensing server may be tricked into returning data regarding a separate valid license, or the licensing server may itself be spoofed

Exploiting it

Some may argue the dangers of revealing how insecure systems can be compromised, just as a magician might jeer at the sight of someone exposing their trickery. Those that argue from that position fail to realize that security does not arise out of obfuscation. Shannon’s maxim teaches that one must always assume that an attacker understands exactly how a system operates.

1. Determine where the software calls home to. This can be done by monitoring network traffic or guessing the license server domain.
2. Spoof the licensing server by modifying the server’s DNS or hosts file to resolve to a “license server” you create.
3. Capture the data sent to the licensing server to a log file.
4. Capture the data returned from the licensing server. This can be done by manually passing the data from #3 to the licensing server. Note that if you do not have information to obtain a valid response from the license server, you may be able to obtain that information from another user with a valid license or from a public demo of the application.
5. Return the license data you capture from the license server, or modify it to ensure it continues to function ad infinitum.

The solution

A digital signature allows us to verify the authenticity of a message through the use of an asymmetric key cipher, which uses one key (the private key) to encrypt data and an entirely different key (the public key) to decrypt data. Meaning that an attacker can not reproduce signature data since they do not have the private key.

How it works

1. The license server generates a unique public/private key pair for the installation and delivers the public key securely to the installation
2. The license server then encrypts the license data, generates a hash of the data and encrypts it using the private key to produce the signature
3. The license server then delivers the data and signature to the installation
4. The installation verifies the signature by decrypting the signature with the public key and comparing it with the hash it generates from the data

In the event that the signature can not be verified the license data is rejected and the license becomes invalid. Attempting to spoof the license server does nothing because only the license server can sign messages and the installation will only be able to verify signatures from the license server.

Additionally, at any time the license server may choose to generate a new key pair. This is especially useful because as attacks on asymmetric key ciphers becomes computationally cheaper it becomes increasingly important to cycle keys and/or increase key lengths.

Why are we telling you all this?

It would be great if there were no need for software license validation, but there is and there’s a market for it. Our philosophy is if you’re going to do something you ought to do it right. At the moment, thousands of developers put their software in the hands of licensing systems that provide illusory protection at best, and that’s unfortunate.

So, why are we telling you all this? Because we’re building a licensing plugin for v3 that does it right. We don’t mind sharing with everyone how it works because even licensing systems should be transparent. And, if our competitors decide to rework their licensing systems and do things right — then everyone is better off. And that’s what it’s all about.

Tags: blesta 3 | encryption | licensing | plugin | plugins | v3