Month: March 2014

Man in the Mirror, Apple’s Security Flaw, and the Importance of Unit Testing

Posted on | by Adrian Hsieh | 5 Comments on Man in the Mirror, Apple’s Security Flaw, and the Importance of Unit Testing
Reading Time: 5 minutes

The “Man-in-the-Middle” attack is such a well-recognized security risk, with established solutions and preventative measures in place that when I first heard about the recent ruckus around the Apple security flaw, I thought Apple’s trouble was more legal in natural, maybe some sort of royalties dispute between iTunes and the Michael Jackson estate. Only later did I found out what all the fuss was about “in the middle”, not “in the mirror”, and why I had to upgrade the iOS on my iPhone on a beautiful Saturday afternoon.

Regarding the specifics to Apple’s security flaw, there is already plenty of press coverage out there.  For example, David Auerbach wrote a great analysis over at Slate.com.

In this post, I’d like to illustrate how automated unit testing with appropriate code coverage could have detected that particular kind of error, the one caused by grammatically correct code that inadvertently invalidated the whole logic of the program. We will build the unit tests using the MUnit module, an open source Mule testing framework that significantly streamline and simplify the process of writing unit tests.

We have built a simple,demonstrative application that processes incoming messages differently depending on whether a property of the payload, called “goodguy”, has value of “true” or not. If the value was true, the message would be processed one way and an HTTP 200 status would be returned. If it was not, the message would be processed another way and an HTTP status 400 would be returned:

The key logic for routing the message is shown below:

<choice doc:name="Choice">
  <!-- <when expression="#[payload['goodguy']=true]"> -->
  <when expression="#[payload['goodguy']==true]">
    <set-payload value="#['All Good']" doc:name="set-valid-payload-response"/>
    <http:response-builder status="200" contentType="text/plain" doc:name="HTTP Response 200"/>
  </when>
  <otherwise>
    <set-payload value="#['Invalid Payload']" doc:name="invalid-payload-goes-here"/>
    <http:response-builder status="400" contentType="text/plain" doc:name="HTTP Response 400"/>
  </otherwise>
</choice>

Continue reading →

Error Handling in APIKit-based Projects

Posted on | by Eugene Berman | 3 Comments on Error Handling in APIKit-based Projects
Reading Time: 5 minutes
error handling

If you look at the W3C document listing HTTP status codes, you may notice that only a small portion of all possible codes represents the happy path – i.e. 2xx codes. Most other codes are there to let client know that something went wrong with the request and the expected response cannot be returned. When building an APIKit-based application, developers must properly handle error conditions and set status codes accordingly. As always with Mule, there are many ways to achieve that. Let’s look at some of them.

Our use case is a very simple ACME Company API which returns a product information based on a particular product ID. In other words,

GET /products/{id}

Our RAML is as follows:

When we create a new APIKit project in Studio and add a RAML file, it generates flows for each RESTful call. In our case, it will produce one flow which handles our request:

We can now replace the default content of this flow with a business logic that queries the database and returns product information:

But what if our query returns no results? From the JDBC transport perspective, this is not an error condition – the returned payload will simply be an empty list. In this case, our API call will return an empty response, with the HTTP status code 200 – something the client would expect. Or, if our transformation logic expects some data from the database, it may fail, throwing an exception – again, not the desired behavior. What we really need is to return status 404 and potentially some object containing more details. All we need is to add a <choice> message processor, e.g.:

How about any other scenarios where something else may go wrong? Wouldn’t it be great if we had an exception strategy which can automatically map exceptions to response codes?

Let’s look at our generated code again. There’s a new global element called apikit:mapping-exception-strategy:

It allows mapping exception types to status codes, content types, error messages and anything else you may want to return as a part of your error response. You can add as many mappings as you need, however, you will have to either know all types of exceptions at the design time (which is not always possible) or throw a specific exception using Java or scripting component, e.g.:

In reality, a combined approach should be used. Use as much logic as possible to gracefully handle some error conditions, use mapping exception strategy to intercept and map other errors.

Now you can finish your ACME API, connect it to a database of your choice and send the request for a product that does not exist in the database.

Quoth the server, 404…