Creating X509Certificates from an Azure Web Service results in 'The system cannot find the file specified'

In a project I have worked on we wanted to create in memory certificates to use in our web application.

There are a lot of reasons why you don't want to enable this kind of functionality, but let's keep it
simple and only talk about this scenario without arguing.

In our code we used X509Certificate2 to create the in memory certificate using a byte array (byte[] certificateData) and
a password (string sercurePassword).

return new X509Certificate2(certificateData, securePassword);

To make our live as developers a little simpeler we created both a Web project (IIS Express) and a Console (Selfhost) project in Visual Studio.
During development I mainly use the Selfhost but the above solution works very nice in both the Selfhost as the Web Project. So I created a pull request and my colleages reviewed and completed the pull request. The nice thing about our build/release cycle is that in about 5 minutes the above code was deployed to Azure in de Development
Environment.

WHAT???? It's not working......

After looking in the Error Log I found this error:

"The system cannot find the file specified"

WHAT?? I don't have a file.. so.. which file can't be found...
All the code is only using in memory variables... Help!!!

Luckily I found the answer in one of the stack overflow answers.

Due to the fact that the Azure Web Service does not have a User Profile it cannot create a Certificate for you. To fix this problem set the StorageFlags of the X509Certificate2 with the following values:

return new X509Certificate2(
    certificateData, 
    securePassword,
    // MachineKeySet and Exportable are needed to be able to create Certificates inside
    // Azure Web Services
    X509KeyStorageFlags.MachineKeySet | 
    X509KeyStorageFlags.Exportable);

With these settings the Certificate is created successfully and my app is also working is Azure.

Happy Coding ;-)

Autofac with SignalR and WebApi in Owin registration solution (without using container.Update)

In one of my Owin projects I want to use SignalR and WebApi. Autofac is used as Dependency injection, but somehow this results in a lot of registration problems. 

A lot of samples I've found where using the 

GlobalHost.ConnnectionManager.GetHubContext<>

Do not use GlobalHost in Owin

But the SignalR Autofac documentation clearly states that the GlobalHost static class cannot be used in a Owin project. You should use the IConnectionManager interface.

So I tried to create a Generic HubContextProvider<THubClient> which can be used to get the typed HubContext from the ConnectionManager.

public interface IHubContextProvider<THubClient>
        where THubClient : class
{
    IHubContext<THubClient> GetHubContext<THub>()
        where THub : Hub<THubClient>;
}

public class HubContextProvider<THubClient> : IHubContextProvider<THubClient>
        where THubClient : class
{
    private readonly IConnectionManager connectionManager;
    public HubContextProvider(IConnectionManager connectionManager)
    {
        this.connectionManager = connectionManager;
    }

    public IHubContext<THubClient> GetHubContext<THub>()
        where THub : Hub<THubClient>
    {
        return this.connectionManager.GetHubContext<THub, THubClient>();
    }
}

This class is used in Singleton HubHandlers, which are classes that are used to communicate back to the Clients subscribed. In the generic base class the property HubContext is set using the HubContextProvider.

Registration

In the Startup class of the application I created a ContainerBuilder and register all the types in the application. 

var builder = new ContainerBuilder();

// Register all typed needed in the application
// ....
builder.RegisterHubs(Assembly.GetExecutingAssembly());

var container = builder.Build();

Create Dependency Resolvers

For using WebApi and Autofac you need to create the AutofacWebApiDependencyResolver.

HttpConfiguration httpConfig = new HttpConfiguration();
var webApiResolver = new AutofacWebApiDependencyResolver(container);
httpConfig.DependencyResolver = webApiResolver;

And for using SignalR and Autofac you need to create the AutofacDependencyResolver

HubConfiguration hubConfig = new HubConfiguration();
var signalRResolver = new AutofacDependencyResolver(container);
hubConfig.Resolver = signalRResolver;

Error resolving

I followed the instructions of Autofac to create correct registrations for SignalR and WebApi. But when the application is started I got the following error:

None of the constructors found with 'Autofac.Core.Activators.Reflection.DefaultConstructorFinder'
on type 'HubContextProvider`1[IStateHubClient]' can be invoked with the available services and parameters:
Cannot resolve parameter 'Microsoft.AspNet.SignalR.Infrastructure.IConnectionManager connectionManager'
of constructor 'Void .ctor(Microsoft.AspNet.SignalR.Infrastructure.IConnectionManager)'.

Ok... so somehow I am missing the IConnectionManager, so who is responsible for creating/register this interface? 

Somehow this interface is created by the AutofacDependencyResolver from Autofac SignalR, but is not injected in the container that is used by the application. 

Register IConnectionManager

There seems to be a simple solution for the error. Just register the IConnectionManager at the container yourself. But.. Where can I get the IConnectionManager? In the HubConfiguration!

builder.RegisterInstance(hubConfig.Resolver.Resolve<IConnectionManager>());

So the registration looks like this:

HttpConfiguration httpConfig = new HttpConfiguration();
HubConfiguration hubConfig = new HubConfiguration();

var builder = new ContainerBuilder();

// Register all typed needed in the application
// ....
builder.RegisterInstance(hubConfig.Resolver.Resolve<IConnectionManager>());
builder.RegisterHubs(Assembly.GetExecutingAssembly());

var container = builder.Build();

var webApiResolver = new AutofacWebApiDependencyResolver(container);
httpConfig.DependencyResolver = webApiResolver;

var signalRResolver = new AutofacDependencyResolver(container);
hubConfig.Resolver = signalRResolver;

After adding the registration of the IConnectionManager everything seems to be working during startup. But the SignalR hubs and the handler are not using the same IConnectionManager. It seems like that the 'new AutofacDependencyResolver(..)' overrides the IConnectionManager implementation internally. So when the Hub's are created it uses the internal IConnectionManager and the HubHandlers are using the just registered IConnectionManager.

So now we need to have a solution for this.

Solution 1 [builder.Update(..)]

After using our big friend Google I found one solution which uses the ContainerBuilder.Update() method. First we need to register all our own registrations, then create the dependency resolvers and after the add the IConnectionManager to the current container.

HttpConfiguration httpConfig = new HttpConfiguration();
HubConfiguration hubConfig = new HubConfiguration();

var builder = new ContainerBuilder();

// Register all typed needed in the application
// ....
builder.RegisterHubs(Assembly.GetExecutingAssembly());

var container = builder.Build();

var webApiResolver = new AutofacWebApiDependencyResolver(container);
httpConfig.DependencyResolver = webApiResolver;

var signalRResolver = new AutofacDependencyResolver(container);
hubConfig.Resolver = signalRResolver;

var signalRBuilder = new ContainerBuilder();
signalRBuilder.RegisterInstance(hubConfig.Resolver.Resolve<IConnectionManager>());
signalRBuilder.Update(container);

Solution 2 [without builder.Update(...)]

However solution 1 seems to work it is best practice to not update the registrations after building the container. See Consider a container as immutable in the Autofac documentation.

This is also visible in Visual Studio with the warning:

Warning	CS0618	'ContainerBuilder.Update(IContainer)' is obsolete: 
'Containers should generally be considered immutable. Register all of your dependencies 
before building/resolving. If you need to change the contents of a container, you
technically should rebuild the container. This method may be removed in a future major release.

Mmm... we should fix this...before getting some major release of Autofac that does not support the update() method.

I've seen some complex solutions for registration of the IConnectionManager using different kind of complex methods. Like registration of the SignalR dependency resolver and using this resolver again for getting the connection manager. I also tried a solution for registration using lambda method.

builder.Register(context => hubConfig.Resolver.Resolve<IConnectionManager>());

Idea behind this was to be able to register the IConnectionManager but when the Resolve() occurs use the hubConfig to get the IConnectionManager. But this results in a StackOverflowException... Nice :(...

So now the solution that works for me and is not using the ContainerBuilder.Update() method is by changing the HubContextProvider from the beginning of the post to use the HubConfiguration instead of the IConnectionManager.

public class HubContextProvider<THubClient> : IHubContextProvider<THubClient>
    where THubClient : class
{
	private readonly IConnectionManager connectionManager;
	public HubContextProvider(HubConfiguration hubConfiguration)
	{
		this.connectionManager = hubConfiguration.Resolver.Resolve<IConnectionManager>();
	}

	public IHubContext<THubClient> GetHubContext<THub>()
		where THub : Hub<THubClient>
	{
		return this.connectionManager.GetHubContext<THub, THubClient>();
	}
}

For this to work, the HubConfiguration must be available in the container, but that one simple extra call:

HttpConfiguration httpConfig = new HttpConfiguration();
HubConfiguration hubConfig = new HubConfiguration();

var builder = new ContainerBuilder();

// Register all typed needed in the application
// ....
builder.RegisterHubs(Assembly.GetExecutingAssembly());
builder.RegisterInstance(hubConfig);

var container = builder.Build();

var webApiResolver = new AutofacWebApiDependencyResolver(container);
httpConfig.DependencyResolver = webApiResolver;

var signalRResolver = new AutofacDependencyResolver(container);
hubConfig.Resolver = signalRResolver;

There is no need for registering the IConnectionManager anymore.

Yes... No I have a solution that works with Owin, SignalR, WebApi and Autofac without using ContainerBuilder.Update().

Update:

I got some questions about the registration of the HubContextProvider<>. This is the registration I used:

builder.RegisterGeneric(typeof(HubContextProvider<>)).As(typeof(IHubContextProvider<>));

With this all the HubContextProviders are automatically added to the registration.

The REST you know!! Or not? Part 2

In my previous post about REST you could read about the basics of a REST interface. In this post I will try to explain the HTTP Verbs that you should use with REST in detail.

Reponse type

Responses of the REST API can be any form, but mostly used are XML and JSON. In this blog I will use JSON as request and response types. But in principle it does not matter if you use XML or JSON.

Safe and Idempotent

Every time that you communicate with a REST API some sort of operation is executed on the server. This can be a request operation, but can also be adding, updating or deleting objects. When an operation does not change any data on the server side an operation can be called 'safe'. This means that if you execute the operation multiple times no data will be changed on the server and the data is 'safe'. If an operation can be executed multiple times and the outcome of the operation is the same after the first operation this is called 'idempotent'. 

Create a new object (POST)

The POST verb is used for creating objects. The image below shows an example of a POST for creating a Rental. The example below shows the POST with a rental object as body (JSON object). In the rental object you can see the Id of the Car and the Id of the Customer that rents the car. There are also other properties like startdate and many more. The POST is executed on the '/rentals' resource uri.

 

 

If the POST is successful the server will respond with a HTTP Status Code 201 (Created). The location of the newly created object is returned as Uri in the Location Header of the response. By executing the location URI the objects information can be requested.

If you POST a second time with same information 2 identical objects will be created with a different identifier. If your object model has constraints on the data whereby the object cannot exists multiple times the server may respond with a HTTP Status Code 409 (Conflict) which means that the object cannot be created again.

When executing the POST data on the server will likely change and therefor this operation is not 'safe'.  The post is no 'idempotent' operation because when you execute the POST multiple times the response results after the first request will not be the same as the first response result.

In the above example both the ID of the Customer as the ID of the Car are send with the request body. One other option is to use the navigation relation between Customer/Rental/Car to POST the new rental. This is shown in the picture below.

 

 

In this example you can see that the uri is different from the first example. Here the customer found by requesting through the customers resource using the ID of the customer as URI part. This way of navigation can be useful when the client for example has a list of Customers. When you click on a customer you can choose a Car and select the car for rental. Navigation to the customer was already setup using the URI so the request object can be sent without a CustomerID.

If the data send to the server in the request is invalid the server may respond with the HTTP Status Code 400 (Bad Request). The client then know that is should change the request body before sending it again.

Querying one ore multiple objects (GET)

When a POST is performed the location of the new created object is returned in the response. To get the information from the URI the URI must be requested with the GET verb. The GET verb can also be use the request a list of objects. If a GET is successful it will return a HTTP Status Code 200 (OK). In the response the requested object or list of objects is returned.

 

 

As you can see in this example the GET is executed on the location that was returned by the POST operation before. The body of the response contains the information as posted before. If the object requested does not exists the server will respond with a HTTP Status Code 404 (Not Found). The client will then know that is must create the object before requesting it.

In the URI above you can see that one rental object is requested with the id 'a4f5s2f'. But what if you want to display a list of all the cars that can be rent. For getting lists with objects the GET verb is also used but without the ID part of the URI.

 

 

The body of a GET from a single item of a GET with a list of item differ because the GET on a list of items will return an array of objects instead of one object.

The GET operation should be a 'safe' operation and cannot change data on the server. If you request the GET uri multiple times the result will be the same every time you request again therefor the GET operation is a 'idempotent' operation.

Updating an object (PUT)

If you want to update a resource the PUT verb should be used. The PUT is mostly used with an URI that contains an identifier so the server knows which object it should change. In the request body of the PUT the complete object is send to the server and the server will overwrite the data with this new information. If the update is successful the server will respond with the HTTP Status Code 200 (OK). This is the same as responded by the GET verb. Like with the POST operation if the data sent using the PUT verb is not valid the server will respond with the HTTP Status Code 400 (Bad Request).

 

 

As you can see in the example above the same URI is used as with the GET request. The body of the response contains the same information as the body of the request because if the update was successful the data is changed. If the data was already changed on the server it may respond with a HTTP Status Code 409 (Conflict). In some scenario's the server may respond with HTTP Status Code 204 (No Content) instead of the HTTP Status Code 200 (OK). This is mostly done because of minimizing data traffic between server and client. With the 204 the server presumes that the client will hold the objects after adding them to the PUT request.

If the server cannot find the object requested it will respond with a HTTP Status Code 404 (Not Found).

What about creating objects with a PUT? PUT can be used to create objects also and if that's the case then the server will not respond with a 404 (Not Found) but with a HTTP Status Code 201 (Created). So when to use PUT and when to use POST if both can create objects? The answer is fairly simple: If the id's are in control of the server POST should be used for creating objects. If the id's can be decided by the client PUT can also be used for creating objects.

The PUT is not 'safe' and but is 'idempotent'

Deleting objects (DELETE)

When objects are no longer needed the client can request a deletion of the object. The deletion is performed with a DELETE verb. The URI used for the DELETE operation is the same as the URI for the GET and/or PUT. If the object is deleted successfully the server will respond with a HTTP Status Code 204 (No Content).

 

 

It is also possible for the server to respond with HTTP Status Code 200 (OK) if the body contains the deleted object. This can be useful when implementing some sort of undo mechanism. On other (success) response  can be HTTP Status Code 202 (Accepted), this is used when the server accepts the delete but the object is not deleted yet.

The DELETE operation is not a 'safe' operation but can be implemented as 'idempotent' operation. If a object that the client is trying to delete is already deleted the server may response with the HTTP Status Code 200 (OK). This indicates that the delete is executed even if the object was not there. In this scenario it does not matter if you execute the delete multiple times the result will be the same and therefor the operation is 'idempotent'. If the server returns a HTTP Status Code 404 (Not Found) on deletion of a not existing object the operation is not 'idempotent' because executing the operation multiple times will then result in a 200 the first time and 404 every next attempt.

It's up the the designer of the API how this works, I personally prefer the 'idempotent' version of the DELETE operation. 

 

That's enough for today!

 

Other post(s) in this serie for know are:

The REST you know!! Or not? Part 1

Why this POST if you already know REST?

I have noticed that there are many different opinions about what REST is and how you can use to create an API that is easy to use. Sometimes REST API's are complex just because they are not created using correct REST. 

As a serious developer I don't want to write 'Bad Code' and hopefully I am not the only one! If you are planning to use REST and don't want to write 'Bad Code' either read this article. If you don't mind to write 'Bad Code' also read this article because you then know how to create 'Bad Code' by not implementing the solutions below ;-).

 

What is REST?

Let's begin with the basics. REST stands for Representational State Transfer (see WIKI - REST). Okay... So now you know, right? In short, REST is a communication protocol between client and server that is stateless. This means that the server does not keep track of the state between two requests. The communication can be cached for performance reasons. In most cases HTTP(S) will be used for communicating REST.

How does the communication work?

REST uses the HTTP verbs GET / POST / PUT / DELETE in most of the cases. Other Verbs can be used but in this article I will focus on these 4 verbs.

A lot of blogs and articles write about the REST verbs as a CRUD pattern with the following assumptions:

  • POSTCREATE (Insert)
  • GETREAD
  • PUT = UPDATE
  • DELETEDELETE

The above assumption is partially correct but you are not limited to this assumption. A PUT can also be used for the CREATE. This will be show in the PUT chapter below.

How do you think?

When you know other communication protocols between client and server you may have noticed that a lot of protocols are RPC (Remote procedure call) based. Which means that the client will request some operation from the server which will than result the output of the operation. REST is not RPC based but RESOURCE based, which means that your thinking pattern must change from RPC style (GetCars, RentCar) to RESOURCE based style (GET /cars, POST /rentals). Let's take a look how this really works. When you are implementing a REST API try to use Nouns and not to use Verbs for your URI's.

Domain model

When defining a REST interface the domain model for the rest interface must be clear. During a project changes will always occur, but some kind of domain model must be available to be able to define your model for the REST interface. 

The model I will use in my examples is about renting cars:

The model consists of 3 classes:

  • Customer which is the person that rents a car
  • Address which is an address of the customer 
  • Rental which is the resource for holding the rental period and link the Customer to a Car.
  • Car which is a car that can be rent.

When defining resources you have to identify the root aggregates of the model. For my model I see 3 root aggregate Customer, Rental, Car. From the application perspective these objects are likely to get their own screen with a list of object. All customers in the system, all Rentals in the system, all Cars in the system. Address is not a root aggregate because we will never lookup an Address on its own. Address will always be displayed for a Customer.

By identifying the root aggregates the following URI structure is appropriate:

/customers
/customers/{id}/addresses/
/rentals
/cars

One other resource can be the resource to show rentals for a customer:

/customers/{id}/rentals

 

In the next post(s) I will be talking about the different HTTP Verbs in detail, different Response Results, Security issues, Maturity model and lots of other topic about REST.

 

Other post(s) in this serie for know are: