Neocodex Technology Blog

As mentioned in this news post, Neocodex now uses Secure Sockets Layer (SSL) to protect our users from eavesdropping attacks that may occur from using unfamiliar/insecure networks.

But how did we get it all set up?

Modern-day SSL essentially offers two benefits to the end user:

• Security: Encrypts the traffic between client and server so that a third-party cannot eavesdrop on the data.
• Trust: Lets the end user know that the identity of the organization using SSL has been verified.

It is possible to implement the former without the latter using self-signed certificates, but we wanted both of these benefits. Because of this, we needed to be issued a certificate from a reputable Certificate Authority (CA) who could verify our identity.

First we needed to generate a private key on our server (*.key file), and then create a Certificate Signing Request (CSR) using that key. This request is then provided to the CA, and once our identity has been verified, a certificate is provided to us in the form of a *.crt file. Our identity was verified using our domain and IP information, as well as having a valid e-mail address associated with our domain. Many CAs go a step further in their background check, but we simply wanted basic assurance for our users instead of nothing at all.

So now, here's where things get a bit technical. We now needed to give our web server enough knowledge so that if anyone wants to connect to us using SSL (by having https:// in their URL bar), it can take care of all of that for us. The things we needed to provide to our web server are:

• Neocodex's private key (*.key), and neocodex's certificate from the CA (*.crt) combined into one file with extension *.pem
• The Certificate Authority's own certificate (ca.crt) -- you can find this publicly available on their website.

In lighttpd, this can be done with the following code (inside lighttpd.conf):

$SERVER["socket"] == ":443" {
ssl.engine = "enable"
ssl.ca-file = "/path/to/ca.crt"
ssl.pemfile = "/path/to/neocodex.pem"
}

Now, some complications arise when you want to enable SSL on multiple domains. We run a separate site that we sell Neocash from, and so we generated a *.pem file for that domain as well. But, we need to tell lighttpd to use the correct pem file for each domain. This technique is called Server Name Identification, and is implemented in lighttpd the following way:

$SERVER["socket"] == ":443" {
ssl.engine = "enable"
ssl.ca-file = "/path/to/ca.crt"
ssl.pemfile = "/path/to/neocodex.pem"

$HTTP["host"] =~ "neocodex.us" {
ssl.pemfile = "/path/to/neocodex.pem"
ssl.ca-file = "/path/to/ca.crt"
}

$HTTP["host"] =~ "otherdomain.com" {
ssl.pemfile = "/path/to/otherdomain.pem"
ssl.ca-file = "/path/to/ca.crt"
}
}

Notice that we reference neocodex.pem twice -- we have to give lighttpd a default pem file to use if neither of these domains are requested, so we use neocodex's certificate if all else fails.

And that's it! After restarting lighttpd, any requests made to https://www.neocodex.us/* are encrypted using a 256-bit algorithm.

Neocodex has recently started to sell Neocash cards through its store with immediate delivery. In this blog post, I want to take you through the history of how we got here, and how we implemented the immediate delivery solution that is custom to our website, and unique to all Neocash delivery services on the internet.

On April 16, 2012, Pyro699, one of the admins on our site offered to purchase Neocash for our members. The system was completely manual. Users would post in the thread, and Pyro699 would go to the store to buy the Neocash card for the user. The delivery would be made through a PM. The whole process would take a few days, depending on how long it took to go to the store at a convenient time. In the three months that the service was available, Pyro699 sold $215 worth of Neocash cards, plus a small fee.

On July 31, 2012, we evaluated the Neocash selling system that Pyro had set up and saw that it had generated quite a bit of sales. We decided to make things a bit more official and move the service into our store. The process was still the same, however: Pyro699 would go to the store whenever an order was generated and deliver the Neocash code through the PM system, manually. The service was available for three weeks and we sold 4 $10 Neocash cards, and 8 $25 Neocash cards, for a total of $240 plus our fee.

On August 19, 2012, we wrote a simple plugin to take things one step further and introduced a system that would deliver the Neocash card codes immediately without requiring users to wait for us to go to the store. It required us to keep an inventory of Neocash codes on hand and write a custom trigger for our e-commerce software, IP.Nexus.

To get an idea of what a custom action looks like, we've reproduced some of our code here:

<?php

/**
 * Externally instantiate the IPS API
 */
define('IPS_ENFORCE_ACCESS', TRUE);
define('IPB_THIS_SCRIPT', 'public');
require_once('/var/www/html/forum/initdata.php');
require_once(IPS_ROOT_PATH . 'sources/base/ipsRegistry.php');
require_once(IPS_ROOT_PATH . 'sources/base/ipsController.php');

class custom_actions_neocash {
    public function onPurchaseGenerated($member, $package, $invoice, $purchase) {
        /*
         * settings -- we might want to change these
         */
        $this->from_member_id = 34316; // pyro
        $this->low_stock_value = 1; // how many items remaining in our inventory constitutes a low stock alert?

        /*
         * Instantiate the IPS registry
         */
        $this->registry = ipsRegistry::instance();
        $this->registry->init();

        if(!$this->messengerFunctions) {
            $classToLoad = IPSLib::loadLibrary(IPSLib::getAppDir('members') . '/sources/classes/messaging/messengerFunctions.php', 'messengerFunctions', 'members');
            $this->messengerFunctions = new $classToLoad($this->registry);
        }

        /*
         * Set up a shorthand for the database connection
         */
        if(!$this->DB) {
            $this->DB = $this->registry->DB();
        }

        /*
         * Which package did the user purchase?
         */
        switch($package['p_id']) {
            case 8: // 1000 neocash
                $value = 1000;
                break;
            case 9: // 2500 neocash
                $value = 2500;
                break;
            case 15: // 1500 neocash
                $value = 1500;
                break;
            default:
                $this->send_out_of_stock_pm($member['member_id'], 'unknown package');
                return;
        }
    }
}

?>

A lot of the code has been omitted for brevity. All it does after what has been shown is pull the Neocash code from the database and send a PM to the user. To understand how to do this, you can consult the IPB API:

• Sending private messages
• IP.Nexus custom actions

The system has some work left to do. If you didn't notice, purchasing multiple Neocash cards at the same time might not work yet. Furthermore, we have to make sure that the number of cards reported to be in stock is updated at every transaction, just in case. We don't want to report that there are cards in stock when there aren't.

While there is some work to do with the system, the basic framework is there to support immediate delivery of Neocash card codes . Hopefully this post gives you a bit of insight about what it took to get a product from start to (almost) finish on Neocodex . Expect more posts about the technological backend of Neocodex to follow .