Raise exception if HTTP response is other than Success

The standard way nowadays to perform a HTTP request in .NET is using the HttpClient object in the System.Net.Http namespace. There are other objects with a similar purpose, such as HttpWebRequest but HttpClient has probably become the most common.

Read more of this post

Domain Driven Design with Web API extensions part 4: domain events in code


In the previous post we looked at some theory behind domain events. We said that domain events were events that happen within a domain and that other components of the system may be interested in. The domain becomes the publisher – or producer – and the listeners will be the subscribers, or consumers of the domain messages.

We established that we’d solve the communication of consumers and subscribers through a mediator which stands in between. Publishers and subscribers will stay decoupled that way.

In this post we’ll implement the theory in C# code.

Read more of this post


The portable Web API client library

I this short post I just would like to draw your attention to a portable Web API client library available from NuGet. You can use it in multiple project types, like console and Window Phone apps where you need to perform HTTP-related actions.

The library is available from within Visual Studio in the NuGet package manager:

Web API client library in NuGet

From then on you can use the HttpClient object from the System.Net.Http namespace to initiate HTTP calls, e.g.:

HttpClient client = new HttpClient()
	BaseAddress = new Uri("http://www.myapi.com/")
HttpResponseMessage response = await client.GetAsync("customers");

Web API 2 security extensibility points part 5: OWIN


In the previous post we discussed how to add a custom authorisation filter to your .NET web application. We saw how you could derive from the AuthorizeAttribute class and implement your own logic for the IsAuthorized and HandleUnauthorizedRequest methods. The methods in the custom authorisation filter are called after any authentication filter is applied and before the appropriate controller action is executed.

In this post we’ll look at another entry point where you can apply your custom security logic in a .NET web application: OWIN

Read more of this post

Web API 2 security extensibility points part 4: custom authorisation filters


In the previous post we built a custom HTTP message handler for our demo Web API 2 application. We saw how a registered message handler intercepts all calls to your API before authentication filters are executed. We also wrote a couple of examples where we checked for the presence of a custom header and of an authorisation header. We finally showed how to set the principal for the current HTTP call.

In this post we’ll see another way you can intercept the calls to your API. Authorisation filters are executed after authentication filters and before your controller action methods. That is the last stage where you can add your custom auth-related logic.

Read more of this post

Web API 2 security extensibility points part 3: custom message handlers


In the previous post we looked at how to implement your own custom authentication filter. Authentication filters – and filters of type IFilter in general – are executed just before your controller action methods are run. We saw how to implement the IAuthenticationFilter interface and how to apply the custom filter both as an attribute and as a global filter.

In this post we’ll look at HTTP message handlers and specifically how to add your own message handler. Message handlers are executed even before any custom filter so they provide an early entry point into the life cycle of a web application. There’s nothing stopping us from adding an initial security check or a full-blown login mechanism already at that stage. We can check e.g. if a mandatory custom header has been provided and reject all incoming HTTP calls that don’t fulfil this requirement up front.

Read more of this post

Web API 2 security extensibility points part 2: custom authentication filter


In the previous post we introduced the topic and main goals of this series. We also set up a demo Web API 2 project which we’ll use throughout. We also briefly investigated the HTTP request context and how we could extract information about the current user of the HTTP request from it.

In this post we’ll see how to write your own custom authentication filter attribute. We’ll only look at a simple example to show how to access the request context from an authentication filter. Further down you’ll find a reference to a post on http://www.asp.net which takes up a much more detailed example.

Read more of this post

Web API 2 security extensibility points part 1: starting point and HTTP request context


Web API 2 comes with a number of new security features. In this new series we’ll concentrate on the HTTP request context and its Principal property. In particular we’ll see how to hook into the different extensibility points in the Web API. These extensibility points offer you to plug in your security-related checks at different points in the application lifetime when a request hits your API. You can carry out a number of checks and modify the request Principal according to your business rules and needs.

I’m building the demo in Visual Studio 2013. I’m not sure at this point how much the Web API template will change in Visual Studio 2015.

Read more of this post

Building a Web API 2 project from scratch using OWIN/Katana .NET Part 5: adding an IoC


In the previous post we transformed the CustomersApi application a little bit. We added a customer repository and a customer service. We also transformed the Get action method of CustomersController into an asynchronous one.

We ended up having to construct the dependencies of CustomersController in the constructor like this:

public CustomersController()
	_customerService = new CustomerService(new CustomerRepository());

In this post we’ll get rid of this direct control over the controller dependencies. Instead, we’ll let an ICustomerService object be injected into the controller through its constructor.

Read more of this post

Building a Web API 2 project from scratch using OWIN/Katana .NET Part 4: async controllers and mini-DDD


In the previous post we briefly looked at a new hosting project by Microsoft called Helios. It is meant to be the future of web application deployment where Helios removes the necessity of having the entire System.Web dependency in your web project. We saw that Helios is only in a preview state so it shouldn’t be used for real-life projects yet.

In this post we’ll diverge from OWIN/Katana and instead see how we can add asynchronous controller methods to our current CustomersApi web project. We’ll also build a miniature version of a layered application. We’ll put the layers into separate folders for simplicity.

Read more of this post

Elliot Balynn's Blog

A directory of wonderful thoughts

Software Engineering

Web development

Disparate Opinions

Various tidbits

chsakell's Blog


Once Upon a Camayoc

Bite-size insight on Cyber Security for the not too technical.

%d bloggers like this: