All posts by Jorge Rowies

Validating requests in ASP.NET Web API (beyond ModelState.IsValid)

Lately I’ve been working with ASP.NET Web API and I had to solve a couple of issues regarding data validation when sending a request to the API.

Problem #1

When exposing an operation that receives several optional parameters (i.e. to perform a search), sending invalid parameters will not be detected by the API.

Example:

Given the following operation for searching albums: public IEnumerable Get(DateTime? releasedFrom = null, DateTime? releasedUntil = null, string albumName = null, string artistName = null)

Requests with invalid parameters in the query string like http://api.coolmusic/albums?foo=bar will not be validated by the API. This might cause serious problems, suppose we call the API with a small typo like releaseFrom instead of releasedFrom, we will receive a set of data that we think is filtered but actually it’s not filtered at all.

Problem #2

Similarly to the previous problem, sending invalid values in the body of a request will not be detected by the API when those values are serialized/deserialized into typed objects (i.e. using Web API formatters).

Example:

Given the following operation to update albums: public void Patch(int id, [FromBody]Album album)

Requests with invalid values in the payload will not be caught by the API:

Solution

I’m pretty sure there are many ways to solve these problems, but a simple an effective solution is to create action filters that will:

  • Validate the parameters of the operation against the parameters in the query string and return appropriate status codes if a mismatch is found
  • Use the API formatters to serialize the body into a JObject object and then make sure that all the props in the JObject have their corresponding property in the typed entity

Here’s the code for the action filters:

[csharp]
[AttributeUsage(AttributeTargets.Method)]
public class QueryStringParametersValidationAttribute : ActionFilterAttribute
{
public override void OnActionExecuting(HttpActionContext actionContext)
{
var parameters = actionContext.ActionDescriptor.GetParameters();
var queryParameters = actionContext.Request.GetQueryNameValuePairs();

var invalidParams = queryParameters.Select(kvp => kvp.Key).Where(
queryParameter => !parameters.Any(p => p.ParameterName.Equals(queryParameter, StringComparison.OrdinalIgnoreCase))).ToList();

if (invalidParams.Any())
{
var invalidParamsStr = invalidParams.Aggregate((current, next) => current + ", " + next);
actionContext.Response = actionContext.Request.CreateErrorResponse(
HttpStatusCode.BadRequest,
string.Format("Some of the parameters in the query string are invalid: {0}", invalidParamsStr));
}
}
}

[AttributeUsage(AttributeTargets.Method, AllowMultiple = true)]
public class BodyPropertiesValidationAttribute : ActionFilterAttribute
{
private readonly Type entityType;

private readonly string parameterName;

public BodyPropertiesValidationAttribute(Type entityType, string parameterName)
{
this.entityType = entityType;
this.parameterName = parameterName;
}

public override void OnActionExecuting(HttpActionContext actionContext)
{
var props = this.entityType.GetProperties(BindingFlags.Public | BindingFlags.Instance);

var jObject = (JObject)actionContext.ActionArguments[this.parameterName];

if (jObject == null)
{
actionContext.Response = actionContext.Request.CreateErrorResponse(
HttpStatusCode.BadRequest,
string.Format("Could not get values from body, parameter name: {0}", this.parameterName));
return;
}

var invalidProps = jObject.Properties().Select(p => p.Name).Where(
propName => !props.Any(pr => pr.Name.Equals(propName, StringComparison.OrdinalIgnoreCase))).ToList();

if (invalidProps.Any())
{
var invalidPropsStr = invalidProps.Aggregate((curr, next) => curr + ", " + next);
actionContext.Response = actionContext.Request.CreateErrorResponse(
HttpStatusCode.BadRequest,
string.Format("Some of the values received are invalid: {0}", invalidPropsStr));
}
}
}
[/csharp]

And how to use them:

[csharp]
public class AlbumsController : ApiController
{
[QueryStringParametersValidation]
public IEnumerable<Album> Get(
DateTime? releasedFrom = null, DateTime? releasedUntil = null,
string albumName = null, string artistName = null)
{
return new []
{
new Album()
{
Id = 1,
ArtistName = "Pearl Jam",
Name = "Ten",
ReleaseDate = new DateTime(1991, 8, 27)
},
new Album()
{
Id = 2,
ArtistName = "Soundgarden",
Name = "Superunknown",
ReleaseDate = new DateTime(1994, 3, 8 )
}
};
}

[BodyPropertiesValidation(typeof(Album), "album")]
public void Patch(int id, [FromBody]JObject album)
{
var a = album.ToObject<Album>();
}
}
[/csharp]

You can find the code for this post in GitHub.

I hope you find this useful!

Setup federated auth in an MVC 4 app using WIF 4.5 and Windows Azure ACS

In this post I’ll show a few simple steps to setup federated auth in an MVC 4 application using WIF 4.5 and ACS.

Read More

Entity framework performance issues with lazy relationships

During the last weeks I’ve been working in an application that uses Entity Framework (code-first) and I had a performance-related issue that I thought might worth sharing.

Read More

How to build a basic fluent interface in 8 steps

Disclaimer: the aim of this post is not to show a comprehensive list of the different techniques that can be used to write a fluent API, tons of good information is out there on the web and. If you are very interested in the subject, please take a look at Martin Fowler’s Domain-Specific Languages.

Now that I took that load off my back, let’s start writing a fluent interface.

Imagine we are developing an API to publish blog posts to multiple blogging platforms (Blogger, WordPress, TypePad and so on…), chances are that our (super-simplified) domain model will be something similar to this:

So, creating a new blog post should be:

[csharp]
var post = new BlogPost();
post.Title = "How to build a basic fluent interface in 8 steps";
post.Body = "<html>…</html>";

var author = new Author(); // We should check the authors repository
// before creating a new one
author.Name = "John Doe";
author.Email = "johndoe@email.com";
author.Twitter = "@johndoe";
post.Author = author;

post.Tags = "Fluent API, Internal DSL";
[/csharp]

Our domain model is very simple and the code for creating a blog post is not so bad to read or write, so in this case implementing a fluent interface might be somewhat unnecessary; but… it’s perfect for us to learn how to write a fluent API. Shall we?

Step 1 – Writing a draft of the interface

Write (in notepad) a draft of the fluent interface showing how you want it to look like (don’t think too much now on how you will implement the interface, just play around with the ideas)

This is what I came up with:


var post = Post
.Title("How to build a basic fluent interface in 8 steps")
.Body("...")
.Author()
.Name("John Doe")
.Email("johndoe@email.com")
.Twitter("@johndoe")
.Tags("Fluent API, Internal DSL");

Step 2 – Using a test-first approach

Once you found an option that satisfies you, put it into a test in Visual Studio and add the code you will need to validate the outcome of the fluent interface. Depending on the size of the API, you might want to do this gradually. In this case, we are going to leave the “Author” part out of the scope for now.

In the code below we are creating two BlogPost instances, the first one using the standard API and the second one using our new fluent API. After both instances are created, they are passed to the CheckEquivalence method. This method should check if both instances of BlogPost have the same title, body and tags.

[csharp]
[TestCase]
public void ConfiguringPostWithoutAuthor()
{
var expected = new BlogPost();
expected.Title = "How to build a basic fluent interface in 8 steps";
expected.Body = "<html>…</html>";
expected.Tags = "Fluent API, Internal DSL";

var post = Post
.Title("How to build a basic fluent interface in 8 steps")
.Body("<html>…</html>")
.Tags("Fluent API, Internal DSL");
BlogPost actual = post.Build();

Assert.IsTrue(TestsHelper.CheckEquivalence(expected, actual));
}
[/csharp]

This test, of course, won’t even compile.

Step 3 – Starting to implement the interface

Now, let’s start implementing the Post class. Note that the Title method is static so we can call it without creating a new instance of Post.

[csharp]
public class Post
{
public static Post Title(string title)
{
var post = new Post();
post.TitleValue = title;
return post;
}
}
[/csharp]

Step 4 – Adding more methods to the fluent interface

Once we have our starting point, continue adding the remaining methods (this time as instance methods, not static).

[csharp]
public class Post
{

public Post Body(string body)
{
this.BodyValue = body;
return this;
}

public Post Tags(string tags)
{
this.TagsValue = tags;
return this;
}
}
[/csharp]

Returning the same instance of the object we are building after each method call is one of the most common techniques used to write fluent interfaces, it’s called Method Chaining.

Step 5 – Completing the first iteration and running tests

Now, let’s implement the Build method by creating an instance of BlogPost based on the values provided with the fluent interface.

[csharp]
public class Post
{

public BlogPost Build()
{
var blogPost = new BlogPost();

blogPost.Title = this.TitleValue;
blogPost.Body = this.BodyValue;
blogPost.Tags = this.TagsValue;

return blogPost;
}
}
[/csharp]

Our test should be green now!

Step 6 – Don’t forget the Author

Here comes the tricky part, let’s add the Author now…

If we continue what we’ve been doing with the Title, Body and Tags methods, we should make Author return an instance of Post; but if we do that, we should put the methods Name, Email and Twitter in the Post class, and we don’t want that. What we want is having those methods in a separate class, so instead of returning an instance of Post we are going to return an instance of a new class (AuthorSpec). Let’s try it.

[csharp]
public class Post
{

public AuthorSpec Author()
{
var authorSpec = new AuthorSpec();
return authorSpec;
}
}

public class AuthorSpec
{
public AuthorSpec Name(string name)
{
this.NameValue = name;
return this;
}

public AuthorSpec Email(string email)
{
this.EmailValue = email;
return this;
}

public AuthorSpec Twitter(string twitter)
{
this.TwitterValue = twitter;
return this;
}
}
[/csharp]

Now let’s create a new test method, adding the “Author” code:

[csharp]
public void ConfiguringPostWithAuthor()
{
var expected = new BlogPost();
expected.Title = "How to build a basic fluent interface in 8 steps";
expected.Body = "<html>…</html>";
expected.Tags = "Fluent API, Internal DSL";
var author = new Author();
author.Name = "John Doe";
author.Email = "johndoe@email.com";
author.Twitter = "@johndoe";
expected.Author = author;

var post = Post
.Title("How to build a basic fluent interface in 8 steps")
.Body("<html>…</html>")
.Author()
.Name("John Doe")
.Email("johndoe@email.com")
.Twitter("@johndoe")
.Tags("Fluent API, Internal DSL");
BlogPost actual = post.Build();

Assert.IsTrue(CheckEquivalence(expected, actual));
}
[/csharp]

But wait! The compiler says that the Tags method is not recognized as a member of the AuthorSpec class. That’s because we are calling Tags over the return value of Twitter, which is an AuthorSpec object instead of a Post object.

When writing fluent APIs, it is very common to bump into this kind of problems, the most used solutions for this are ending the Author specification with an “end” method, or passing a nested closure to the Author method.

Step 7 – Closing the Author specification and running more tests

Option A, using an “End” method.

[csharp]
public class Post
{

public AuthorSpec Author()
{
this.authorSpec = new AuthorSpec(this);
return authorSpec;
}
}

public class AuthorSpec
{
public AuthorSpec(Post parent)
{
this.parent = parent;
}

public Post End()
{
return this.parent;
}
}
[/csharp]

How it looks like:

[csharp]
var post = Post
.Title("How to build a basic fluent interface in 8 steps")
.Body("<html>…</html>")
.Author()
.Name("John Doe")
.Email("johndoe@email.com")
.Twitter("@johndoe")
.End()
.Tags("Fluent API, Internal DSL");
[/csharp]

Option B, using a nested closure.

[csharp]
public class Post
{

public Post Author(Action<AuthorSpec> spec)
{
this.authorSpec = new AuthorSpec();
spec(authorSpec);
return this;
}
}
[/csharp]

How it looks like:

[csharp]
var post = Post
.Title("How to build a basic fluent interface in 8 steps")
.Body("<html>…</html>")
.Author(a => a
.Name("John Doe")
.Email("johndoe@email.com")
.Twitter("@johndoe"))
.Tags("Fluent API, Internal DSL");
[/csharp]

I personally prefer option B. I think it’s easier to read and the programmer doesn’t have to remember calling the “End” method.

After implementing one of these options, our test should be green.

Step 8 – Stepping into dangerous territories

Let’s imagine we want to force people using our API to set the author name first and then configure the email address or the twitter account, but not both (exclusive or). We can make use of interfaces to show only a filtered subset of the methods in the method chain.

[csharp]
public class Post
{

public Post Author(Action<IAuthorSpecAfterCreation> spec)
{
this.authorSpec = new AuthorSpec();
spec(authorSpec);
return this;
}
}

public interface IAuthorSpecAfterCreation
{
IAuthorSpecAfterName Name(string name);
}

public interface IAuthorSpecAfterName
{
IAuthorSpecAfterEmailOrTwitter Email(string email);
IAuthorSpecAfterEmailOrTwitter Twitter(string twitter);
}

public interface IAuthorSpecAfterEmailOrTwitter
{
}

public class AuthorSpec : IAuthorSpecAfterCreation,
IAuthorSpecAfterName, IAuthorSpecAfterEmailOrTwitter
{
public IAuthorSpecAfterName Name(string name)
{
this.NameValue = name;
return this;
}

public IAuthorSpecAfterEmailOrTwitter Email(string email)
{
this.EmailValue = email;
return this;
}

public IAuthorSpecAfterEmailOrTwitter Twitter(string twitter)
{
this.TwitterValue = twitter;
return this;
}
}
[/csharp]

This technique can become very useful, but the complexity of the API can grow quickly with so many interfaces here and there… use it with precaution.

The complete sources can be grabbed from here.

That’s it, I hope this helps :)

Fluent API for setting up Windows Azure ACS

During the last couple of months I’ve been working for the p&p guys at Microsoft, developing the sample application for a new guide around Windows Azure hybrid application integration.

One of the components of the sample solution is a console application that performs all the steps required to have the ACS and Service Bus namespaces properly configured. This application uses a set of wrappers around the ACS Management Service API.

While this is a great step towards simplifying the life of the developer, after I looked at the resulting code I realized that my life could have been simplified even more. That’s why I decided to spend some of my time developing a fluent API for setting up ACS namespaces.

This is how the API looks like:

[csharp]
var namespaceDesc = new AcsNamespaceDescription(
"somenamespace", "ManagementClient", "T+bQtqP21BaCLO/8D1hanRdKJF8ZYEV8t32odxP4pYk=");

var acsNamespace = new AcsNamespace(namespaceDesc);

acsNamespace
.AddGoogleIdentityProvider()
.AddServiceIdentity(
si => si
.Name("Vandelay Industries")
.Password("Passw0rd!"))
.AddRelyingParty(
rp => rp
.Name("MyCoolWebsite")
.RealmAddress("http://mycoolwebsite.com/")
.ReplyAddress("http://mycoolwebsite.com/")
.AllowGoogleIdentityProvider()
.SwtToken()
.TokenLifetime(120)
.SymmetricKey(
Convert.FromBase64String("yMryA5VQVmMwrtuiJBfyjMnAJwoT7//fCuM6NwaHjQ1="))
.AddRuleGroup(rg => rg
.Name("Rule Group for MyCoolWebsite Relying Party")
.AddRule(
rule => rule
.Description("Google Passthrough")
.IfInputClaimIssuer().Is("Google")
.AndInputClaimType().IsOfType(ClaimTypes.Email)
.AndInputClaimValue().IsAny()
.ThenOutputClaimType().ShouldBe(ClaimTypes.Name)
.AndOutputClaimValue().ShouldPassthroughFirstInputClaimValue())
.AddRule(
rule => rule
.Description("ACS rule")
.IfInputClaimIssuer().IsAcs()
.AndInputClaimType().IsAny()
.AndInputClaimValue().IsAny()
.ThenOutputClaimType().ShouldPassthroughFirstInputClaimType()
.AndOutputClaimValue().ShouldPassthroughFirstInputClaimValue())));

acsNamespace.SaveChanges(logInfo => Console.WriteLine(logInfo.Message));
[/csharp]

You can find more information in the project repository at github.

Oh, and please don’t forget to take a look at the hybrid application integration guide when it becomes available (a draft can be downloaded from here), these guys have been doing an incredible job !

That’s it, I hope this helps :)

Windows Azure Caching Service: How distributed and local caches work together

The intention of this post is to show how the distributed and local cache of the Windows Azure Caching Service work together. We are going to cover the implications of enabling the local cache feature, the interaction between the local and distributed caches, and how to prevent unexpected errors that can be caused by the in-memory nature of the local cache.

Read More

High memory consumption in WaWorkerHost.exe

When the memory usage of the WaWorkerHost.exe process starts going up without apparent reason, and you are using Tasks in your worker role, it might be the time to check for unhandled exceptions and start handling them properly.

Read More

Using Rule Actions in Windows Azure Service Bus Subscriptions

Setting rule actions in Service Bus Subscriptions is a useful mechanism for automatically modify properties of BrokeredMessages when they are sent to a Topic. Rule actions and filters can be combined to set property values based on conditions.

Read More