Different user types in ASP.Net Identity 2.0 - asp.net

So, I'm trying to implement different kind of users on my application, first, let's say there's only one kind of user:
public class ApplicationUser : IdentityUser
{
// Other Properties
public int TeacherID { get; set; }
[ForeignKey("TeacherID ")]
public virtual Teacher Teacher { get; set; }
}
public class Teacher
{
[Key]
public int TeacherID { get; set; }
public int UserID { get; set; }
// Other properties
[ForeignKey("UserID")]
public virtual ApplicationUser User { get; set; }
}
There's a one to one relationship between those 2 entities, but what if there's more than one type of user? I can't have that ForeignKey on the User entity, I think I'm going in the wrong direction.
I though about using roles for this, so there's an Admin, a Teacher, an Student, and different kind of roles for each one, but what happens if I want to store extra properties for each kind of role?
public class IdentityUserRole<TKey>
{
public IdentityUserRole();
// Resumen:
// RoleId for the role
public virtual TKey RoleId { get; set; }
//
// Resumen:
// UserId for the user that is in the role
public virtual TKey UserId { get; set; }
}
I mean, I can extend the class IdentityUserRole and add more properties, but how do I add properties for each kind of role?

It certainly makes sense to use roles for this purpose, but it does mean you could assign multiple roles. so a user could be a Teacher and a Student, but that can happen.
If you want to add extra properties to the role class, it's done in the same way as is done for user. Create your own version of Role like this:
public class ApplicationRole : IdentityRole
{
public string bool CanJuggle { get; set; }
}
And you need a RoleManager class to go with it:
public class ApplicationRoleManager : RoleManager<ApplicationRole>
{
public ApplicationRoleManager(IRoleStore<ApplicationRole> store)
: base(store)
{ }
//snip
}
And not forgetting your context needs to change:
public class YourContext : IdentityDbContext<ApplicationUser, ApplicationRole, string, IdentityUserLogin, IdentityUserRole, IdentityUserClaim>
{
//snip
}
Think that covers all the relevant parts.

Related

Entity Framework shows inconsistent behaviour when used with Asp.net Identity

I have 3 tables Violation,Comment and and auto generated AspNetUsers respectively.The relationship between them as follows.
I am using code-first approach and my models are as follows.Some properties are removed for brevity.
Violation Model
public class Violation
{
public Violation()
{
this.Comments = new HashSet<Comment>();
}
public int Id { get; set; }
public virtual ICollection<Comment> Comments { get; set; }
public virtual ApplicationUser CreatorUser { get; set; }
}
Comment Model
public class Comment
{
public int Id { get; set; }
[Required]
public string Content { get; set; }
[Required]
public DateTime PostedDateTime { get; set; }
public ApplicationUser ApplicationUser { get; set; }
public Violation Violation { get; set; }
}
ApplicationUser(AspNetUsers Table)
public class ApplicationUser : IdentityUser
{
public ApplicationUser()
{
this.Comments = new List<Comment>();
this.Violations = new List<Violation>();
}
public virtual List<Comment> Comments { get; set; }
public virtual List<Violation> Violations { get; set; }
}
The problem is that when I try to retrieve Comment's ApplicationUser navigation property , I see many of them pointing to a null property even database has proper record for each of them.
Shortly,EF doesn't retrieve database records properly.I stuck with it,can't find the reason.
In fact, it's not being lazy-loaded. You didn't add the virtual keyword to your Comment.ApplicationUser property, so Entity Framework cannot override it to add the lazy-loading logic. As a result, it's always going to be null unless you explicitly load it. Add the virtual keyword, and you'll be fine.
If you want the navigation properties populated you need to include them in the query:
var comments = context.Comments
.Include(c => c.Violation)
.Include(c => c.ApplicationUser)
.Where(x => x.Violation.Id == violationId);
https://msdn.microsoft.com/en-us/data/jj574232.aspx#eager

How can I create two types of users in MVC5?

I'm creating MVC5 app, and I'm already using ASP.NET Identity to create users. So, I already have the AspNetUsers table, and whenever user registers I get an entry there. I also have an Admin role, where I manually specify, which registered user is an admin. On the other hand, I also need to register Businesses, and much like normal Users, they will be able to log-in, register, and do some stuff. The point is that they will have both some similar and different fields with/from the normal users. For example, they will also have, e-mail address, password (which I want to be hashed like for normal users), e-mail confirmation, unique id etc. But they have different fields for more information, like their address, zip, country, category, etc. which normal users don't have. How can I achieve this in MVC?
Should I do something like the ApplicationUser class?
public class ApplicationUser : IdentityUser
I mean, should I inherit my Business model from the IdendityUser? If yes, how will my model know which of the fields from IdentityUser to use and which not?
Here is my current Business model:
public class Business
{
public int BusinessID { get; set; }
public string BusinessName { get; set; }
[ForeignKey("Category")]
public int CategoryID { get; set; }
public virtual Category Category { get; set; }
[ForeignKey("Subcategory")]
public int SubcategoryID { get; set; }
public virtual Subcategory Subcategory { get; set; }
public string BusinessAddress { get; set; }
public string BusinessZip { get; set; }
public string BusinessPhone { get; set; }
public string BusinessDescription { get; set; }
public string Facebook { get; set; }
public string Twitter { get; set; }
public byte[] ImageData { get; set; }
public string ImageMimeType { get; set; }
[Range(0.0, 5.0)]
public double BusinessRating { get; set; }
public virtual ICollection<Review> Reviews { get; set; }
}
So, apart from those fields, I want my table to include the stuff similar to AspNetUsers, like Email, EmailConfirmed, PasswordHash, SecurityStamp, etc.
EDIT:
Please note that some of my fields in the Business model are required. And also below you can find my ApplicationUser class.
public class ApplicationUser : IdentityUser
{
public string FirstName { get; set; }
public string LastName { get; set; }
public async Task<ClaimsIdentity> GenerateUserIdentityAsync(UserManager<ApplicationUser> manager)
{
// Note the authenticationType must match the one defined in CookieAuthenticationOptions.AuthenticationType
var userIdentity = await manager.CreateIdentityAsync(this, DefaultAuthenticationTypes.ApplicationCookie);
// Add custom user claims here
return userIdentity;
}
}
Use simple inheritance:
public class Business : ApplicationUser
{
...
}
You'll end up with a Discriminator column in your AspNetUsers table that will help Entity Framework identity which class it should instantiate for the row (Business or ApplicationUser). Then you can either just query as normal or if you only want one particular type or another, you can use OfType<T>:
var businessUsers = db.Users.OfType<Business>();
Note: By default, Entity Framework handles simple inheritance with a single table with a Discriminator column. For most cases this works just fine, but you must keep in mind that any property you add to subclasses of your base class, must be nullable. You cannot require something like a DateTime on Business to be required at the database-level, because then you could never save an ApplicationUser, which does not that property. However, this is only an issue at the database-level. You can still use view models to make a particular property on Business required from a front-end perspective.

Why do the ASP.NET Identity interfaces use strings for primary and foreign keys?

I'm looking at the interfaces on the new ASP.NET Identity classes and the database it creates using Entity Framework Code First. I'm using the Visual Studio 2013 RC.
At first glance the database schema looks reasonably normal:
But all the keys are NVARCHAR(128)
And for some crazy reason AspNetUserSecrets.Id is a PK that looks like it could point to more than one record in the AspNetUsers table. Does this mean multiple AspNetUsers will have to share the same password?
When I look at the Looking at the interfaces you're forced to implement, these are all strings...
public class User : IUser
{
public string Id { get; set; }
public string UserName { get; set; }
}
public class UserSecret : IUserSecret
{
public string UserName { get; set; }
public string Secret { get; set; }
}
public class UserRole : IUserRole
{
public string UserId { get; set; }
public string RoleId { get; set; }
}
public class UserClaim : IUserClaim
{
public string UserId { get; set; }
public string ClaimType { get; set; }
public string ClaimValue { get; set; }
}
public class UserManagement : IUserManagement
{
public string UserId { get; set; }
public bool DisableSignIn { get; set; }
public DateTime LastSignInTimeUtc { get; set; }
}
public class Tokens : IToken
{
public string Id { get; set; }
public string Value { get; set; }
public DateTime ValidUntilUtc { get; set; }
}
public class UserLogin : IUserLogin
{
public string UserId { get; set; }
public string LoginProvider { get; set; }
public string ProviderKey { get; set; }
}
public class Role : IRole
{
public string Id { get; set; }
public string Name { get; set; }
}
So I'm coming to terms with the fact that I may have to implement this using strings for PK and FK relationships.
But I'd really love to know WHY it's built like this...?
EDIT: Time has passed and there are now articles on how to extend the asp.net identity to use int (or guid) fields:
http://www.asp.net/identity/overview/extensibility/change-primary-key-for-users-in-aspnet-identity
The intent was to allow both arbitrary id types (i.e. int, guid, string), but also avoid having serialization/casting issues for the id property.
So you can define your keys however you like and just implement the interface method
public class MyUser : IUser {
public int Id { get; set; }
string IUser.Id { get { return Id.ToString(); } }
}
Adding to what Hao said:
The Identity runtime prefers strings for the user ID because we don’t want to be in the business of figuring out proper serialization of the user IDs (we use strings for claims as well for the same reason), e.g. all (or most) of the Identity interfaces refer to user ID as a string.
People that customize the persistence layer, e.g. the entity types, can choose whatever type they want for keys, but then they own providing us with a string representation of the keys.
By default we use the string representation of GUIDs for each new user, but that is just because it provides a very easy way for us to automatically generate unique IDs.
With ASP.NET Core, you have a very simple way to specify the data type you want for Identity's models.
First step, override identity classes from < string> to < data type you want> :
public class ApplicationUser : IdentityUser<Guid>
{
}
public class ApplicationRole : IdentityRole<Guid>
{
}
Declare your database context, using your classes and the data type you want :
public class ApplicationDbContext : IdentityDbContext<ApplicationUser, ApplicationRole, Guid>
{
public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options)
: base(options)
{
}
protected override void OnModelCreating(ModelBuilder builder)
{
base.OnModelCreating(builder);
// Customize the ASP.NET Identity model and override the defaults if needed.
// For example, you can rename the ASP.NET Identity table names and more.
// Add your customizations after calling base.OnModelCreating(builder);
}
}
And in your startup class, declare the identity service using your models and declare the data type you want for the primary keys :
services.AddIdentity<ApplicationUser, ApplicationRole>()
.AddEntityFrameworkStores<ApplicationDbContext, Guid>()
.AddDefaultTokenProviders();
In ASP.NET identity tables, primary keys will still be in NVARCHAR but in your application it's will be the data type you want.
You can check this in a controller :
[HttpGet]
public async Task<IActionResult> Test()
{
ApplicationUser user = await _userManager.GetUserAsync(HttpContext.User);
Guid userId = user.Id; // No cast from string, it's a Guid data type
throw new NotImplementedException();
}

EF code first - map child class property to base class table

I wonder if it's possible to map a child class property to base class table. Say I have two classes (shortened):
public abstract class User
{
[Key]
public int UserId { get; set; }
public string Username { get; set; }
// other properties...
}
and
public class Customer : User
{
public int ShopId { get; set; }
public virtual Shop Shop { get; set; }
// other properties...
}
I'm using TPT (table per type) inheritance (that means two tables - User and Customer). For some reasons I would like to have the ShopId property in the User table, but all other properties from Customer class in the Customer table. Is that even possible?
Having ShopId column in User table would allow us for example to create unique index on Username and ShopId (the application is multi-tenant so we don't want globally unique usernames, only shop-level unique usernames).
Is this what you're looking for?
UserBase.cs
public abstract class UserBase
{
public int UserId { get; set; }
public string Username { get; set; }
public int ShopId { get; set; }
public virtual Shop Shop { get; set; }
}
User.cs
public class User : UserBase
{
// user specific properties...
}
Customer.cs
public class Customer : UserBase
{
// customer specific properties...
}
UserDbContext.cs
public class UserDbContext : DbContext
{
...
protected override OnModelCreating(DbModelBuilder modelBuilder)
{
// if you want users and customers to be shop specific
modelBuilder.Entity<UserBase>.HasKey(x => new { x.UserId, x.ShopId });
// if you only want users to be shop specific uncomment below and remove above
//modelBuilder.Entity<User>.HasKey(x => new { x.UserId, x.ShopId });
}
}

Business Logic Architecture with Entity Framework

I`m using Entity Framework and I have entities like this:
public class User : IEntity
{
[Key]
[DatabaseGeneratedAttribute(DatabaseGeneratedOption.Identity)]
public int UserId { get; set; }
[Required]
public String Email { get; set; }
public virtual ICollection<Project> UserProjects { get; set; }
}
public class Project : IEntity
{
[Key]
public int ProjectId { get; set; }
public String Title { get; set; }
public String Description { get; set; }
[ForeignKey("UserOwner")]
public int UserOwnerId { get; set; }
public virtual User UserOwner { get; set; }
}
Also I use Repository pattern and Unit Of Work pattern.
For example I have method
CreateProject(String title, String description, String userOwnerEmail)
in Projects logic class which contains only Project Repository.
Also i have UserLogic class that allows me get user by his email.
How i can get user by his email in CreateProject method to designate him like a project owner.
The main aim is to create loose coupling method.
I think that this example is bad:
public void CreateNewProject(String projectName, String description,String usersEmail)
{
var usersLogic = kernel.Get<IUsersServices>();
User owner = usersLogic.GetUserByEmail(usersEmail);
unit.Repository<Project>()
.Insert(new Project
{
Title = projectName,
Description = description,
CreationDate = DateTime.Now,
UserOwner = owner,
UsersIncludeedInProject = new List<User>()
});
unit.Save();
}
Business Logic and Entity Framework (or any other ORM) don't belong in the same phrase. Separation of Concerns is the principle.
class Project
{
public Project(IProjectRepository repo, IUsersServices userServ){}
public void CreateNewProject(String projectName, String description,String usersEmail)
{
var owner=_users.GetByEmail(usersEmail);
//create project\\
_repository.Save(project);
}
One other approach is to pass the User object as an argument, object you'll get by asking a UserService or even a UserRepository to GetUserByEmail(). But it will be outside the CreateNewProject method
var user= _usersService.GetByEmail();
var project=project.CreateNewProject(projectName,projectDescription,user);
_projectRepository.Save(project);
In this case CreateNewProject does exactly that, because it's probably not its concern to save the project. I recommend this second approach.

Resources