0

I am using Ninject in an MVC application with ASPNET Identity 2.

Log in, log out, updating password etc are all working fine. However if I update the user's name in the database, the ApplicationUserManager seems to be caching the user information.

This is the code to register the Identity services:

private void RegisterServices()
{
    kernel.Bind<IHttpModule>().To<HttpApplicationInitializationHttpModule>();

    var dbContext = kernel.Get<ApplicationDbContext>();
    kernel.Bind<IUserStore<ApplicationUser>>().To<UserStore<ApplicationUser>>().WithConstructorArgument("context", dbContext);

    kernel.Bind<IAuthenticationManager>().ToMethod(x => HttpContext.Current.GetOwinContext().Authentication);
}

I have posted a sample solution on GitHub. WebApplication1 works without DI, and WebApplication2 with Ninject shows the caching behaviour.

Any advice on using ASPNET identity with DI would be appreciated.

LJNielsenDk
  • 1,414
  • 1
  • 16
  • 32
Kevin Kuszyk
  • 1,958
  • 24
  • 37
  • Well, for starters you're doing dependency injection completely wrong. You're not doing dependency injection at all. You're doing service location, and you're bypassing all the standard DI integration points. – Erik Funkenbusch Mar 20 '15 at 16:23
  • Can you elaborate on that? The controllers all have constructor injection, and the services are registered in the composition root. I hook the Ninject kernel into to OWIN according to the Ninject [docs](https://github.com/ninject/Ninject.Web.Common/wiki/Setting-up-a-OWIN-WebApi-application). If you have an alternative pattern for using Ninject, OWIN and MVC can you post an example? – Kevin Kuszyk Mar 20 '15 at 16:36
  • And, more importantly, you're using Ninject incorrectly. You should simply be using the Ninject.MVC5 package, and registering your bindings in `App_Start\NinjectWebCommon.cs`, you would still add the UseNinjectMiddleware call in the owin startup, but configuration is handled by the NinjectWebCommon architecture. – Erik Funkenbusch Mar 20 '15 at 16:38
  • My understanding is that the `NinjectWebCommon.cs` just bootstraps the kernel which I why I removed it. The `Ninject.MVC5` package is there (it contains the contains the controller factory for MVC). If I switch back to `NinjectWebCommon.cs`, how to I register the identity services in the [Startup.Auth.cs](https://github.com/kevinkuszyk/aspnet-identity-cache/blob/master/src/WebApplication2/App_Start/Startup.Auth.cs#L21)? Also does the callback specified `app.CreatePerOwinContext()` not result in the kernel returning new instances on each http request? – Kevin Kuszyk Mar 20 '15 at 16:57
  • Thanks Erik. I tried switching back to `NinjectWebCommon.cs`, but I don't see how to wire up Ninject with OWIN and aspnet identity (see [here](https://github.com/kevinkuszyk/aspnet-identity-cache/blob/use-ninject-web-common-bootstrapper/src/WebApplication2/Startup.cs#L12) and [here](https://github.com/kevinkuszyk/aspnet-identity-cache/blob/use-ninject-web-common-bootstrapper/src/WebApplication2/App_Start/Startup.Auth.cs#L20-L22))? – Kevin Kuszyk Mar 23 '15 at 10:43
  • I don't think you should be using `CreatePerOwinContext` at all if you are using your own DI mechanism. At any rate, it seems pretty clear that for whatever reason `SecurityStampValidator.OnValidateIdentity` is not being called and that's why the name doesn't update. – Matthew Nov 22 '17 at 16:30

0 Answers0