Delegated authentication

Over the next few days we are going to talk about delegated authentication. For modern standards this falls under “What you know”. See What is authentication for further discussion.

To illustrate what delegated authentication is we will start with an all too common story. We introduce you to Mary

Mary loves social media, uploading her pictures on facebook, instagram and then tweeting them. However she is a very busy lady and does not like the work of uploading the same file to multiple servers.

As a tech savvy developer eager to impress your skills on her, you figure you can help her automate this task. The most easiest way forward would be to ask her for passwords for her three accounts then, when she uploaded a picture to your service, your service would automatically post it on all three platforms.

You immediately hit a snag with this approach, as it turns out Mary is not particularly fond of giving her password out to strangers no matter how tech savvy!

On further inspection you find out this is because she is afraid you will not only post the photos she has instructed you to, you will also go through her other stuff.

But what if you could assure her that you need access to posting photos only and not to the rest of her stuff. Prior to 2006 this just wasn’t possible but today that is exactly what delegated authentication does.

In delegated authentication you are the owner but not the direct consumer of a certain resource. To continue we must first define some key terms used in this paradigm.

  • Resource: A digital activity or data in our case this would be posting the photo
  • Delegator: This is the owner of the resource in our case here, that would be Mary
  • Delegate: The delegate wants to access the resource
  • Service provider: Hosts the resource and validates legitimacy of the delegate

It is entirely possible to build out your own delegated authentication service, however you are likely to run into interoperability problems pretty quickly. Thankfully there exists standards for this kind of authentication we will be speaking about in a later entry.

Signup to make sure you don’t miss it.

Have you ever been in the same situation as out tech savvy developer? How did you handle it? Talk to us in the comments below.


Common implementations of MVC pattern

As far as design patterns go, MVC is the most well known pattern.


This component contains the data structures and logic that are unique to your business. That is what the application does to add value.

Examples of this would be your firebase models.


This component interacts with the users of the application.An example would be the html rendered in the browser.

Ideally, the view should listen for changes in the model and respond to them.Most modern Javascript frameworks allow you to do this.


The controller processes requests incoming from the user and sends them to the model as commands.

Of course the pattern is a general principal. To its end a couple of popular implementations have emerged which we will look into in brief.


In this pattern the controller writes out a request to shared file such as a dot file. A daemon running in the background would then read this file and perform an activity based on it.


This particular pattern is best illustrated by the print spool. The front end (your machine) drops files to be printed in a spool area. A printer daemon running in the background watches for new files and send them out to the printer. Once the job is done, the file is removed from the spool area.

It is noteworthy that this pattern would work well with jobs that would benefit from batch processing.


In this pattern the driver provides commands and interprets output from an engine after startup. An example of this would be where a utility meant to periodically fetch content from say ten different websites starts up curl in the background and uses it to do the actual fetching.


This is the browser/server pair where requests are sent to a daemon running in the server such as nginx which then processes the request and sends a response back.

This pattern can be thought of as an implementation of the Driver/Engine pattern.

Do you know of any other implementation of the MVC pattern? Talk to us in the comment section below


Simple Software Estimation

Estimating how long it will take you to write software is a crucial yet often ignored skill. No matter the size of the project, it’s good to get into the habit of estimating your projects.

You don’t really need a complex system to achieve this. Here is a sample of a simple spreadsheet to get things of the ground.

Simple Estimation

Simple Estimation

This method was borrowed from Joel Spolsky book

Some important points to note concerning software estimation:


As usual we are back to our beloved principle, your estimation platform should be as simple as you can make it. That is tasks should be as fine grained as reasonably possible. You should be thinking in tasks lasting 30 mins to at most 2 hours. In short a coding session.

It’s possible that you have longer coding sessions but I still believe you should keep it to this chunks.

Let the developer do it

There is evidence that letting people set their own schedules leads to boosts in productivity. Below is the findings of research carried out by Lawrence and Jeffrey from the University of New Wales.

Programmer Productivity

Programmer Productivity

Of course there is a caveat to this general rule as can be seen above, system analysts generally give better estimates. This is because they have more estimating experience. Still unless you have the budget for a system analyst, stick to the rule.

This is a living file

The column Curr Estimate and Elapsed time should be continuously updated. It is my suggestion that you take 10 mins after your coding session to update this values.

When you start of, your estimates are likely to be spectacularly wrong, however, if you discipline yourself to always update the estimates you will slowly but surely get better at this task as you learn from your mistakes and hone your estimating skills.

Version your estimates

It is critical that your estimates are part of the source. Whenever you commit your code, ensure there is a csv with your estimates within your project.

This gives you an opportune time to actually update your estimates before a commit as well as help you track the time used over long periods.

Tracking time

On this item you can either decide to use a time tracking software such as Toggl or use general estimates based on time spent.

This really is a matter of personal choice though you should strongly consider time tracking software if you or your agency bill by the hour.

Other considerations

It is important that you include other items that affect the schedule but are not programming tasks, this would include:

  • vacation and family time
  • debugging time
  • buffer time
  • deployment time

I hope I have been able to show the importance of scheduling and a simple way of achieving it. If you agree or have an even better method, share with us on the comments below.


Common XML DDoS attacks

SOAP and indeed XML based architectures are a common part of the web services middle ware architecture.

However due to the high resource cost of XML parsing, even simple mistakes in design of XML documents can have catastrophic effects on the stability of your architecture. This fact makes XML based architecture especially susceptible to DDoS attacks.

Listed below are some of the most common XML based attacks.

Parsing attacks

XML files sent via SOAP requests are usually automatically parsed. The following attacks are based on this “feature”

Coercive parsing attack

As discussed, parsing XML documents is an extremely taxing task. In this attack, the attacker sends an XML document that is deeply nested.

Creating such a document is extremely easy since not all of it needs to be loaded into memory however a DOM based parser is likely to run out of memory before it can open thereby, bringing your servers down.

SOAP Array Attack

This is another attack on memory. SOAP allows triggering of remote functions, in this case the XML payload triggers the creation of an extremely large array on the remote machine.

XML element count attack

Services that automatically parse incoming SOAP requests can be brought down by a request that has an unusually high element count.

XML attribute count attack

Quite similar to the above but now with a high attribute count. The perceptive reader may have noted that this kind of attack could be combined with the element count attack for a more potent outcome.

XML Overlong Names Attack

XML nodes are usually parsed to keys in key value pairs. This nodes are element names, attribute names or values and namespace definitions. Where the nodes are extremely long some parsers will fail.

Hash collision attack (HashDoS)

Hash Table is a data structure used to implement an associative array, a structure that can map keys to values

In XML documents Hash tables are used to store attributes and their corresponding value. The value of a certain key is mapped to a storage bucket through a hash function that takes the key as input. In cases where a weak hashing function is used, an attacker can intentionally create hash collisions leading to intense computations within the bucket.

DTD attacks

DTD is an acronym for Document Type Definition it defines the structure and legal elements and attributes of an XML document. You can read up more on it here

Below as some attacks targeted at it.

XML Entity Expansion Attack

Also called the Billion Laughs Attack there is nothing funny about this attack. In this attack the XML document is structured such that the DOM parser recursively resolves entities defined within its DTD.

The parser will run out of memory long before it can resolve the document.

XML External Entity DoS Attack

DTD’s can be defined externally and a rel provided. This attacks works by forcing your server to resolve a large entity defined externally, typically in a server which the attacker controls.

Most of this attacks can be prevented by immunizing your application against them. Some measures include:

  • Lazy loading of XML documents
  • Enforcing limit on attribute count
  • Memory threshold
  • CPU time threshold
  • Authentication of all requests

Have you ever experienced a DDoS attack? Talk to us on the comments below.


What is authentication

Authentication is the process of challenging the user to prove who they are so that they can access protected resources in your system.

It usually falls under three categories:

What do you know

This is the most common type of authentication. Typically it involves providing your username and password which is then checked against the data already stored in the application’s data stores.

Despite its popularity, this method is in fact the weakest form of authentication.

We will discuss in a later article what can be done to secure it, but as basic rules, Hash the passwords and ensure the authentication happens over a secure connection.

Something you have

Most employees now a days carry a security tag that can be swept at the doors in their organization. This is a form Something you have authentication.

Github usually a similar scheme but now using ssh keys Here Github allows gives you access to your repositories by checking your client certificates.

You can read more about this type of authentication here

This is a significantly more secure method compared to What you know method.

Something you are

This is the realm of biometrics. It includes fingerprint scanners, facial recognition and even typing patterns!

This is the strongest form of authentication and is gaining popularity in the modern world, in fact some modern smartphones come equipped with a facial scanner.

You are not restricted to using only one authentication method. Lately Google and other popular web services have been popularizing two factor authentication. This is where they ask you for your username and password combination (What you know) and then send you a sms or notification to your mobile device with a code which you then fill out (What you have).

Hope you are enjoying this series so far! Lets engage in comments below.

Also consider signing up Signup to our newsletter to ensure you don’t miss out on this kind of posts and much more.


API Security Introduction



It is known that most developers starting out on API development don’t yet know how to secure their APIs and there isn’t much in the way of resources for them to use.

We are about to change that with a series of articles culminating in a presentation at the 2015 Africahackon on API security to be held on 31st July 2015.

Hope you enjoy this series!


Getting started with Twitter API

For today we will have a play with the twitter API, see how we can get started using this popular platform.

Twitter is the poster boy of API adoption. Their own UI is built on top of their API and most of the clients it serves are actually API clients.

They provide a whole host of endpoints for us to play with including:

A more complete list can be found here

With that said let us get started with their API

Steps creating an App

  1. Navigate to
  2. Select Create new App and fill in the necessary details. For our tutorial you can simply use learningtwitternow in all fields
  3. Navigate to section named Keys and Access Tokens select Create my access token. Access tokens are what you will use in your application to access the API. Protect them as you would protect your password, they have the same power.

Using your app

All requests to Twitter API must be signed by Oauth. Thankfully they have provided us with a nice interface to carry out the authorization conversation.

To test our App click on Test Oauth button on top right

Test Oauth

Test Oauth

All the fields should be pre populated except request query and request URI.

Request URI is where we feed in our end point for example The request query are any extra GET variables that need to be passed to the API. For now we have none of those.

Request URI

Request URI

We can now generate our signatures by clicking on Get Oauth Signature

Copy the curl command and paste it to your terminal. Should look something like this

 curl --get ''
 --header 'Authorization: OAuth oauth_consumer_key="1J4FmtUOB1QjznpNMLHPqxqdN", oauth_nonce="a391652ee21c00d7ef4b3c9d76d0143d", oauth_signature="cdl3G8XsUv1o4XlQnuzFbrlGLwM%3D", oauth_signature_method="HMAC-SHA1", oauth_timestamp="1433834776", oauth_token="68480850-iV4oIN5uHXr0LNWPc5bPbhCNUJJQKZJ875nzmv1yJ", oauth_version="1.0"'

You probably don’t need the verbose switch and as such can omit the –verbose option.

Note this command will work for a few minutes at best before authorization is required once more.

For production environments, you may need use a library such as Abraham’s Twitter Oauth .

Have you used the twitter API in production? Let us know in comments below.


Gricean rules

Fundamentally, client server communication is really just a conversation between a business and its clients. That is, a human to human interaction.

Understanding this means that we can exploit human’s well developed social communication patterns.

For this entry, we will look into Grice’s Maxims. This are the rules by which ordinary cooperative speech is conducted and as such helping us to structure our own data formats to mimic them.

Let us begin.

Maxim of quantity

Pack as much information as required by the client but not anymore. For example if a request is made for users bio

GET /users/1/bio

You need only return the bio information

<person xmlns:atom="">
                <atom:link      rel="self"      

It would be unnecessary to return the users activity information or even the users address but it would be questionable to not return the user’s name.

Maxim of quality

Do not return what you don’t know to be true or even worse what is outright false. If a request requires information that has since been deleted, do not return the data even if you have it in your archive. Consider instead returning a 404 status code.

This maxim also requires that your application obeys the Rule of least surprise and is not reliable.

Maxim of relation

While before we admonished including too many details, it is important that we include Rel links in our response to ensure that the clients gets the proper context.

In the same vein it is important that we don’t include links that have no context in the current response.

Maxim of manner

You should choose your representation to be as simple as possible for the context in which it is requested. Avoid ambiguity or obscurity of expression by choosing standard data formats that are common practise for similar requests in the industry.

For example use JSON for AJAX requests and HTML for Browser requests. Using YAML for AJAXrequest while valid and simple would be surprising for most clients.

You can read more on Gricean maxim’s from here

How do you decide the amount of information to return to your clients? Let’s keep the conversation going.


Syntax rules for data formats

In the design of data format to be used in your API, you will definitely come across the problem on how to structure the syntax.

Thankfully, the unix shell provides us with some battle tested guidelines that we can use:



Provide support for comments

Invariably you will want a way to provide comments to the data that are not executable. In such a case simply use # to lead any section that is meant to be a comment.

Ignore whitespace

Now, I am a big fan of the python language, however, your data format is not where you want whitespace to matter. Spaces and tabs should be taken to mean a single space no matter the repetition or position.

This is because data structures are meant to be seen by human eyes and humans just aren’t that good at distinguishing spaces.

A corollary is that multiple blank lines should also be treated as one.


In shell and some programming languages single and double quotes mean different things. In as much as possible avoid replicating this. Whatever you choose the quotes to mean let it be the same for both single and double.

Special characters

Support special and unprintable characters using the common \. This prevents any kind of suprised in your code. Most consumers of your data will for example take for granted that \n means newline and \t means new tab.

Keep it simple

We have already talked about the KISS principle before. It also applies in this case. Complex lexical rules violate the principle wholesale and should be avoided at all cost.

If you already use a standard data format such as JSON or XML then you may have noticed they tend to respect the general guidelines provided above.

Have you ever used a custom data format in your code before? Lets keep the conversation going.