I'm using the MVC4 Internet Application Code First. I was wondering if there is a way for me to retrieve the PasswordVerificationToken from the webpages_Membership table. I've tried following instructions in this older question.
I'm able to retrieve the PasswordVerificationToken from the webpages_Membership table however when I try to add a user to a role using Roles.AddUserToRole I get a foreign key constraint error.
Doesn't matter just added the simple membership tables to an entity model
Related
I'm using Identity 3 and I want to add some columns in AspNetUser table.
I've tried to do it using EF Core Code first and it's working well but I need to do it DB first.
I was wondering, if I will create the columns manually in database, then create the ApplicationUser class with corresponding properties, will it work?
Yup that should work, I've done it before.
However as time goes on I ended up having to add so many that it got messy.
So eventually I refactored those extra columns into their own related tables:
e.g: User_AdditionalDetails
This was a massive pain as I had live users and had to write scripts to migrate everyone's data etc.
This way you would only need to add a single FK for the related table with all this extra info.
It also neatens the code too, and gives the benefit of being able to load different sets of user properties only when they are needed.
If it's for an application scope property of the user like 'Region' which determines behaviour of core functionality of your app, then I'd say add it straight onto the main ApplicationUser class.
Is it ok to delete records from ASP.NET identity tables AspNetUSers, AspNetRoles and AspNetUserRoles directly from SQL Server using T-SQL? The ASP.NET Core app is using only these three identity tables other AspNet... tables are empty.
UPDATE:
Why we want to do it directly through T-SQL since app has several users (with one role) and client wants to get rid of all the users quickly in one shot.
It is ok to delete rows from AspNetUsers, AspNetRoles or AspNetUserRoles.
Because IdentityServer does the same.
For example check the SQL statements which are generated when deleting a user through the UserStore class.
I know that each time a user registers in my ASP.NET MVC application the ApplicationUser class is used to create the new record and put it in the database.
I was wondering if it's okay to add properties to that class for example I want the model to have a column in the database for DateOfBirth. Then use that class(model) directly in my application when I have to do some business logic things, database queries and similar stuff. Or is it more correct to create a new table in the database called let's say ApplicationAccounts, that saves the general info about the account. Each ApplicationAccount will be associated with a ApplicationUser(1 to 1 relation) and be somewhat of a buffer in the communication with the real accounts. Does that make sense?
I would go with the second option : create your own table, link them up in a one to one relationship using the UserID as a unique foreign key and then go from there.
One note here, it is perfectly normal for the model you need for the views to be different from the database model, this is because your db model can hold a lot of data that your view doesn't actually need. You might want to consider having separate models and use something like Automapper for a quick translation from one to another.
I have an ASP.NET MVC 5 web app. I have connected to a database on localDB ("MyWebAppDatabase"), which already contains many tables. I am accessing this using ADO.NET Entity Framework, and this is all working great.
However, I would like to add a table which references users who use the website: I have a "Subscription" table and would like to associate it with an ApplicationUser. The problem is that the tables containing user information are stored in a separate database (which was automatically generated by the Visual Studio when I created the project under the DefaultConnection context), and I don't know how I can perform this association.
What is the best way to go about this? I thought the ideal solution would be if I could move the tables that ASP.NET automatically created for application users into MyWebAppDatabase - then I can easily update the database with the correct tables and foreign keys. Is this correct? If so, how would I go about doing this? I'm not entirely sure where the database is for the application users (I couldn't decipher it from looking at Web.Config and reading the DefaultConnection connection string) and I don't really understand how I would be able to migrate the tables.
Thank you all for your help!
Ideally if you can move the tables into a single database you will get the best performance, otherwise you will have to do all of the JOIN's in memory in the application. You can't make foreign key references across database unfortunately.
If you point the connection string for the ASP.NET Identity to the same database that your Subscription table is located in and run the application and create some users it should create those tables automatically.
Ihave a DB First EF5 project that I am implementing SimpleMembership in. I have most of it working, but a question has come up.
The main User table created by Simple Membership has the UserName in it. I have a couple other places in the app where I need to query this table, specifically the userName. Simple Membership does not use the Data.EntityClient in the connection string, so i have it set to the SqlClient.
So because i don't have an entity model with the provider User table, I am not sure how to query it. Usually i would create an instance of the entity model and use LINQ on it, but when I try it I get a very long winded error about mixing code first with entity first. I have modified the 'initialSimpleMembershipAttribute' so it points to the separate connection string I made for the Membership tables.
One solution i thought of was to save the user, then copy the username to one of my custom tables, then i can query it through EF, but this seems like it would violate some kind database 'best practice' of duplicated data.
Another idea I had is to create a second edmx model for the tables that Membership created, but if SimpleMembership does not use the EntityClient, does that also mean it will not recognize a entity model?
You're way over complicating things.
If you have your own model, then you can just get rid of the model that the default template gives you, and use yours instead. It doesn't matter if it's Code first or database first or whatever. Just change the Initialize SimpleMembershipAttribute to remove the references to the default model they give you, and make sure you modify the InitializeDatabaseConnection call correctly.
WebSecurity.InitializeDatabaseConnection("YourConnection", "WhateverYouCallYourUserTable",
"WhateverYourUserIdIs", "WhateverYourUserNameColumnIs", autoCreateTables: true);