September 23, 2014 at 09:58

Implementing a web-based client-server application using OWIN

Introduction


The subject of OWIN has been touched on many times in Habré , however, questions about the implementation of applications and components using OWIN still pop up. In this publication, I will start with the standard Visual Studio 2013 template and demonstrate the implementation of the application architecture. I will also show how to use one DI container - for both MVC and WebApi within the same project.

Configuring WebApi


In the standard VS2013 template, WebApi is configured in global.asax. Move it to the Startup class.

Now register the OWIN module WebApi. To do this, we need to install the appropriate NuGet package. Open the Package Manager Console and enter:

PM> Install-Package Microsoft.AspNet.WebApi.Owin


After installing the package, we can register OWIN Middleware for WebApi.

var apiConfig = ConfigureWebApi();
ConfigureDependencyInjection(app, apiConfig);
app.UseWebApi(apiConfig);


We will talk about the “ConfigureDependencyInjection” method later.

Configuring a DI Container


In this example, I use the Autofac DI container, as he already has the necessary DependencyResolver class implementations for WebApi and MVC, as well as extension methods for integrating with OWIN.

Install the necessary modules:

PM> Install-Package Autofac.Mvc5
PM> Install-Package Autofac.WebApi2.Owin


To integrate MVC and Owin, you need to install another package:

PM> Install-Package Autofac.Mvc5.Owin


Since I want to demonstrate the use of a single container for WebApi and MVC, the container initialization will be located in the OWIN configuration class.

private void ConfigureDependencyInjection(IAppBuilder app, HttpConfiguration apiConfig)
{
    var builder = new ContainerBuilder();
    Assembly executingAssembly = Assembly.GetExecutingAssembly();
    builder.RegisterApiControllers(executingAssembly);
    builder.RegisterControllers(executingAssembly);
    RegisterComponents(builder);
    var container = builder.Build();
    app.UseAutofacMiddleware(container);
    var apiResolver = new AutofacWebApiDependencyResolver(container);
    apiConfig.DependencyResolver = apiResolver;
    app.UseAutofacWebApi(apiConfig);
    var mvcResolver = new AutofacDependencyResolver(container);
    DependencyResolver.SetResolver(mvcResolver);
    app.UseAutofacMvc();
}


With this code, everything is very simple. First, we create a ContainerBuilder and register our controllers in it, then register the services. After that, create a container and set it as DependencyResolver for WebApi and Mvc.

Here you need to pay attention to the line app.UseAutofacMvc () ;. Calling this method allows you to extend LifetimeScope objects so that they are used in MVC.

Implementing an Application Security Component Using AspNet Identity as an Example


Component Registration

AspNet Identity packages are already installed in the standard application template, however, if you started with an empty template, you must install the following packages:

PM> Install-Package Microsoft.AspNet.Identity.Owin
PM> Install-Package Microsoft.AspNet.Identity.EntityFramework


To implement AspNet Identity security, we need to register four classes:

  • Usermanager
  • SignInManager
  • IUserStore
  • IAuthenticationManager


With SignInManager component registration and IUserStore there are no problems, their registration code is given below.

private void RegisterComponents(ContainerBuilder builder)
{
    builder.RegisterType().As().InstancePerRequest();
    builder.RegisterType().As>().InstancePerRequest();
    builder.RegisterType>().As>().InstancePerRequest();
}


It is worth noting that I used the AspNet.Identity.EntityFramework library class as IUserStore, so the ApplicationDbContext class is present in the registration.

Next, you need to register the IAuthenticationManager. Here it is necessary to pay attention that the implementation of the IAuthenticationManager interface does not have an open constructor, so we set the factory method.

builder.Register((c, p) => c.Resolve().Authentication).InstancePerRequest();


The IOwinContext.Authentication property is actually a factory method and provides us with a new AuthenticationManager with every call.

Now you need to register the UserManager class. The constructor of this class is not of particular interest, but the factory method “Create” is defined below in this class, which is responsible for creating and configuring this class.

We will transfer the creation and configuration of the class to the factory method autofac to keep the entire configuration together. In this case, we will face a small problem. The Create method accepts IdentityFactoryOptions as one of the arguments. We cannot create IdentityFactoryOptions ourselves. Fortunately, there is the IAppBuilder.GetDataProtectionProvider () method located in the Microsoft.Owin.Security.DataProtection namespace.

var dataProtectionProvider = app.GetDataProtectionProvider();
builder.Register>((c, p) => BuildUserManager(c, p, dataProtectionProvider));


Business logic

Now you can use our DI container to implement the application logic. If we look in the AccountController, we will see such lines there:

HttpContext.GetOwinContext().Get();
HttpContext.GetOwinContext().GetUserManager();
HttpContext.GetOwinContext().Authentication;


Using these lines, objects of the UserManager, SignInManager, and IAuthenticationManager classes are resolved, respectively. This approach is proposed by the AspNet Identity library. It does not suit us for several reasons, the most obvious of them:

  1. Using ServiceLocator does not allow us to control dependencies inside the class.
  2. The appearance of the second DI container, which directly depends on AspNet Identity.


We will remove the properties UserManager, SignInManager, AuthenticationManager and add initialization of the _userManager and _authenticationManager fields through the constructor. Also remove the constructor without parameters. Similarly, fix the ManageController. In the Identity configuration method, we remove the lines that register our classes in OwinContext.

    app.CreatePerOwinContext(ApplicationDbContext.Create);
    app.CreatePerOwinContext(ApplicationUserManager.Create);
    app.CreatePerOwinContext(ApplicationSignInManager.Create);


Now you can remove the extra packages that are responsible for integrating WebApi with IIS.

Uninstall-Package Microsoft.AspNet.WebApi
Uninstall-Package Microsoft.AspNet.WebApi.WebHost


Conclusion


In this publication, we learned how to implement the modular structure of an ASP.Net application with component registration as OWIN Middleware, registered a single Dependency Injection container for ASP.Net MVC and WebApi and implemented the application security module with it.

The full application code is available at GitHub .
Tags:

Also popular now: