I'm trying to get the DbContext from the current Owin context, so I can use a single context on my application, however, I'm getting a NullReferenceException.
I can access UserManager and RoleManager:
private ApplicationUserManager _userManager;
public ApplicationUserManager UserManager
{
get
{
return _userManager ?? HttpContext.GetOwinContext().GetUserManager<ApplicationUserManager>();
}
private set
{
_userManager = value;
}
}
They're configured how they came by default in the Identity sample project:
app.CreatePerOwinContext(ApplicationDbContext.Create);
app.CreatePerOwinContext<ApplicationUserManager>(ApplicationUserManager.Create);
app.CreatePerOwinContext<ApplicationRoleManager>(ApplicationRoleManager.Create);
app.CreatePerOwinContext<ApplicationSignInManager>(ApplicationSignInManager.Create);
But trying to get the context to use it directly:
ApplicationDbContext context = HttpContext.GetOwinContext().Get<ApplicationDbContext>();
It always returns null on my controller. How can I get the current DbContext from the Owin context?
EDIT:
I was creating a new context to use with my generic repository
public AdminController()
{
AppContext = new ApplicationDbContext();
this.repoProyects = new GenericRepository<Proyect>(AppContext);
}
But it was creating a problem with entities being referenced from multiple contexts, so I'm trying to get the current Owin context like this:
public AdminController()
{
this.AppContext = HttpContext.GetOwinContext().Get<ApplicationDbContext>();
this.repoProyects = new GenericRepository<Proyect>(AppContext);
}
HttpContext is always null from here, so I don't know how to get the context to pass it to my class.
I had the same issue using Identity Framework when I added some extra navigation properties to the ApplicationUser. If you set
appContext = HttpContext.Current.GetOwinContext().Get<ApplicationDbContext>();
in OnActionExecuting instead of in the constructor, then OWIN should be ready to return the DbContext that's in use at that point. OnActionExecuting kicks in before any action methods fire, so this should be early enough to be useful. Hope that helps.
I was missing the initialization of my entities in the Startup method ConfigureOauth...
app.CreatePerOwinContext<OwinAuthDbContext>(() => new OwinAuthDbContext());
Found the answer here: http://www.c-sharpcorner.com/UploadFile/ff2f08/token-based-authentication-using-Asp-Net-web-api-owin-and-i/
Related
I'm wanting to configure registrations in a Unity container being used by ASP.NET Web API 2 based on properties of a HTTP request. For example, a request to /api/database1/values should result in a Unity container configuration with an IDbContext configured for database1, while a request to /api/database4/values will get an IDbContext configured for database4.
I've gotten so far as using UnityHierarchicalDependencyResolver as the dependency resolver, so types registered with HierarchicalLifetimeManager last only for the lifetime of the request. This works well for getting types resolved per request. But how to get them registered per request using OWIN middleware is beyond me.
In my middleware, a call to System.Web.Http.GlobalConfiguration.Configuration.DependencyResolver.GetService(typeof(IUnityContainer)) gets an instance of IUnityContainer, but it's the same container for all requests, including any registrations from previous requests.
By encapsulating UnityHierarchicalDependencyResolver with my own implementation of IDependencyResolver I can see that IDependencyResolver.BeginScope isn't called until much later in the process. So the problem would seem to be that the child container isn't created until Web API wakes up, long after my middleware calls Next(..).
Is there a way I can get the scope of my dependency resolver to start sooner? Is there some other strategy that I'm missing. In case it makes any difference, I'm hosting in IIS, but favouring the OWIN middleware approach.
Update
This isn't an answer, and it's too big for a comment, but after struggling to solve this with Unity I decided to switch to Autofac and it all just fell into place.
The Autofac OWIN packages (Autofac.Mvc5.Owin, Autofac.Owin, Autofac.WebApi2.Owin) make it dead easy to use Autofac within the OWIN pipeline and ensure appropriate lifetime management in ASP.NET MVC and Web API. This was the missing link.
I couldn't find a way to reconfigure the container per-request, but it did at least make it possible to configure a factory per-request (so yes, #Haukinger and #alltej, you were right to push in that direction.
So I register a factory like:
builder.RegisterType<DataDependencyFactory>().InstancePerRequest();
And register the create method of that factory like:
builder
.Register(c => c.Resolve<DataDependencyFactory>().CreateDataDependency())
.As<IDataDependency>()
.InstancePerRequest();
Registering the factory this way is particularly useful, because downstream dependents don't need to be aware of the factory. I like this because my dependents don't need a factory, they need an instance. The container bends to the needs of my dependents, not the other way around :)
Then, in a piece of OWIN middleware, I resolve the factory, and set a property on it according to the properties of the request. Subsequent resolution of IDataDependency in an MVC or Web API controller, or anything else later in the OWIN pipeline, will get an instance configured according to the property on the factory.
Based on your api URL ("/api/database4/values"), I suggest that you create a filter attribute(e.g. DbIdFilter) so that you can reuse the filter attribute to other controller methods that follow similar url path/segment like this below:
[HttpGet]
[DbIdFilter]
[Route("{databaseId}/values")]
public IHttpActionResult GetValues()
{
return Ok();
}
[HttpGet]
[DbIdFilter]
[Route("{databaseId}/products")]
public IHttpActionResult GetProducts()
{
return Ok();
}
First, create the filter attribute:
public class DbIdFilterAttribute : ActionFilterAttribute
{
private readonly string _routeDataId;
private const string defaultRouteName = "databaseId";
public DbIdFilterAttribute():this(defaultRouteName)
{}
public DbIdFilterAttribute(string routeDataId)
{
_routeDataId = routeDataId;
}
public override void OnActionExecuting(HttpActionContext actionContext)
{
var routeData = actionContext.Request.GetRouteData();
var dbId = routeData.Values[_routeDataId] as string;
//here we create the db instance at the filter level.
DbInstanceFactory.RegisterDbInstance(dbId);
}
}
Next, create an instance factory that will register/resolve the db instance during runtime:
public class DbInstanceFactory : IDbInstanceFactory
{
public static IDbInstance RegisterDbInstance(string databaseId)
{
var factory = UnityConfig.GetConfiguredContainer().Resolve<IDbInstanceFactory>();
return factory.CreateInstance(databaseId);
}
public IDbInstance CreateInstance(string databaseId)
{
var container = UnityConfig.GetConfiguredContainer();
//container.RegisterType<IDbInstance, DbInstance>();
container.RegisterType<IDbInstance, DbInstance>(new InjectionConstructor(databaseId));
var dbInstance = container.Resolve<IDbInstance>();
return dbInstance;
}
public IDbInstance GetInstance()
{
var container = UnityConfig.GetConfiguredContainer();
var dbInstance = container.Resolve<IDbInstance>();
return dbInstance;
}
}
public interface IDbInstanceFactory
{
IDbInstance CreateInstance(string databaseId);
IDbInstance GetInstance();
}
Register this factory class in UnityConfig.cs (or wherever you currently register the types):
container.RegisterType<IDbInstanceFactory, DbInstanceFactory>
(new ContainerControlledLifetimeManager());
It's registered ContainerControlledLifetimeManager since this factory does not have to be a per request.
So just a basic DbInstance class below(for clarity) that takes a parameter in the constructor (this parameter can be your connection string or a named connection):
public class DbInstance : IDbInstance
{
public string DbId { get; }
public DbInstance(string databaseId)
{
DbId = databaseId;
}
}
public interface IDbInstance
{
string DbId { get; }
}
In controller class, you can use it like this:
....
private IDbInstanceFactory _dbFactory;
public MyController(IDbInstanceFactory dbFactory)
{
_dbFactory = dbFactory;
}
// Alternate, if you want to use property injection instead of constructor injection
//[Dependency]
//public IDbInstanceFactory DbFactory { get; set; }
[HttpGet]
[DbIdFilter]
[Route("{databaseId}/test")]
public IHttpActionResult Test()
{
var db = _dbFactory.GetInstance();
return Ok(db.DbId);
}
...
I've got an app in asp.net core using the built-in DI framework. I'd like to add a per-request (i.e. transient) service to the provider, but I'd like to actually make use of the request in its construction.
services.AddTransient<IMyService>(provider => { ... });
That's the closest overload I can find, but the provider object doesn't have anything about the current request. Is there a way to achieve what I'm trying to do, without upgrading to a more robust DI framework?
As posted in the comments, you can inject the IHttpContextAccessor into your services and access it, if the HttpContext is the only thing you need.
public class MyService : IMyService
{
private readonly HttpContext context;
public MyService(IHttpContextAccessor httpContextAccessor)
{
if(IHttpContextAccessor==null)
throw new ArgumentNullException(nameof(httpContextAccessor));
context = httpContextAccessor.HttpContext;
}
}
However, if you need something that's only available in the controller or outside of HttpContext, you can create a factory and pass the parameters to the factory
public class MyServiceFactory : IMyServiceFactory
{
// injecting the HttpContext for request wide service resolution
public MyServiceFactory(IHttpContextAccessor httpContextAccessor) { ... }
public IMyService Create(IDependency1 dep1, IDependency2 dep 2, string someRuntimeConfig)
{
IServiceProvider provider = this.context.RequestServices;
var myService = new MyService(provider.GetService<ISomeRepository>(), dep1, dep2, someRuntimeConfig);
return myService;
}
}
and then inject the IMyServiceFactory to your classes where you'd need IMyService.
I am trying to run cleanup jobs from my azure Webjob for my mvc application. I can do standard database updates no problem but am unable to cleanup the aspnetuser accounts as I cannot get an ApplicationUser context as no startup class for Owin.
Anyone got any ideas on how this can be done or some dummy code? My google searches have come up blank thus far.
Thanks.
I am running ASP.net MVC 5 with VS 2015
Actually even if the ApplicationUserManager requires an OwinContext, you can get rid of the OwinContext.
The OwinContext is only useful for accessing the ApplicationDbConbtext that is bound to the OWinContext.
So I refactored the Create factory methods of ApplicationUserManager in order to be able to manage the users, at startup (or in a WebJob), without any OwinContext :
public static ApplicationUserManager Create(
IdentityFactoryOptions<ApplicationUserManager> options,
IOwinContext context)
{
ApplicationDbContext dbContext = context.Get<ApplicationDbContext>();
return Create(options, dbContext);
}
internal static ApplicationUserManager Create(IdentityFactoryOptions<ApplicationUserManager> options, Applicatio
{
// Create ApplicationUserManager myself instead of finding it on OwinContext
var manager = new ApplicationUserManager(new UserStore<ApplicationUser>(context));
// old code already generated by VS wizard
}
Then I use the ApplicationUserManager :
using (ApplicationDbContext applicationDbContext = new ApplicationDbContext())
{
var options = new IdentityFactoryOptions<ApplicationUserManager>
{
//DataProtectionProvider = app.GetDataProtectionProvider(),
};
ApplicationUserManager userManager = ApplicationUserManager.Create(options, applicationDbContext);
// ApplicationRoleManager has been changed the same way to be usable without OwinContext
ApplicationRoleManager appRoleManager = ApplicationRoleManager.Create(applicationDbContext);
// ... Code using ApplicationUserManager and ApplicationRoleManager
ApplicationUser appUser = userManager.FindByEmailAsync(email).Result;
// ...
IdentityResult result = userManager.CreateAsync(appUser, password).Result;
}
}
Hope it helps
I'm trying to create a custom authorization-attribute for my WebApi project.
In this attribute I would like to inject an IAuthModule object. I have no clue how I could implement this. I've found some solutions on the web but I have not been successful with any of them.
This is what I have so far:
public void Configuration(IAppBuilder app)
{
// WebApi config
HttpConfiguration config = new HttpConfiguration();
// SimpleInjector
var container = new SimpleInjector.Container();
container.Register<IAuthModule, CoreAuthModule>();
container.RegisterWebApiFilterProvider(config);
container.RegisterWebApiControllers(config);
container.Verify();
config.DependencyResolver = new SimpleInjectorWebApiDependencyResolver(container);
// Setup Oauth
ConfigureOAuth(app, container.GetInstance<IAuthModule>());
WebApiConfig.Register(config);
app.UseCors(Microsoft.Owin.Cors.CorsOptions.AllowAll);
app.UseWebApi(config);
}
and the attribute:
public class CustomAuthorizationAttribute : AuthorizeAttribute
{
// how can I inject something here?
public IAuthModule AuthModule { get; set; }
protected override bool IsAuthorized(HttpActionContext actionContext)
{
return false;
}
}
The Simple Injector Web API integration guide goes into more details about this in the Injecting dependencies into Web API filter attributes section. What it basically describes is that you need to do two things:
Use the RegisterWebApiFilterProvider extension method to allow Simple Injector to build-up Web API attributes.
Register a custom IPropertySelectionBehavior to make sure Simple Injector will inject dependencies into your attribute's properties.
So this basically comes down to adding the following registration:
var container = new Container();
container.Options.PropertySelectionBehavior = new ImportPropertySelectionBehavior();
container.RegisterWebApiFilterProvider(GlobalConfiguration.Configuration);
Where the ImportPropertySelectionBehavior is implemented as follows:
using System;
using System.ComponentModel.Composition;
using System.Linq;
using System.Reflection;
using SimpleInjector.Advanced;
class ImportPropertySelectionBehavior : IPropertySelectionBehavior {
public bool SelectProperty(Type type, PropertyInfo prop) {
return prop.GetCustomAttributes(typeof(ImportAttribute)).Any();
}
}
This custom IPropertySelectionBehavior enables explicit property injection where properties are marked with the System.ComponentModel.Composition.ImportAttribute attribute. Any property that is marked with this attribute will get injected.
Do note that dependency injection in attributes is sub optimal as described here and here.
When I create default SPA template progect VS2013 creates MeController. Calling Get I have a user information. But when I create almost the same Controller, for example UserController, and copy-paste all from Me to User I do not have necessary info about user on breakpoint in the method:
// GET api/Me
public GetViewModel Get()
{
var user = UserManager.FindById(User.Identity.GetUserId());
return new GetViewModel() { Hometown = user.Hometown };
}
I don't uderstand this magic! I also do not see a caller of constractor and sender of userManager. Where is it?
public MeController(ApplicationUserManager userManager)
{
UserManager = userManager;
}
There is a default constructor in the MeController which gets called by default. In this case the UserManager, is got from the Owin contect as below
public ApplicationUserManager UserManager
{
get
{
return _userManager ?? HttpContext.Current.GetOwinContext().GetUserManager<ApplicationUserManager>();
}
private set
{
_userManager = value;
}
}
Even if you copy this over to a new class like UserController, this should happen. Are you using any DI library like StrucuteMap/Unity etc? Certain DI controllers choose the 'greediest' constructor(the one with the maximum arguments). You could override that by using appropriate methods for that DI library(like this if you are using StructureMap)
In case you would want to use your own UserManager you could use your own implementation of UserManager and have it used. But if you are planning to stick with the default, this is already added in Startup.Auth.cs into the Owin pipeline.