I am using this sample project (https://github.com/imranbaloch/ASPNETIdentityWithOnion) as my application architecture, in this sample the core is completly decoplied from the i
Okay I have solved this by doing the following:
I know that making a dependency on the Microsoft.AspNet.Identity.Core sounds Odd, but we only need the interface IUser which is basically considered as Core Domain Model for your application too.
The Ultimate Idea here is to GET RID OF THE Microsoft.AspNet.Identity.EntityFramework completely.
Interested devs can +1 this, so I can upload a full working sample on GitHub.
I'm using this framework, no need to have a link in every entity To get the userID reference, i added a property UserIDBy in BaseEntity so every entity will inherit it.
public abstract class BaseEntity
{
public int Id { get; set; }
public string UserIDBy { get; set; }
}
Next, in the web project, there is already an extension method called GetUserId(this IIdentity identity)
in IdentityExtensions.cs
, so to stock the UserIDBy in every Create and Edit action result:
Create Action Result :
// POST: /Region/Create
[HttpPost]
public async Task<ActionResult> Create([Bind(Include = "RegionName")] Region region)
{
if (ModelState.IsValid)
{
// TODO: Add insert logic here
var id = User.Identity.GetUserId();
region.UserIDBy = id.ToString();
await _regionService.AddAsync(region);
return Json(new { success = true });
}
return PartialView("_Create", region);
}
Edit Action Result :
//// POST: /Region/Edit/5
[HttpPost]
[ValidateAntiForgeryToken]
public ActionResult Edit([Bind(Include = "id,RegionName")] Region region)
{
if (ModelState.IsValid)
{
var id = User.Identity.GetUserId();
region.UserIDBy = id.ToString();
_regionService.Update(region);
return Json(new { success = true });
}
return PartialView("_Edit", region);
}
Dont forget to import it :
using Myapp.Web.Extensions;
Just stumbled upon this, having the same problem.
The problem with the marked answer is that it still references Microsoft.AspNet, which makes it rough for future .NET Core-plans.
The main problem is really with the general attempt to build in an authentication feature in the core, which defeats the purpose.
Consider letting the built in functionality for web authentication and authorization remain in the web layer, and reference a Core user object (UserProfile?) that represents the Core needs. This would also simplify switching to another authentication method (AD).
Depending on your preference, you can then reference the Core.UserProfile from your AspNetUser to avoid multiple SQL-calls, or simply make sure to have a good cache policy on the Core.UserProfile operations.
This allows you to control your authentication methods separate from your Core model.