With reference to
I speak with no authority, only referencing what I did to get this to work. There is a lot of confusion over the use of Identity with OWIN, mainly from the sample code and lack of authoritative documentation thus far. It does look like this needs tidying up,
but I am not sure how that should be done as so much of it is internal code. I have found however that I can completely decouple my code from it as of Identity 2.0.1 (untested with Identity 2.1 as yet).
The samples include
From what I have found, there is no internal dependency on
, so unless you intend to use the
as a (poor mans) service locator you don't need to do this. Instead you can inject your per-request
from your IoC container into the classes that require it.
As you have seen, this is just a factory method which is then passed to OWIN through
. The intent is to create a single
per request. This is then used internally by using the
as a service locator. I read somewhere that one of the team said this was because they had no IoC injection to use, so they use the context dictionary instead.
acts as a service locator for other services, such as the
. This is then provided to the factory in the
. But from what I can work out, the
is a single instance, not per-request.
But this is where it gets strange. The
property is actually set to the factory method you originally provided (in this case
). So the factory method is passed state that includes itself.
that is provided is a
. This is created by the
. It seems like nothing is done with this until the application pushes a request through the pipeline. The
will have issues in a web farm such as Azure so you may want to replace this anyway.
Therefore you can:
- Let your IoC framework generate the single instance
IDataProtectionProvider, and register that with Owin in
app.SetDataProtectionProvider(idp) - this makes sense as you will be setting up your IoC framework here as well, so you have access to the single instance at this point.
- Subtype the
ApplicationUserManager and provide a ctor which allows your IoC framework to inject an
IDataProtectionProvider (or provide a factory method to your IoC so this work is not done in the ctor but is still controlled by the IoC injector and lifetime scopes)
AppUserManager(AppUserStore store, IDataProtectionProvider dpp)
- Use the following code as the Owin factory method (Autofac specific, but you can substitute any other IoC container).
app.CreatePerOwinContext<AppUserManager>((o, context) => context.GetAutofacLifetimeScope().Resolve<AppUserManager>()); // returns the per-request AppUserManager from the IoC resolver
- Now you can apply the same technique to inject the
SmsService and any other services into the
ApplicationUserManager and no longer worry about the
- You can also use your IoC framework to inject an
IDataProtectionProvider anywhere you need a new
ApplicationUserManager, removing your dependency on the