Pablo M. Cibraro (aka Cibrax)

Giving temporary access to your ASP.NET Web API with Hawk

2013-03-08T15:00:12Z

One of the features supported by Hawk, an HTTP authentication protocol based on HMAC, is to provide read-only access to a Web API for a short period time. That’s performed through a token called “bewit” that a Web API can provide to a client. That token is only valid for Http GET calls and it can be used for a limited period of time.

I already implemented this feature in my Hawk port for .NET. A bewit token can be generated as it is shown below,

var credential = new HawkCredential
{
     Id = "dh37fgj492je",
     Key = "werxhqb98rpaxn39848xrunpaw3489ruxnpa98w4rxn",
     Algorithm = "hmacsha256",
     User = "steve"
 };

var bewit = Hawk.GetBewit("localhost", 
  new Uri("http://localhost:8091/Api/HelloWorld"), 
  credential, 
  60000);

The GetBewit method expects the following arguments,

The host name
The complete request URI
The Hawk credentials with information about the key and algorithm to use
A time-to-live setting in seconds for the token

That token is an string representation that you can add as a additional query string in the Web API call.

new HttpRequestMessage(HttpMethod.Get, 
  "http://localhost:8091/Api/HelloWorld?bewit=" + bewit);

In that way, you can share a link to your Web API with a limited access for a period of time to someone without having to share any security credentials.

On the service side is as simple as configuring the HawkMessageHandler as part of the Web API configuration,

var handler = new HawkMessageHandler((id) =>
{
     return new HawkCredential
     {
           Id = id,
           Key = "werxhqb98rpaxn39848xrunpaw3489ruxnpa98w4rxn",
           Algorithm = "hmacsha256",
           User = "steve"
       };
 });

config.MessageHandlers.Add(handler);

The handler will automatically detect a bewit token in the query string, and it will performed all the required validations.

ASP.NET Web API Logging and Troubleshooting

2013-03-01T14:48:00Z

ASP.NET ships with two built-in mechanisms for doing logging and troubleshooting. Chasing errors without knowing these two mechanisms might be a daunting task, specially if they happen in the runtime pipeline much before a message gets to a handler or a controller.

The first mechanism is the error policy. You can configure the error policy preferences as part of the configuration object (HttpConfiguration) in the IncludeErrorDetailPolicy property. This is just an enum that instructs Web API about how to deal with exceptions.

The possible values for this enum are,

Default: It’s uses the customErrors configuration settings if you are using ASP.NET as host or LocalOnly for self-host.
LocalOnly: Only includes error details for local requests
Always: Always includes error details
Never: Never includes error details

When an exception happens, Web API will check the value on this setting for including details about the exception in the response message or not. For example, if Always is enabled, Web API will serialize the exception details as part of the message that you get as response.

The second mechanism is Tracing. Tracing is a service that you can inject as part of the configuration object as well. The default implementation does do anything.

public static void Register(HttpConfiguration config)
{
    config.Services.Replace(typeof(ITraceWriter), new MyTracer());
}

MyTracer is a custom implementation of the ITraceWriter service, which Web API uses for tracing purposes. This is a general tracing mechanism, so Web API will call it for logging everything and not just errors.

public class MyTracer : ITraceWriter
{
    public void Trace(HttpRequestMessage request, string category, TraceLevel level, 
        Action<TraceRecord> traceAction)
    {
        TraceRecord rec = new TraceRecord(request, category, level);
        traceAction(rec);
        WriteTrace(rec);
    }

    protected void WriteTrace(TraceRecord rec)
    {
        var message = string.Format("{0};{1};{2}", 
            rec.Operator, rec.Operation, rec.Message);
        System.Diagnostics.Trace.WriteLine(message, rec.Category);
    }
}

If any of these two work for you, you can still use an Error Filter. Tugberk has written a blog post about how to integrate ELMAH with an Error Filter in Web API here.

Message Handlers per Route in ASP.NET Web API

2013-02-25T14:35:34Z

Message Handlers are one of the core components for message processing in Web API. They use an asynchronous model for processing messages, so they receive a request message and returns a Task with the corresponding response.

protected internal abstract Task<HttpResponseMessage> SendAsync(HttpRequestMessage request,
 CancellationToken cancellationToken);

In most cases, a message handler does something and delegates some other work to the rest of the handlers configured in the pipeline. For example, a handler for security checks the Auth Http header, and delegates the call the handlers configured out of the box by Web API, which eventually will call a controller method. The framework also provides a base class to make delegation implicit, DelegatingHandler, which receives the next handler to call as part of the constructor.

The following example shows a message handler implementation for basic authentication,

public class BasicAuthHandler : DelegatingHandler
{
   Func<string, string, IPrincipal> auth;

   public BasicAuthHandler(HttpMessageHandler innerHandler, Func<string, string, IPrincipal> auth)
       : base(innerHandler)
   {
       this.auth = auth;
    }

    protected override System.Threading.Tasks.Task<HttpResponseMessage> SendAsync(HttpRequestMessage request,

System.Threading.CancellationToken cancellationToken)
    {
         if (request.Headers.Authorization != null &&
             !string.Equals(request.Headers.Authorization.Scheme, "basic",

StringComparison.InvariantCultureIgnoreCase))
         {
              return base.SendAsync(request, cancellationToken);
          }

          if (request.Headers.Authorization == null ||
              string.IsNullOrWhiteSpace(request.Headers.Authorization.Scheme))
          {
              return ChallengeResponse(request);
           }

          var authToken = request.Headers.Authorization.Parameter;
          var decodedToken = Encoding.UTF8.GetString(Convert.FromBase64String(authToken));

          var username = decodedToken.Substring(0, decodedToken.IndexOf(":"));
          var password = decodedToken.Substring(decodedToken.IndexOf(":") + 1);

          var principal = this.auth(username, password);
            
          if (principal == null)
          {
              return ToResponse(request, HttpStatusCode.Unauthorized, "Invalid credentials");
           }

          Thread.CurrentPrincipal = principal;
          if (HttpContext.Current != null)
             HttpContext.Current.User = principal;
                        
          return base.SendAsync(request, cancellationToken);
   }

   private static Task<HttpResponseMessage> ChallengeResponse(HttpRequestMessage request)
   {
       var tsc = new TaskCompletionSource<HttpResponseMessage>();

       var response = request.CreateResponse(HttpStatusCode.Unauthorized);
        response.Headers.WwwAuthenticate.Add(new AuthenticationHeaderValue("basic", "realm=localhost"));

       tsc.SetResult(response);

       return tsc.Task;
     }

     private static Task<HttpResponseMessage> ToResponse(HttpRequestMessage request,

HttpStatusCode code, string message)
     {
        var tsc = new TaskCompletionSource<HttpResponseMessage>();

         var response = request.CreateResponse(code);
         response.ReasonPhrase = message;

         tsc.SetResult(response);

         return tsc.Task;
      }
 }

A good thing about Message Handler is that you can configure them globally or per route. In this case, if you want to enable basic authentication for some routes only, it’s a matter of configuring this handler in the routes you want to have protected.

config.Routes.MapHttpRoute(
   "BasicAuth",
   "MyController",
   new { controller = "MyController" },
   null,
   new BasicAuthHandler(new HttpControllerDispatcher(config), (u, p) => 
   {
      return new GenericPrincipal(new GenericIdentity(u, new string[] {}));
   }));

As you can see, the Inner Handler is a built-in handler provided by Web API, HttpControllerDispatcher, which does all the magic for processing the request and pass it over to the controller action. You can also inject any other dependency as part of the constructor. One thing to consider is that message handlers are singleton if you configure them this way, so make sure to inject the dependencies in the right way for avoiding memory leaks (If you have to use a repository for example, you might want to inject a factory or pass a delegate for resolving the dependencies from a DI container).

Multitenant domain routing with AWS Route 53

2013-02-12T15:57:43Z

A common requirement in SaaS applications is the ability to route requests to different tenants based on a URL routing strategy.

In most cases, a domain prefix is good enough to identify tenants (e.g. mytenant.xxxxx.com). That approach typically relies on CName records for mapping the prefixes or tenants and the domain name to an URL where the application is actually hosted. Many cloud providers support the idea of mapping custom domains to their web hosted services, so this approach with CName works just fine.

An evident problem is that you would require a different CName record per prefix or tenant. If you have to create those records manually, this approach simply does not scale as the number of tenants increase.

An alternative is to use a wildcard CName, and route all the requests that match that wildcard to the hosted application in the cloud. For example, *.xxxxxx.com to your web application url.

Many DNS servers don’t support wildcards in CName such as the ones offered by free for GoDaddy or NameCheap. However, AWS Route 53 supports wildcards and also an API to manage almost everything in the DNS tables.

Configuring AWS Route 53 is relatively easy. Assuming that you already have a AWS account, you need to create first a hosted zone, which represents the association of a domain name with a set of name servers provided by Route 53. Once you specified the domain name (e.g cibrax.me), and the hosted zone is created. Route53 will show you a list of name servers you need to use. If you already own a domain in other place like GoDaddy or NameCheap, you need to go there and update the list of name servers associated to that domain.

Afterwards, you need to create a resource record set, which is basically the CName record containing the wildcard or prefix you want to use. Here, you can specify the CNAme record and the mapped URL. For example, *.cibrax.me goes to www.xxxxxxxx.com.

That’s all from the point of view of DNS configuration. The rest is part of the implementation of your web application.

Multitenancy in SQL Azure

2012-12-06T18:38:48Z

If you are building a SaaS application in Windows Azure that relies on SQL Azure, it’s probably that you will need to support multiple tenants at database level.

This is short overview of the different approaches you can use for support that scenario,

A different database per tenant

A new database is created and assigned when a tenant is provisioned.

Pros

Complete isolation between tenants. All the data for a tenant lives in a database only he can access.

Cons

It’s not cost effective. SQL Azure databases are not cheap, and the minimum size for a database is 1GB. You might be paying for storage that you don’t really use.
A different connection pool is required per database.
Updates must be replicated across all the databases
You need multiple backup strategies across all the databases

Multiple schemas in a database shared by all the tenants

A single database is shared among all the tenants, but every tenant is assigned to a different schema and database user.

Pros

You only pay for a single database.
Data is isolated at database level. If the credentials for one tenant is compromised, the rest of the data for the other tenants is not.

Cons

You need to replicate all the database objects in every schema, so the number of objects can increase indefinitely.
Updates must be replicated across all the schemas.
The connection pool for the database must maintain a different connection per tenant (or set of credentials)
A different user is required per tenant, which is stored at server level. You have to backup that user independently.

Centralizing the database access with store procedures in a database shared by all the tenants

A single database is shared among all the tenants, but nobody can read the data directly from the tables. All the data operations are performed through store procedures that centralize the access to the tenant data. The store procedures contain some logic to map the database user to an specific tenant.

Pros

You only pay for a single database.
You only have a set of objects to maintain and backup.

Cons

There is no real isolation. All the data for the different tenants is shared in the same tables.
You can not use traditional ORM like EF code first for consuming the data.
A different user is required per tenant, which is stored at server level. You have to backup that user independently.

SQL Federations

A single database is shared among all the tenants, but a different federation is used per tenant. A federation in few words, it’s a mechanism for horizontal scaling in SQL Azure, which basically uses the idea of logical partitions to distribute data based on certain criteria.

Pros

You only have a single database with multiple federations.
You can use filtering in the connections to pick the right federation, so any ORM could be used to consume the data.

Cons

There is no real isolation at that database level. The isolation is enforced programmatically with federations.

Using MAC Authentication for simple Web API’s consumption

2012-12-06T02:44:20Z

For simple scenarios of Web API consumption where identity delegation is not required, traditional http authentication schemas such as basic, certificates or digest are the most used nowadays. All these schemas rely on sending the caller credentials or some representation of it in every request message as part of the Authorization header, so they are prone to suffer phishing attacks if they are not correctly secured at transport level with https.

In addition, most client applications typically authenticate two different things, the caller application and the user consuming the API on behalf of that application. For most cases, the schema is simplified by using a single set of username and password for authenticating both, making necessary to store those credentials temporally somewhere in memory.

The true is that you can use two different identities, one for the user running the application, which you might authenticate just once during the first call when the application is initialized, and another identity for the application itself that you use on every call.

Some cloud vendors like Windows Azure or Amazon Web Services have adopted an schema to authenticate the caller application based on a Message Authentication Code (MAC) generated with a symmetric algorithm using a key known by the two parties, the caller and the Web API.

The caller must include a MAC as part of the Authorization header created from different pieces of information in the request message such as the address, the host, and some other headers. The Web API can authenticate the caller by using the key associated to it and validating the attached MAC in the request message. In that way, no credentials are sent as part of the request message, so there is no way an attacker to intercept the message and get access to those credentials.

Anyways, this schema also suffers from some deficiencies that can generate attacks. For example, brute force can be still used to infer the key used for generating the MAC, and impersonate the original caller. This can be mitigated by renewing keys in a relative short period of time. This schema as any other can be complemented with transport security.

Eran Rammer, one of the brains behind OAuth, has recently published an specification of a protocol based on MAC for Http authentication called Hawk. The initial version of the spec is available here. A curious fact is that the specification per se does not exist, and the specification itself is the code that Eran initially wrote using node.js.

In that implementation, you can associate a key to an user, so once the MAC has been verified on the Web API, the user can be inferred from that key. Also a timestamp is used to avoid replay attacks.

As a pet project, I decided to port that code to .NET using ASP.NET Web API, which is available also in github under https://github.com/pcibraro/hawknet

Enjoy!.

await, WhenAll, WaitAll, oh my!!

2012-11-15T15:21:13Z

If you are dealing with asynchronous work in .NET, you might know that the Task class has become the main driver for wrapping asynchronous calls. Although this class was officially introduced in .NET 4.0, the programming model for consuming tasks was much more simplified in C# 5.0 in .NET 4.5 with the addition of the new async/await keywords. In a nutshell, you can use these keywords to make asynchronous calls as if they were sequential, and avoiding in that way any fork or callback in the code. The compiler takes care of the rest.

I was yesterday writing some code for making multiple asynchronous calls to backend services in parallel. The code looked as follow,

var allResults = new List<Result>();
foreach(var provider in providers)
{
  var results = await provider.GetResults();
  allResults.AddRange(results);
}
return allResults;

You see, I was using the await keyword to make multiple calls in parallel. Something I did not consider was the overhead this code implied after being compiled. I started an interesting discussion with some smart folks in twitter. One of them, Tugberk Ugurlu, had the brilliant idea of actually write some code to make a performance comparison with another approach using Task.WhenAll.

There are two additional methods you can use to wait for the results of multiple calls in parallel, WhenAll and WaitAll.

WhenAll creates a new task and waits for results in that new task, so it does not block the calling thread. WaitAll, on the other hand, blocks the calling thread. This is the code Tugberk initially wrote, and I modified afterwards to also show the results of WaitAll.

 class Program
    {
        private static Func<Stopwatch, Task>[] funcs = new Func<Stopwatch, Task>[] { 
            async (watch) => { watch.Start(); await Task.Delay(1000); 
                Console.WriteLine("1000 one has been completed."); },
            async (watch) => { await Task.Delay(1500); 
                Console.WriteLine("1500 one has been completed."); },
            async (watch) => { await Task.Delay(2000); 
                Console.WriteLine("2000 one has been completed."); watch.Stop(); 
                Console.WriteLine(watch.ElapsedMilliseconds + "ms has been elapsed."); }
        };
        static void Main(string[] args)
        {
            Console.WriteLine("Await in loop work starts...");
            DoWorkAsync().ContinueWith(task =>
            {
                Console.WriteLine("Parallel work starts...");
                DoWorkInParallelAsync().ContinueWith(t =>
                    {
                        Console.WriteLine("WaitAll work starts...");
                        WaitForAll();
                    });
            });
            Console.ReadLine();
        }
        static async Task DoWorkAsync()
        {
            Stopwatch watch = new Stopwatch();
            foreach (var func in funcs)
            {
                await func(watch);
            }
        }
        static async Task DoWorkInParallelAsync()
        {
            Stopwatch watch = new Stopwatch();
            await Task.WhenAll(funcs[0](watch), funcs[1](watch), funcs[2](watch));
        }
        static void WaitForAll()
        {
            Stopwatch watch = new Stopwatch();
            Task.WaitAll(funcs[0](watch), funcs[1](watch), funcs[2](watch));
        }
    }

After running this code, the results were very concluding.

Await in loop work starts...
1000 one has been completed.
1500 one has been completed.
2000 one has been completed.
4532ms has been elapsed.

Parallel work starts...
1000 one has been completed.
1500 one has been completed.
2000 one has been completed.
2007ms has been elapsed.

WaitAll work starts...
1000 one has been completed.
1500 one has been completed.
2000 one has been completed.
2009ms has been elapsed.

The await keyword in a loop does not really make the calls in parallel.

Unit testing ASP.NET Web API controllers that rely on the UrlHelper

2012-10-10T18:34:33Z

UrlHelper is the class you can use in ASP.NET Web API to automatically infer links from the routing table without hardcoding anything. For example, the following code uses the helper to infer the location url for a new resource,

public HttpResponseMessage Post(User model)
{
  var response = Request.CreateResponse(HttpStatusCode.Created, user);
  var link = Url.Link("DefaultApi", new { id = id, controller = "Users" });
  response.Headers.Location = new Uri(link);
  return response;
}

That code uses a previously defined route “DefaultApi”, which you might configure in the HttpConfiguration object (This is the route generated by default when you create a new Web API project).

The problem with UrlHelper is that it requires from some initialization code before you can invoking it from a unit test (for testing the Post method in this example). If you don’t initialize the HttpConfiguration and Request instances associated to the controller from the unit test, it will fail miserably.

After digging into the ASP.NET Web API source code a little bit, I could figure out what the requirements for using the UrlHelper are. It relies on the routing table configuration, and a few properties you need to add to the HttpRequestMessage. The following code illustrates what’s needed,

var controller = new UserController();
controller.Configuration = new HttpConfiguration();
var route = controller.Configuration.Routes.MapHttpRoute(
         name: "DefaultApi",
         routeTemplate: "api/{controller}/{id}",
         defaults: new { id = RouteParameter.Optional }
);
var routeData = new HttpRouteData(route, 
       new HttpRouteValueDictionary 
       { 
          { "id", "1" },
          { "controller", "Users" } 
       }
);
controller.Request = new HttpRequestMessage(HttpMethod.Post, "http://localhost:9091/");
controller.Request.Properties.Add(HttpPropertyKeys.HttpConfigurationKey, controller.Configuration);
controller.Request.Properties.Add(HttpPropertyKeys.HttpRouteDataKey, routeData);

The HttpRouteData instance should be initialized with the route values you will use in the controller method (“id” and “controller” in this example). Once you have correctly setup all those properties, you shouldn’t have any problem to use the UrlHelper. There is no need to mock anything else.

Enjoy!!.

Doing unit and integration tests with the Web API HttpClient

2012-09-12T19:23:01Z

One of the nice things about the new HttpClient in System.Net.Http is the support for mocking responses or handling requests in a http server hosted in-memory. While the first option is useful for scenarios in which we want to test our client code in isolation (unit tests for example), the second one enables more complete integration testing scenarios that could include some more components in the stack such as model binders or message handlers for example.

The HttpClient can receive a HttpMessageHandler as argument in one of its constructors.

public class HttpClient : HttpMessageInvoker
{
   public HttpClient();
   public HttpClient(HttpMessageHandler handler);
   public HttpClient(HttpMessageHandler handler, bool disposeHandler);

For the first scenario, you can create a new HttpMessageHandler that fakes the response, which you can use in your unit test. The only requirement is that you somehow inject an HttpClient with this custom handler in the client code.

public class FakeHttpMessageHandler : HttpMessageHandler
{
  HttpResponseMessage response;

  public FakeHttpMessageHandler(HttpResponseMessage response)
  {
       this.response = response;
   }

   protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, 
System.Threading.CancellationToken cancellationToken)
   {
      var tcs = new TaskCompletionSource<HttpResponseMessage>();
            
      tcs.SetResult(response);

      return tcs.Task;
    }
}

In an unit test, you can do something like this.

var fakeResponse = new HttpResponse();
var fakeHandler = new FakeHttpMessageHandler(fakeResponse);
var httpClient = new HttpClient(fakeHandler);

var customerService = new CustomerService(httpClient);

// Do something

// Asserts

CustomerService in this case is the class under test, and the one that receives an HttpClient initialized with our fake handler.

For the second scenario in integration tests, there is a In-Memory host “System.Web.Http.HttpServer” that also derives from HttpMessageHandler and you can use with a HttpClient instance in your test. This has been discussed already in these two great posts from Pedro and Filip.

Consuming the Amazon S3 service from a Win8 Metro Application

2012-09-10T15:58:27Z

As many of the existing Http APIs for Cloud Services, AWS also provides a set of different platform SDKs for hiding many of complexities present in the APIs. While there is a platform SDK for .NET, which is open source and available in C#, that SDK does not work in Win8 Metro Applications for the changes introduced in WinRT. WinRT offers a complete different set of APIs for doing I/O operations such as doing http calls or using cryptography for signing or encrypting data, two aspects that are absolutely necessary for consuming AWS. All the I/O APIs available as part of WinRT are asynchronous, and uses the TPL model for .NET applications (HTML and JavaScript Metro applications use a model based in promises, which is similar concept).

In the case of S3, the http Authorization header is used for two purposes, authenticating clients and make sure the messages were not altered while they were in transit. For doing that, it uses a signature or hash of the message content and some of the headers using a symmetric key (That's just one of the available mechanisms). Windows Azure for example also uses the same mechanism in many of its APIs.

There are three challenges that any developer working for first time in Metro will have to face to consume S3, the new WinRT APIs, the asynchronous nature of them and the complexity introduced for generating the Authorization header. Having said that, I decided to write this post with some of the gotchas I found myself trying to consume this Amazon service.

1. Generating the signature for the Authorization header

All the cryptography APIs in WinRT are available under Windows.Security.Cryptography namespace. Many of operations available in these APIs uses the concept of buffers (IBuffer) for representing a chunk of binary data. As you will see in the example below, these buffers are mainly generated with the use of static methods in a WinRT class CryptographicBuffer available as part of the namespace previously mentioned.

private string DeriveAuthToken(string resource, string httpMethod, string timestamp)
{
   var stringToSign = string.Format("{0}\n" +
      "\n" +
      "\n" +
      "\n" +
      "x-amz-date:{1}\n" +
      "/{2}/", httpMethod, timestamp, resource);

   var algorithm = MacAlgorithmProvider.OpenAlgorithm("HMAC_SHA1");

   var keyMaterial = CryptographicBuffer.CreateFromByteArray(Encoding.UTF8.GetBytes(this.secret));

   var hmacKey = algorithm.CreateKey(keyMaterial);

   var signature = CryptographicEngine.Sign(
                hmacKey,
                CryptographicBuffer.CreateFromByteArray(Encoding.UTF8.GetBytes(stringToSign))
            );

   return CryptographicBuffer.EncodeToBase64String(signature);
}

The algorithm that determines the information or content you need to use for generating the signature is very well described as part of the AWS documentation. In this case, this method is generating a signature required for creating a new bucket. A HmacSha1 hash is computed using a secret or symetric key provided by AWS in the management console.

2. Sending an Http Request to the S3 service

WinRT also ships with the System.Net.Http.HttpClient that was first introduced some months ago with ASP.NET Web API. This client provides a rich interface on top the traditional WebHttpRequest class, and also solves some of limitations found in this last one. There are a few things that don't work with a raw WebHttpRequest such as setting the Host header, which is something absolutely required for consuming S3. Also, HttpClient is more friendly for doing unit tests, as it receives a HttpMessageHandler as part of the constructor that can fake to emulate a real http call. This is how the code for consuming the service with HttpClient looks like,

public async Task<S3Response> CreateBucket(string name, string region = null, params string[] acl)
{
   var timestamp = string.Format("{0:r}", DateTime.UtcNow);

    var auth = DeriveAuthToken(name, "PUT", timestamp);

    var request = new HttpRequestMessage(HttpMethod.Put, "http://s3.amazonaws.com/");
    request.Headers.Host = string.Format("{0}.s3.amazonaws.com", name);
    request.Headers.TryAddWithoutValidation("Authorization", "AWS " + this.key + ":" + auth);
    request.Headers.Add("x-amz-date", timestamp);

    var client = new HttpClient();
    var response = await client.SendAsync(request);

    return new S3Response
    {
         Succeed = response.StatusCode == HttpStatusCode.OK,
         Message = (response.Content != null) ? 
            await response.Content.ReadAsStringAsync() : null
     };
 }

You will notice a few additional things in this code. By default, HttpClient validates the values for some well-know headers, and Authorization is one of them. It won't allow you to set a value with ":" on it, which is something that S3 expects. However, that's not a problem at all, as you can skip the validation by using the TryAddWithoutValidation method.
Also, the code is heavily relying on the new async and await keywords to transform all the asynchronous calls into synchronous ones. In case you would want to unit test this code and faking the call to the real S3 service, you should have to modify it to inject a custom HttpMessageHandler into the HttpClient. The following implementation illustrates this concept,

In case you would want to unit test this code and faking the call to the real S3 service, you should have to modify it to inject a custom HttpMessageHandler into the HttpClient. The following implementation illustrates this concept,

public class FakeHttpMessageHandler : HttpMessageHandler
{
  HttpResponseMessage response;

  public FakeHttpMessageHandler(HttpResponseMessage response)
  {
       this.response = response;
   }

   protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, System.Threading.CancellationToken cancellationToken)
   {
      var tcs = new TaskCompletionSource<HttpResponseMessage>();
            
      tcs.SetResult(response);

      return tcs.Task;
    }
}

You can use this handler for injecting any response while you are unit testing the code.

Binding form data in ASP.NET Web API

2012-08-10T15:34:00Z

One scenario that is very common in ASP.NET MVC is to bind form data (data posted with the media type application/x-www-form-urlencoded) to individual parameters or a form collection in a controller action. However, that scenario does not work quite the same in ASP.NET Web API as the body content is treated a forward-only stream that can only be read once.

If you define an action with multiple simple type arguments such as the one shown bellow, the model binding runtime will try to map those by default from the request URI (query string or route data).

public void Post(int id, string value)
{
}

That data never comes from the body content unless you decorate the argument with the [FromBody] attribute. However, only one argument in the action can be decorated with this attribute, and you get an exception when you try to decorate more than one. Nevertheless, the desired effect is far from what you would expect.

If you define an action as follow,

public void Post([FromBody]int id)
{
}

And you POST a form with the following data,

http://localhost:64561/api/values

METHOD: POST

CONTENT-TYPE: application/x-www-form-urlencoded

BODY: id=4

Nothing will be mapped. It does not matter you defined a single parameter with the same as the one posted in the body.

If you really want to have a single type argument mapped to the body content, you have to POST a message with the following content

http://localhost:64561/api/values

METHOD: POST

CONTENT-TYPE: application/x-www-form-urlencoded

BODY: =4

As you can see, no key defined so the whole is mapped to our argument in the action. That’s the default behavior for single types. If you want to change that behavior, the framework is completely extensible and you can replace the whole model binding infrastructure included out of the box for one that you find more useful as it is explained here by Mike Stalls (which shows how you can replicate the same model used by ASP.NET MVC).

For complex types, the framework includes two MediaTypeFormatter implementations. The first one is FormUrlEncodedMediaTypeFormatter, which knows how to map every key/value in the form data to a FormDataCollection or a JTokenType (a dynamic type for expressing JSON available as part of the Json.NET library). These two are useful when you want to get access to all the values in form in a generic manner. You define for example a controller that receives a FormDataCollection instance like this,

public void Post(FormDataCollection form)
{
}

The second one is JQueryMvcFormUrlEncodedFormatter, which derives from the first one and knows how to map the form data to a concrete type representing a model. For example, a model defined as follow will match a body content with the keys “Id” and “Value”

public class MyModel
{
   public int Id { get; set; }
   public string Value { get; set; }
}

Therefore, your controller action can either receive a generic form collection (or a JTokenType) or a complex model type as any of these two will handle the deserialization of the body content type into the expected model.

Implementing synchronous MediaTypeFormatters in ASP.NET Web API

2012-07-09T15:42:51Z

One of main characteristics of MediaTypeFormatter’s in ASP.NET Web API is that they leverage the Task Parallel Library (TPL) for reading or writing an model into an stream. When you derive your class from the base class MediaTypeFormatter, you have to either implement the WriteToStreamAsync or ReadFromStreamAsync methods for writing or reading a model from a stream respectively.

These two methods return a Task, which internally does all the serialization work, as it is illustrated bellow.

public abstract class MediaTypeFormatter

  public virtual Task WriteToStreamAsync(Type type, object value,

     Stream writeStream, HttpContent content, TransportContext transportContext);

  public virtual Task<object> ReadFromStreamAsync(Type type, Stream readStream,

     HttpContent content, IFormatterLogger formatterLogger);

However, most of the times, serialization is a safe operation that can be done synchronously. In fact, many of the serializer classes you will find in the .NET framework only provide sync methods. So the question is, how you can transform that synchronous work into a Task ?.

Creating a new task using the method Task.Factory.StartNew for doing all the serialization work would be probably the typical answer. That would work, as a new task is going to be scheduled. However, that might involve some unnecessary context switches, which are out of our control and might be affect performance on server code specially.

If you take a look at the source code of the MediaTypeFormatters shipped as part of the framework, you will notice that they actually using another pattern, which uses a TaskCompletionSource class.

public Task WriteToStreamAsync(Type type, object value, Stream writeStream,

HttpContent content, TransportContext transportContext)

  var tsc = new TaskCompletionSource<AsyncVoid>();

  tsc.SetResult(default(AsyncVoid));

  //Do all the serialization work here synchronously

  return tsc.Task;

/// <summary>

/// Used as the T in a "conversion" of a Task into a Task{T}

/// </summary>

private struct AsyncVoid

They are basically doing all the serialization work synchronously and using a TaskCompletionSource for returning a task already done.

To conclude this post, this is another approach you might want to consider when using serializers that are not compatible with an async model.

Update: Henrik Nielsen from the ASP.NET team pointed out the existence of a built-in media type formatter for writing sync formatters. BufferedMediaTypeFormatter http://t.co/FxOfeI5x

HTML 5 para dispositivos mobiles – Proyecto Liike

2012-06-06T18:50:37Z

La serie de videos que grabe con Miguel Angel Saenz y Ariel Schapiro de Microsoft Argentina acerca del proyecto “Liike” de Patterns & Practices para desarrollos de aplicaciones mobiles con HTML 5 ha sido publicada en channel9.

Les dejo la lista de videos para que los puedan ir viendo y conociendo un poco mas con este proyecto mas que interesante.

http://channel9.msdn.com/posts/1Serie-HTML5-para-dispositivos-mviles-Proyecto-Liike-parte-1-introduccin
http://channel9.msdn.com/posts/2Serie-HTML5-para-dispositivos-mviles-Proyecto-Liike-parte-2-overview-de-aplicacin-Mileage-Stats
http://channel9.msdn.com/posts/3Serie-HTML5-para-dispositivos-mviles-Proyecto-Liike-parte-3-determinacin-de-vista-en-html-a-mostrar
http://channel9.msdn.com/posts/4Serie-HTML5-para-dispositivos-mviles-Proyecto-Liike-parte-4-Single-Page-application
http://channel9.msdn.com/posts/5Serie-HTML5-para-dispositivos-mviles-Proyecto-Liike-parte-5-nuevos-controles-HTML5-
http://channel9.msdn.com/posts/6Serie-HTML5-para-dispositivos-mviles-Proyecto-Liike-parte-6-Botn-Switch-to-Desktop-Site
http://channel9.msdn.com/posts/7Serie-HTML5-para-dispositivos-mviles-Proyecto-Liike-parte-7-Testing-de-aplicaciones-mviles-en-HTML5

Apache Cordova. A new alternative for developing native apps in Win Phone 7

2012-05-11T15:23:22Z

Apache Cordova is one of those projects that recently caught my attention for developing applications in mobile. This project previously known as PhoneGap was donated by Adobe to the Apache Foundation to be part of a new and attractive open source alternative for developing mobile applications. If you haven’t heard of it before, it basically provides the required infrastructure to run native applications in different mobile platforms such as IOS, Android, and Windows Phone 7 using an hybrid approach with an embedded browser. There is a thin native layer that provides access to different native features in phone through an standard object model in JavaScript, so the developers can write their applications using HTML 5 and have access to different features through that model. Therefore, the two most important components in this project are the native layer and the JavaScript component model, which are supported across the different platforms.

The Microsoft Interoperability team collaborated as part of the project to support Win7 phone as another available platform, which was announced by Abu Obeida in December last year. Another major announcement these days was the support for a Metro theme in JQuery Mobile, which gives the ability to give applications written in HTML 5 for this platform the same look and feel as a native applications.

If you want to know more about the platform, there is an excellent introductory article written by Colin Eberhardt for the MSDN Magazine, “Develop HTML Windows Phone Apps with Apache Cordova”

One the things I noticed in the project, is that there is available a project template in Visual Studio for creating the initial application. However, you need to manually deploy that template in the right folder to make it available in Visual Studio, which might be an error prone task. I decided to make a little contribution to the project and write an Visual Studio extension (a vsix package) to automatically deploy the template, which I am not sure yet if it is going to be approved or not, but I think it is a nice thing to have for easing adoption. This is part of the fork associated to my user in case you want to use it.

Increasing your system reliability with the Azure Service Bus Queues

2012-04-20T15:10:00Z

A common scenario for many web applications running in the cloud is to integrate with existing systems through web services (no matter the messaging style they use). Although in these scenarios, an SLA is typically used as an agreement between the two parties to assure certain level of availability, many things can still fail. Therefore, it is always a good idea to have a mechanism in place to handle any possible error condition and retry the execution when it is possible.

As example, you could have a web application that calls an online CRM system (like Salesforce.com or MS Dynamics) for allowing the users to report incidents. In that scenario, we can not assume any possible call to the CRM system will always succeed. On the other hand, this kind of call does not require an immediate response for the user, so it can be scheduled for later execution and retried if something unexpected happens.

A persistent storage for the messages like a queue is always a good choice for decoupling clients from services, and also accomplish the goal previously discussed. When you move to Windows Azure, there are two different queue offerings, Queues as part of the Storage service, and Queues (or Topics) as part of the Service Bus.

The Service Bus SDK provides a programming model on top of WCF for consuming or sending messages to the queues, which makes this solution very appealing for this scenario. The Service Bus also provides Topics, which are an specific kind of queues that supports subscriptions.

By using Service Bus Queues, the calls to any third party service could be eventually wrapped up in WCF services that are invoked by the web application. The following image illustrates the possible architecture,

One of the core classes in the WCF programming model for the Service Bus Queues is BrokeredMessage. This class represents a message that can be sent to/from an existing queue, and contains a lot of standard properties such as MessageId, ReplyTo, SessionId or Label to name a few. It also contain a dictionary for custom properties that an application can assign to the message.

In the example above, the MessageId property can be used to correlate the input and out messages in the queue and update the corresponding result in the web application. The WCF service can also use the ReplyTo property, which represents the queue name in which the response should go. Sessions is another concept supported in the Service Bus Queues, which are useful for correlating a set of messages as a batch for processing. This is something optional and requires the queue to support sessions when they are created.

In WCF, the BrokeredMessage is assigned to the service call with a message property BrokeredMessageProperty as it is illustrated bellow,

var channelFactory = new ChannelFactory<ICRMServiceClient>("crminput");

var clientChannel = channelFactory.CreateChannel();

// Use the OperationContextScope to create a block within which to access the current OperationScope

using (var scope = new OperationContextScope((IContextChannel)clientChannel))

    // Create a new BrokeredMessageProperty object

    var property = new BrokeredMessageProperty();

    // Use the BrokeredMessageProperty object to set the BrokeredMessage properties

    property.Label = "Incident";

    property.MessageId = Guid.NewGuid().ToString();

    property.ReplyTo = "sb://xxx.servicebus.windows.net/input";

    // Add BrokeredMessageProperty to the OutgoingMessageProperties bag provided

    // by the current Operation Context

    OperationContext.Current.OutgoingMessageProperties.Add(BrokeredMessageProperty.Name, property);

    //Do the service call here

On the service side, the BrokeredMessageProperty instance can be retrieved in a similar way

var incomingProperties = OperationContext.Current.IncomingMessageProperties;

var property = incomingProperties[BrokeredMessageProperty.Name] as BrokeredMessageProperty;

Another important feature in the programming model for supporting execution retries in our example is the ReceiveContext. By decorating the WCF service contract with the ReceiveContextEnabled attribute, we can manually specify whether the operation was successfully completed or not. If the operation was not completed, the message will remain in the queue and the operation will be executed again next time.

[ServiceContract()]

public interface ICRMService

    [OperationContract(IsOneWay=true)]

    [ReceiveContextEnabled(ManualControl = true)]

    void CreateCustomer(Customer customer);

The following code shows how the operation implementation looks like,

var incomingProperties = OperationContext.Current.IncomingMessageProperties;

var property = incomingProperties[BrokeredMessageProperty.Name] as BrokeredMessageProperty;

//Complete the Message

ReceiveContext receiveContext;

if (ReceiveContext.TryGet(incomingProperties, out receiveContext))

   //Do Something

   receiveContext.Complete(TimeSpan.FromSeconds(10.0d));

else

   throw new InvalidOperationException("...");

As you can see, the ReceiveContext instance is marked as complete or implicitly set as not complete when an exception is thrown.

The assemblies for the Service Bus SDK are available as part of a Nuget package “Windows Azure Service Bus”. As part of the package registration, all the required configuration extensions for the WCF such as custom bindings and behaviors are also added in the application configuration file.

NetMessagingBinding is the one you need to use for sending or receiving messages from a queue. That binding is constantly polling the queues for detecting new messages, and activating the WCF service when a new message arrives. For that reason, you need to keep the web application App pool running all the time. This can be accomplished in Windows Azure with a simple approach as this one mentioned by Christian Weyer in this post.