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("")
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 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


A great site

Elliot Balynn's Blog

A directory of wonderful thoughts

HarsH ReaLiTy

A Good Blog is Hard to Find

Softwarearchitektur in der Praxis

Wissenswertes zu Webentwicklung, Domain-Driven Design und Microservices

Technology Talks

on Microsoft technologies, Web, Android and others

Software Engineering

Web development

Disparate Opinions

Various tidbits

chsakell's Blog


Guru N Guns's

OneSolution To dOTnET.

Johnny Zraiby

Measuring programming progress by lines of code is like measuring aircraft building progress by weight.

%d bloggers like this: