At some point you might need to plug into or configure the OWIN pipeline that is used by Azure Mobile Service. The purpose of this post is to demonstrate 3 ways to achive this. Let’s get started.
The 3 ways that we are going to look at today are:
- StartupOwinAppBuilder.Initialize()
- Using a custom IOwinAppBuilder
- Using a IOwinAppBuilderExtension
Before we actually look at each item individually I will summarize how OWIN is configured in Azure Mobile Services.
If you take a look at Microsoft.WindowsAzure.Mobile.Service.dll you will see that the entry point of OWIN configuration is a class called StartupOwinAppBuilder. The entry point is specified with the help of the OwinStartup attribute.
|
1 |
[assembly: OwinStartup(typeof(StartupOwinAppBuilder))] |
StartupOwinAppBuilder does not actually configure OWIN but in fact it delegates the configuration. By default, AMS (Azure Mobile Services) will look for a class that implements IOwinAppBuilder and that implementation will be invoked by StartupOwinAppBuilder. The class OwinAppBuilder is one such implementation and it will be used by default. This is where the actual OWIN configuration of AMS is conducted. Now that we understand how Azure Mobile Services starts the OWIN configuration process, let’s learn how we can actualy plug into it.
Using StartupOwinAppBuilder.Initialize()
With Microsoft.WindowsAzure.Mobile.Service.Config.StartupOwinAppBuilder.Initialize() you can set a delegate that will be used to configure the OWIN pipeline. The catch here is that by using StartupOwinAppBuilder.Initialize you actually override the default delegate that has been selected for you by the framework. All of the default OWIN configurations fly out the window and you are on your own. Basically this is the most drastic measure – in most cases the other two options will better suit your needs.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
public static class WebApiConfig { public static void Register() { var options = new ConfigOptions(); var config = ServiceConfig.Initialize(new ConfigBuilder(options)); // Make sure this is after ServiceConfig.Initialize // Otherwise ServiceConfig.Initialize will overwrite your changes Microsoft.WindowsAzure.Mobile.Service.Config.StartupOwinAppBuilder.Initialize(appBuilder => { //Configure OWIN here appBuilder.UseFacebookAuthentication("", ""); }); Database.SetInitializer(new MobileServiceInitializer()); } } |
Using a custom IOwinAppBuilder
The second approach is to create our own IOwinAppBuilder implementation and plug that into the OWIN initialization process. Since we normally want to only add to the default OWIN configuration we will inherit from the built-in OwinAppBuilder class – that way we can easily add additional configuration steps instead of overwriting the whole process.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
public class MyCustomOwinAppBuilder : OwinAppBuilder { public MyCustomOwinAppBuilder(HttpConfiguration config) : base(config) { } public override void Configuration(IAppBuilder appBuilder) { // Default configuration base.Configuration(appBuilder); // Custom configuration appBuilder.UseMyAwesomeMiddleware(); } } |
The only thing left to do now is tell ASM to use our custom builder. All custom implementation like IOwinAppBuilder are resolved using Autofac – the DI framework used by Azure Mobile Seervices. To enable this scenario we have to make minor modifications to our WebApiConfig.Register() method.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
public static class WebApiConfig { public static void Register() { var options = new ConfigOptions(); // Create ConfigBuilder with another constructor var builder = new ConfigBuilder(options, ConfigureDependencies); var config = ServiceConfig.Initialize(builder); Database.SetInitializer(new MobileServiceInitializer()); } private static void ConfigureDependencies(HttpConfiguration configuration, ContainerBuilder builder) { // Configure DI here // Register our custom builder var instance = new MyCustomOwinAppBuilder(configuration); builder.RegisterInstance(instance).As<IOwinAppBuilder>(); } } |
Once we have registered our builder instance, ASM will be able to locate it and use it. Something to have in mind is that only one IOwinAppBuilder can be used at a time, i.e, even if you have registered 10 builder instances, only the last registered builder will be invoked.
Using IOwinAppBuilderExtension
The last option is the least invasive one. Similarly to the IOwinAppBuilder, we just have to implement a simple interface. The difference here is that we cannot override the default OWIN configuration and we can register as many IOwinAppBuilderExtension types/instances as we fancy. Behind the scenes the framework is using the built-in OwinAppBuilder and at some point of its OWIN configuration flow it gets all IOwinAppBuilderExtension types and executes them one by one. Pretty neat.
|
1 2 3 4 5 6 7 |
public class MyOwinAppBuilderExtension : IOwinAppBuilderExtension { public void Configure(Owin.IAppBuilder appBuilder) { appBuilder.UseMyAwesomeMiddleware(); } } |
And here is how we register the extensions:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
public static class WebApiConfig { public static void Register() { var options = new ConfigOptions(); // Create ConfigBuilder with another constructor var builder = new ConfigBuilder(options, ConfigureDependencies); var config = ServiceConfig.Initialize(builder); Database.SetInitializer(new MobileServiceInitializer()); } private static void ConfigureDependencies(HttpConfiguration configuration, ContainerBuilder builder) { // Configure DI here // Register our extensions builder.RegisterType<MyOwinAppBuilderExtension>().As<IOwinAppBuilderExtension>(); builder.RegisterType<MyOwinAppBuilderExtension2>().As<IOwinAppBuilderExtension>(); } } |
Are you using any of the three methods that are outlined here? Do you like the current options?
-
Chase Oliphant
-
Milan
-
Chase Oliphant
-
Chase Oliphant
-
Aidan Casey
-
Milan