We Keep Coding

C# >NET 7 Trying to resolve services (with a Singleton) prior to Service Provider being built

I'm using .NET 7 in a WebApplication with OAuth extensions.
The (GitHub) AuthenticationBuilder is added in the section of code before the application is built and the DI service provider is created.
However I need to work with a DI chain for UnitofWork/Repo/etc. Prior to the container being built. Based on some reading I decided to instantiate a premature copy of the container in my anonymous method for the oAuth event.
Once I did that the UI prompted me with a warning that a second container was being built and I get that totally kills the concept of a Singleton and probably isn't a really good idea.
Are there any suggestions on how to handle working with the DB from within the oAuth.OnCreatingTicket event? Or do I just need to pass configuration and manually instantiate all of the classes myself?
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddRazorPages();
builder.Services.AddServerSideBlazor();
builder.Services.AddTransient<IUnitOfWork,UnitOfWork>();
builder.Services.AddSingleton<IDocumentStore>(s =>
DocumentStoreFactory.CreateStore(
builder.Configuration["Server"],
builder.Configuration["Database"]));
builder.Services.AddAuthentication(...)
.AddCookie(...)
.AddGitHub(o =>
{
o.ClientId = builder.Configuration["GitHub:ClientID"]!;
o.ClientSecret = builder.Configuration["GitHub:ClientSecret"]!;
o.Events = new OAuthEvents
{
OnCreatingTicket = async context =>
{
//Building a temporary service provider so UnitOfWork/Service/DocumentStore DI chain can be fullfilled
var sp = builder.Services.BuildServiceProvider();
await OauthPersistUser.HandleGitHubOauthTicket(context, sp.GetService(typeof(ILogger<>)), sp.GetService<IUnitOfWork>());
}
};
});
var app = builder.Build();
//app Service provider Container is built and ready

Several hours of playing around later I realized that the context passed by the oAuth provider has access to the service provider via HttpContext.RequestServices.
so I can reduce my parameters to just the content, then grab the UnitOfWork object by:
public static async Task HandleGitHubOauthTicket(OAuthCreatingTicketContext context)
{
var uow = context.HttpContext.RequestServices.GetService<IUnitOfWork>();
var log = context.HttpContext.RequestServices.GetService<ILogger<OauthPersistUser>>();
...
}

StructureMap DbContext with identity

So i have recently started using structure map. I have a web api using identity. My goal is to have a dbcontext per request. Currently i am having context issues, the context injected through structure map is different to the one being used by the user manager. I have looked around and cant find a solution even though im sure its pretty obvious.
So to start with i have my structuremap setup.
public class DefaultRegistry : Registry {
#region Constructors and Destructors
public DefaultRegistry() {
Scan(
scan => {
scan.TheCallingAssembly();
scan.AddAllTypesOf<IImporterService>().NameBy(type => type.Name);
scan.WithDefaultConventions();
});
For<IHttpContextBaseWrapper>().Use<HttpContextBaseWrapper>();
For<ApplicationDbContext>().Use(() => new ApplicationDbContext());
For<HttpContextBase>().Use(() => new HttpContextWrapper(HttpContext.Current));
}
#endregion
}
I do not need to inject the user manager for the moment as its accessed through the httpcontext in a base service, i know this will probably have to change for unit testing in the future.
Next we have the startup auth.
private void ConfigureOAuthTokenGeneration(IAppBuilder app)
{
app.CreatePerOwinContext(ApplicationDbContext.Create);
app.CreatePerOwinContext<ApplicationUserManager>(ApplicationUserManager.Create);
app.CreatePerOwinContext<ApplicationRoleManager>(ApplicationRoleManager.Create);
//Token Auth
var OAuthOptions = new OAuthAuthorizationServerOptions
{
TokenEndpointPath = new PathString("/api/account/login"),
Provider = new ApplicationOAuthProvider("self"),
AuthorizeEndpointPath = new PathString("/api/AccountApi/ExternalLogin"),
AccessTokenExpireTimeSpan = TimeSpan.FromDays(121),
RefreshTokenProvider = new ApplicationRefreshTokenProvider(),
//#if DEBUG
AllowInsecureHttp = true,
//#endif
};
// Enable the application to use bearer tokens to authenticate users
app.UseOAuthBearerTokens(OAuthOptions);
}
I have cut down the code but i have the typical structure of service and repository layers. All inject using structuremap, the service and repositories have the correct context, the only on that does not is the user manager. I know its the line below causing the issue:
app.CreatePerOwinContext(ApplicationDbContext.Create);
However like i said i am still getting used to structure map, i previously used unity and would just resolve the instance i need from the current container. Any help or guidance is much appreciated.

Your problem with all these lines:
app.CreatePerOwinContext(ApplicationDbContext.Create);
app.CreatePerOwinContext<ApplicationUserManager>(ApplicationUserManager.Create);
app.CreatePerOwinContext<ApplicationRoleManager>(ApplicationRoleManager.Create);
First you tell a middleware to manage creation of your DbContext. Then you tell middleware to manage creation of your ApplicationUserManager and ApplicationUserManager.Create takes an instance of ApplicationDbContext managed by that middleware, not by your DI container. Same happens for your ApplicationRoleManager. At the end you have 2 ways of producing ApplicationDbContext per request - one through your DI container, another through middleware.
If you want to have only single instance of ApplicationDbContext you need to get rid of the second way of creation its' instance: ApplicationDbContext.Create. This will resolve your problem.
However your middleware still needs access to your ApplicationUserManager. So instead of all these:
app.CreatePerOwinContext(ApplicationDbContext.Create);
app.CreatePerOwinContext<ApplicationUserManager>(ApplicationUserManager.Create);
app.CreatePerOwinContext<ApplicationRoleManager>(ApplicationRoleManager.Create);
you need to use app.CreatePerOwinContext(() => DependencyResolver.Current.GetService<ApplicationUserManager>());
And get rid of all other ways of creating these instances other than injection from your DI container.
Further info in my old blog post - scroll to "Clean up" part for the details about middleware registration.

Autofac scope issues

I am trying to get autofac to work, but having issues with my unitofwork / user manager classes.
Initially I set my unit of work up as a per request instance like this:
builder.RegisterType<UnitOfWork<DatabaseContext>>().As<IUnitOfWork>().InstancePerRequest();
But in my StartupConfig.cs I was trying to set up oAuth like this:
private static OAuthAuthorizationServerOptions ConfigureOAuthTokenGeneration(IAppBuilder app, ILifetimeScope scope)
{
var t = scope.Resolve<IPasswordHasher>();
// Get our providers
var authProvider = scope.Resolve<OAuthProvider>();
var refreshTokenProvider = scope.Resolve<IAuthenticationTokenProvider>();
// Create our OAuth options
return new OAuthAuthorizationServerOptions()
{
AllowInsecureHttp = true, // TODO: Remove this line
TokenEndpointPath = new PathString("/oauth/access_token"),
AccessTokenExpireTimeSpan = TimeSpan.FromDays(1),
AccessTokenFormat = new Business.Authentication.JwtFormat("http://localhost:62668"),
Provider = authProvider,
RefreshTokenProvider = refreshTokenProvider
};
}
The scope is obtained by this:
var scope = config.DependencyResolver.GetRootLifetimeScope();
Because of this, I could not use InstancePerRequest for the UnitOfWork, instead I changed it to this:
builder.RegisterType<UnitOfWork<DatabaseContext>>().As<IUnitOfWork>().InstancePerLifetimeScope();
Now the application actually runs, but I get a new error with my UserProvider, it is instantiated like this:
builder.RegisterType<UserProvider>().As<IUserProvider>().InstancePerRequest();
But if I run that, I get this error:
No scope with a tag matching 'AutofacWebRequest' is visible from the scope in which the instance was requested.
If you see this during execution of a web application, it generally indicates that a component registered as per-HTTP request is being requested by a SingleInstance() component (or a similar scenario). Under the web integration always request dependencies from the dependency resolver or the request lifetime scope, never from the container itself.
This is actually being invoked by the line:
var authProvider = scope.Resolve<OAuthProvider>();
which is in my StartupConfig.cs. The OAuthProvider does need the UserProvider, the signature looks like this:
public OAuthProvider(IAdvancedEncryptionStandardProvider helper, IUserProvider userProvider)
{
this._helper = helper;
this._userProvider = userProvider;
}
So because this is not in the "request", I changed the UserProvider to be resolved like this:
builder.RegisterType<UserProvider>().As<IUserProvider>().InstancePerLifetimeScope();
which matches the UnitOfWork now, the project will load. But if I have an interface that tries to do 2 things (get the current user and list all users) it creates 2 requests, both creating a new instance of the UserController:
public UsersController(IUserProvider provider)
{
this._provider = provider;
}
which in turn tries to create 2 instances of the UserProvider. This throws an error:
The context cannot be used while the model is being created. This exception may be thrown if the context is used inside the OnModelCreating method or if the same context instance is accessed by multiple threads concurrently. Note that instance members of DbContext and related classes are not guaranteed to be thread safe.
So, I guess I need to know how I can resolve this.
It's like I need 2 scopes, one for the start of the application and then another for everything else.
Can anyone help me with this?

The issue
Since, at the time of the OWIN middleware registration, you need to provide an instance of OAuthAuthorizationServerOptions, there's no way to resolve the Provider and RefreshTokenProvider properties per HTTP request.
What we need is a way to create the OAuthAuthorizationServerOptions per HTTP request. By extension, the same concept would apply to the OAuthAuthorizationServerMiddleware.
A possible solution
That's exactly what AutofacMiddleware<T> does; It wraps an OWIN middleware by resolving it during the HTTP request from the lifetime scope stored in the OWIN context, then executes it. This means that we can now instantiate a new OAuthAuthorizationServerMiddleware for each HTTP request.
As explained in the documentation, when you use app.UseAutofacMiddleware(container) in your Startup class, Autofac does 2 things:
it hooks itself in the OWIN pipeline to create a nested lifetime scope for each HTTP request
it wraps all the OwinMiddleware services registered in the container with AutofacMiddleware and adds them to the OWIN pipeline
The solution is then to register OAuthAuthorizationServerMiddleware and all its dependencies in the Autofac container, and it will be automatically resolved for each request and executed.
OAuthAuthorizationServerMiddleware has 3 dependencies:
The next OWIN middleware in the pipeline, which AutofacMiddleware takes care of as it provides it to the Resolve method - TypedParameter.From(this.Next)
An instance of IAppBuilder
The OAuthAuthorizationServerOptions instance
We have to register the last two dependencies plus the middleware itself in the container. Let's have a look at what this could look like:
Disclaimer: I didn't try the code below
// Here go all the registrations associated with the `Provider`
// and `RefreshTokenProvider` properties with the appropriate lifetimes
builder
.RegisterInstance(app)
.As<IAppBuilder>();
builder
.Register(x => new OAuthAuthorizationServerOptions
{
AllowInsecureHttp = true, // TODO: Remove this line
TokenEndpointPath = new PathString("/oauth/access_token"),
AccessTokenExpireTimeSpan = TimeSpan.FromDays(1),
AccessTokenFormat = new Business.Authentication.JwtFormat("http://localhost:62668"),
Provider = x.Resolve<OAuthProvider>(),
RefreshTokenProvider = x.Resolve<IAuthenticationTokenProvider>()
})
.AsSelf()
// InstancePerDependency is same as InstancePerLifetimeScope
// in this case since the middleware will get resolved exactly one
// time per HTTP request anyway
.InstancePerDependency();
builder.RegisterType<OAuthAuthorizationServerMiddleware>();
Controlling the middleware order
While this could work, it's possible that it doesn't suit your needs since the OAuth middleware will be registered in the OWIN pipeline where you call app.UseAutofacMiddleware(container).
If you want more control over middleware order, you can separate the Autofac lifetime scope creation from the middleware registration in the OWIN pipeline:
Disclaimer: I didn't try the code below
// creates the per HTTP request lifetime scope
app.UseAutofacLifetimeScopeInjector(container);
// "usual" OWIN middlewares registrations
app.UseFoo();
// now use one from the container
app.UseMiddlewareFromContainer<OAuthAuthorizationServerMiddleware>();
// other "usual" OWIN middlewares registrations
app.UseBar();

Dependency injecting UserStore in OWIN startup using Ninject OWIN middleware

I am having problems creating a custom UserStore using dependency injection when creating an ApplicationUserManager using the OWIN request pipeline.
Background
I am trying to migrate the user functionality in our web application from using the SimpleMembership to the new ASP.NET Identity. When starting a new MVC 5 project, the default implementation of the single page application uses ASP.Identity, using Entity Framework to implement the UserStore functionality.
In my case, we are already using NHibernate as the ORM, and using ninject to implement the unit of work pattern so that we had one NHibernate session per request, and I wanted to make the ASP.Identity work with our existing framework.
To this end, I created a custom UserStore, which could be created by injecting the relevant repositories/nhibernate session, etc. This could then be injected into the Controller's constructor using Ninject, rather than using the default implementation's GetOwinContext functionality.
In order to do this, I had commented out the following line in the ConfigureAuth(IAppBuilder app) method of the Startup, which by default creates the UserManager class:
// app.CreatePerOwinContext<ApplicationUserManager>(ApplicationUserManager.Create);
Instead, I used the NinjectWebCommon created when installing the Ninject.Web.Common.Webhost nuget package to create the relevant bindings.
This implementation worked fine with some of the UserManager operations, but with some operations, such as ResetPasswordAsync, it fails because the default ApplicationUserManager implementation is not called, and so the UserTokenProvider in the UserManager class is never set:
public static ApplicationUserManager Create(IdentityFactoryOptions<ApplicationUserManager> options, IOwinContext context)
{
var manager = new ApplicationUserManager(new UserStore<ApplicationUser>(context.Get<ApplicationDbContext>()));
// Configure validation logic for usernames
manager.UserValidator = new UserValidator<ApplicationUser>(manager)
{
AllowOnlyAlphanumericUserNames = false,
RequireUniqueEmail = true
};
// Configure validation logic for passwords
manager.PasswordValidator = new PasswordValidator
{
RequiredLength = 6,
RequireNonLetterOrDigit = true,
RequireDigit = true,
RequireLowercase = true,
RequireUppercase = true,
};
// Register two factor authentication providers. This application uses Phone and Emails as a step of receiving a code for verifying the user
// You can write your own provider and plug in here.
manager.RegisterTwoFactorProvider("PhoneCode", new PhoneNumberTokenProvider<ApplicationUser>
{
MessageFormat = "Your security code is: {0}"
});
manager.RegisterTwoFactorProvider("EmailCode", new EmailTokenProvider<ApplicationUser>
{
Subject = "Security Code",
BodyFormat = "Your security code is: {0}"
});
manager.EmailService = new EmailService();
manager.SmsService = new SmsService();
var dataProtectionProvider = options.DataProtectionProvider;
if (dataProtectionProvider != null)
{
manager.UserTokenProvider = new DataProtectorTokenProvider<ApplicationUser>(dataProtectionProvider.Create("ASP.NET Identity"));
}
return manager;
}
Therefore, the UserTokenProvider is not set.
Problem
I want to use the OWIN pipeline, because Visual Studio's default implementation of the ApplicationUserManager class injects the IDataProtectionProvider in its Create callback method. However, I also want to create my UserStore using dependency Injection, and I do not know how to create a UserStore within this method using dependency injection.
public static ApplicationUserManager Create(IdentityFactoryOptions<ApplicationUserManager> options, IOwinContext context)
{
// WANT TO CREATE THE USER STORE USING NINJECT DEPENDENCY INJECTION HERE
// var userStore = ...
var manager = new ApplicationUserManager(userStore);
}
I have tried to get around this limitation by using the Ninject.Web.Common.OwinHost nuget package and creating the kernel within the Startup class.
public void ConfigureAuth(IAppBuilder app)
{
// Setup
app.UseNinjectMiddleware(CreateKernel);
}
However, the Ninject.Web.Common.OwinHost does not expose its Kernel, so I am unable to use service location pattern to inject the values into my custom UserStore in the Create callback.
I have also tried to create a singleton Kernel, and register this using app.CreatePerOwinContext(CreateKernel) with the relevant delegate, so I could later access the Kernel, but when I call context.Get() it just returns null.
Question
How can I register a callback function with CreatePerOwinContext to create a custom UserManager which uses a custom UserStore, and then use Ninject to create the custom UserStore using dependency injection in the Create callback, so that I also have access to the IdentityFactoryOptions which Owin uses to inject the user token provider?

For info:
It is possible to register the kernel as a singleton so that the same kernel can be used by the ninject middleware and also registered within the owin context.
public static StandardKernel CreateKernel()
{
if (_kernel == null)
{
_kernel = new StandardKernel();
_kernel.Bind<IHttpModule>().To<HttpApplicationInitializationHttpModule>();
_kernel.Load(Assembly.GetExecutingAssembly(), Assembly.Load("Super.CompositionRoot"));
}
return _kernel;
}
The callback function app.CreatePerOwinContext(ApplicationUserManager.Create), will call the ApplicationUserManager.Create rather than register it to be called at a later point during the setup. Therefore, the CreateKernel function needs to be registered before the ApplicationUserManager's Create callback or you will get a null reference exception if you try to get the kernel from the owin context within that method.
public void ConfigureAuth(IAppBuilder app)
{
app.CreatePerOwinContext(CreateKernel);
app.UseNinjectMiddleware(CreateKernel);
app.CreatePerOwinContext<ApplicationUserManager>(ApplicationUserManager.Create);
}
This will allow you to access the kernel to create a custom UserStore within the ApplicationUserManager's Create callback:
public static ApplicationUserManager Create(IdentityFactoryOptions<ApplicationUserManager> options, IOwinContext context)
{
var kernel = context.Get<StandardKernel>();
var userStore = kernel.Get<IUserStore<User, int>>();
var manager = new ApplicationUserManager(userStore);
//...
}
I know that in general dependency injection should be favoured over service location, but in this context I couldn't see a way around it - unless anybody has any better suggestions?
This will allow you to use Ninject to implement the unit of work patter leveraging Ninject's InRequestScope().OnDeactivation functionality. I'm aware that the UserManager class has a per request lifetime, but didn't know the most the most appropriate way to commit any outstanding transactions on request finish.

Note This was for WebApi (using System.Web.Http)
Okay so I kind of cheated by using stuff from System.Web which is the namespace we're suppose to be weening ourselves off of, but while its still used, why not.
Firstly, I use some helpers from this SO question:
Configuring Ninject with Asp.Net MVC & Web Api
Within which, the resolver is registered with System.Web's global configuration. Thus, I just go grab it when I need it:
public static ApplicationUserManager Create(IdentityFactoryOptions<ApplicationUserManager> options, IOwinContext context)
{
var repository = System.Web.Http.GlobalConfiguration.Configuration.DependencyResolver
.GetService(typeof(Data.Repositories.UserRepository)) as Data.Repositories.UserRepository;
var manager = new ApplicationUserManager(repository);
...
Note: I use the term Repository over Store since it matches the well-known pattern, more understandable to most people.
And the Startup.Auth looks like this, I basically move the Ninject init into here so its done in time:
public void ConfigureAuth(IAppBuilder app)
{
// Dependency Injection
Evoq.AppName.Configuration.Ninject.NinjectHttpContainer.RegisterAssembly();
// Configure the db context and user manager to use a single instance per request
app.CreatePerOwinContext<ApplicationUserManager>(ApplicationUserManager.Create);
...
I did also use a method similar to the OP where I 'attached' a callback to get the IKernel but while this keeps it all OWINy, the problem with this approach is that you have to call owinContextThing.Get<IKernel>() which means referencing Ninject deeper in my code.
There were ways around it, but it started getting more complex than my solution above.
Additional Note
This is the Identity Framework code that registers the callback. Note the call to app.GetDataProtectionProvider which is essentially the thing we originally needed to make a UserTokenProvider.
/// <summary>
/// Registers a callback that will be invoked to create an instance of type T that will be stored in the OwinContext which can fetched via context.Get
/// </summary>
/// <typeparam name="T"></typeparam>
/// <param name="app"></param>
/// <param name="createCallback"></param>
/// <returns></returns>
public static IAppBuilder CreatePerOwinContext<T>(this IAppBuilder app, Func<IdentityFactoryOptions<T>, IOwinContext, T> createCallback) where T : class,IDisposable {
if (app == null) {
throw new ArgumentNullException("app");
}
if (createCallback == null) {
throw new ArgumentNullException("createCallback");
}
app.Use(typeof(IdentityFactoryMiddleware<T, IdentityFactoryOptions<T>>),
new IdentityFactoryOptions<T>() {
DataProtectionProvider = app.GetDataProtectionProvider(),
Provider = new IdentityFactoryProvider<T>() {
OnCreate = createCallback
}
});
return app;
}
I've looked and looked and reflected the libs and cannot find that method! If I knew how that worked, potentially we could find another way to create a token, i.e. wouldn't need the options instance.

Registering component multiple times

I need to instantiate a concrete class based on data in the HttpRequestMessage. I'm using the following code to configure my Web API service:
var builder = new ContainerBuilder();
builder.RegisterHttpRequestMessage(GlobalConfiguration.Configuration);
builder.RegisterWebApiFilterProvider(GlobalConfiguration.Configuration);
builder.RegisterApiControllers(typeof(WebApiApplication).Assembly);
// ... snip ....
container.Register(x =>
{
if (x.IsRegistered<HttpRequestMessage>())
{
var httpRequestMethod = x.Resolve<HttpRequestMessage>();
var tokenHelper = x.Resolve<ITokenHelper>();
var token = tokenHelper.GetToken(httpRequestMethod);
var connectionContext = x.Resolve<ISqlServerConnectionContext>();
connectionContext.Token = token;
return token ?? new NullMinimalSecurityToken();
}
return new NullMinimalSecurityToken();
});
// ... snip ...
var container = builder.Build();
GlobalConfiguration.Configuration.DependencyResolver = new AutofacWebApiDependencyResolver(container);
return container;
Unfortunately, the delegate is called multiple times, with the last one not having a registered HttpRequestMessage, meaning I get back a NullMinimalSecurityToken, which causes my security attribute to reject the request (as it should). However, when I'm stepping through, I can see that IMinimalSecurityToken is already registered (i.e. x.IsRegistered<IminimalSecurityToken() returns true). If I try to return the resolved IMinimalSecurityToken if it's already registered, I get a circular reference error.
In addition, attempting to use InstancePerApiRequest while registering results in a "No scope with a Tag matching 'AutofacWebRequest' is visible from the scope in which the instance was requested" error.
I'm not entirely clear on why this delegate gets called multiple times, nor why in one of the calls it doesn't have an HttpRequestMethod.
What am I doing wrong that is causing multiple executions of the delegate (assuming that is in fact a problem), and how do I fix this so that I can properly inject a valid IMinimalSecurityToken into my SecurityAttribute (via property injection, but that part is working, it's just that what gets injected isn't valid).

So this problem turned out to be caused by trying to "convert" the Ninject code over to Autofac.
I was able to use Autofac's capabilities to inject Web API filters to wire up the security attribute, which allowed me to inject the required IMinimalSecurityToken in the constructor, rather than the rather hacky way I had to work around Ninject's limitations in that area:
container.RegisterType<SecurityTokenAuthorization>().As<IAutofacAuthorizationFilter>().InstancePerApiRequest();
container.RegisterType<SecurityTokenAuthorization>().AsWebApiAuthorizationFilterFor<DocumentController>().InstancePerApiRequest();
I've got other issues now, but they are sufficiently different that they'll need a new question assuming I'm not able to solve them.