I'm looking for assistance here. I've built an application that uses .NET Core 3.1, identity, and EF Core. I've extended aspnetusers to include additional columns. My company uses stored procedures for all other db queries.
My question is how do I go about getting the currently logged-in users' information and using this information (that includes the custom extended identity) in a FromSqlRaw select statement against the database. Currently, my user is hard-coded but this should be whoever is logged into the application.
This is what I currently have.
Select * from dbo.CustomerList where usercode = 'BobS';
My guess is to use claims but I'm not sure why my code isn't working.
I'm assuming that at your entry point you already have the logged in User, most likely from the HttpContext.
You could inject the UserManager into your current class and load the user via something like this.
var user = await _userManager.GetUserAsync(HttpContext.User);
This user object then should contain all the fields including custom fields of the efcore entity that you created.
You can then extend your efcore dbcontext to map results of raw sql queries and run something like this.
var customers = context.CustomerList
.FromSqlInterpolated($"Select * from dbo.CustomerList where usercode = {user.Code}")
.ToList();
For further reference you might consult the following links:
https://learn.microsoft.com/en-us/ef/core/querying/raw-sql
https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.identity.usermanager-1?view=aspnetcore-5.0
In general using ORM frameworks like the entity framework while coding most of the application logic inside of the database via stored procedures might not be the best approach. Usually I create most of the business logic in .NET querying necessary data via the ORM framework and only using store procedures / functions via the raw query option for performance critical scenarios or when the mapping of the ORM framework fails.
Related
A while ago I asked this question about using EF with ASP.Net core, and this is working great. Now that I want to add ASP.Net Identity, I'm wondering if the best approach is to add identity logic to the separate project with regular / non-core EF, or into the main core project with EF core, or something else. I see a lot of pages that discuss EF core, but I would prefer to use the same context everywhere, and I would prefer to use regular EF as I am currently doing. I'm looking for what would be a clean / best practices approach here, I have been using regular EF since to my knowledge EF core 1.0 doesn't support stored procs, and I prefer to continue to use a database first approach anyway. Appreciate any help that gets me out of the quicksand.
NOTE: My 'User' table (called something else) has some existing profile data in it; I intend to use this as my Identity User table.
Have you considered having an explicit Identity service that can issue tokens based on your existing identity database?
IdentityServer4 is an OpenId Connect provider. It supports EF so that you can use your existing user data to perform authentication.
The push now is towards .NET Core and it would be a good step in that direction to have a separate project dedicated to handling identity that uses IdentityServer4 and EF Core.
ASP.Net Identity Framework is designed for Code-first, and will normally try to generate its tables for you. I'm not sure if it is able to work Database-first, but I think you could get it working as follows:
Create a separate, temporary, project/solution with Identity / Individual User Account.
Insert the data structure from this temporary database into your main database, merging AspNetUsers with your User table.
Delete the temporary project/solution and database.
Update the models in your EF6 project. This should bring in the new tables.
Add Identity Framework to your ASP.Net Core project, referencing the database context from your EF6 project.
I haven't tried this, but having worked with Identity Framework quite a bit I can't see a reason why it wouldn't work.
Further reading:
Database first Identity: Using Asp.Net Identity DataBase first approach
Custom table name for Users table: How can I change the table names when using Visual Studio 2013 ASP.NET Identity?
I am trying to update an older website. It already has an existing database with a user and a role table, with existing data in it.
I need to create a new web-api and a new web project and integrate ASP.NET Identity into the already existing database.
I have currently setup my solution to breakup the projects as follows:
Domain
Services
WEB_API
WEB_UI
My aim is to implement the Identity in the services layer so that both my WebAPI and MVC site can utilize the same identity mechanism.
I am fairly overwhelmed at the moment, I have read many tutorials and articles over the last day or two and have ended up with the options of either re-implementing the IUserStore and IRoleStore. And also with mapping the different entities in the OnModelCreatingMethod.
I cant seem to find a tutorial which is aimed at what I want to do. My database is to different to simply remap the names of columns, And I dont want to re-implement the entire Identity Stores as there are only a few conflicting fields. Most tuts I have found are related to using mysql instead of EF. I still want to make use Entity Framework.
Issues I have:
The current Users Table in the database used Int pk , not GUID
The Password Field uses a different Hashing algorithm. So i would need to override how Identity checks and store the password.
I do not have all the required Identity User fields in my database, however I am able to add new fields, I just cant change already existing fields.
I am making use of Database First as the DB already exists.
So basically my question is, In what direction do I need to go in order to overcome the above mentioned issues. Can I get away with changing the Database mapping? Or do I need to go as far as re implementing the User and Role Stores?
What I had initially planned was to re-implement the User and Role Stores using entity framework, And i could then make use if the DB first model classes and map the actual DB structure and fields to my ApplicationUser Fields. But this is where I thought I might be diving into cold waters, and i'm generally not a fan of reinventing the wheel if not necessary.
-The first thing you should do if you haven't already is to BACK-UP your current database!
You could use code first to update an existing database.
I found this walkthrough and it seemed close to the route you're on, and I'm hoping it will help solve your problem, begin at "Migrating to Visual Studio 2013".
http://www.asp.net/identity/overview/migrations/migrating-an-existing-website-from-sql-membership-to-aspnet-identity
This would create a few new tables, but not necessarily a new database.
Download Nuget packages:
Microsoft.AspNet.Identity.EntityFramework,
Microsoft.AspNet.Identity.Owin,
Microsoft.Owin.Host.SystemWeb
Enable-migrations and run a script such as this: https://aspnet.codeplex.com/SourceControl/latest#Samples/Identity/SQLMembership-Identity-OWIN/Migrations.sql
Or you could try using a reverse POCO generator found in visual studio extensions.
(My 1st attempt at writing an answer here. Tried to clarify.)
i'm working on an ASP.NET MVC project with EF code first as database modelling.
It's a multi user application in which everyone has it's own database, what i need now is the ability to list all Posts of all the user using the platform, so i search for cross database querying.
It seem EF doesn't support this type of query because the dbcontext is linked to a fixed connection string, then i ask you which method i can develop to achive my goal?
I was thinking on using two dbcontext, one for the database of the user and another database containing the data of all users, trying to duplicate CRUD operation both in personal and global database, but it seem very odd to do.
Any suggestion? Thanks in advance.
if it is only " what i need now is the ability to list all Posts of all the user using the platform"
-> you can create sql server view use linked server query to get the data from different databases
Create a stored procedure to return the data from the linked servers, then call this store procedure using ExecuteStoreQuery. Create an entity to hold the result set, and have EF hydrate the results.
The title is not so accurate, but I couldn't come up with a better one.
I’m trying to write a MySQL Connector for MS‘ Forefront Identity Manager (FIM is basically a sync engine that synchronizes identities between various data sources using a meta directory). But I’m having difficulties to come up with an appropriate design.
Let’s say I want to import user data from a db into FIM’s metaverse. A user object has various attributes like firstname, lastname, address etc. In the database these attributes can be distributed between multiple tables. FIM ultimately needs these attributes to be merged into one object. So the user needs to configure the connector to tell it how the data is stored in the DB.
I was wondering what would be the “best” way to represent this configuration. Two alternatives come to (my) mind:
I could just save a select query that merges/joins the data, so that the result is a single “table” with all the desired attributes. The problem with this is that I think I would have to do some kind of parsing on this query-string to create a fim-compatible-schema out of it (which is basically the name of the object type (f.e. “person”) and a list of attributes). This schema needs to be creatable from the query-string alone without actually executing the query (I could execute some fake queries if that would simplify the process).
I could create some classes to represent the database schema, i.e. the tables and relationships. Since I’m not that experienced with MySQL (or databases at all for that matter) I’m running the risk of missing some special cases. Also it might be some kind of overkill, since the schema can be assumed as fixed once it's configured.
Does anyone have same advice on which alternative to choose and how to tackle the problems that would come with it? Or is there another – better – alternative I didn’t think of? Any advice would be greatly appreciated!
If something is not clear, please let me know.
Edit: Since there have been some questions on the use case, I'm going to elaborate a bit:
As I've said, I'm developing a Management Agent for FIM. FIM provides a so called Extensible Connectivity Management Agent, which is basically one single class implementing a few interfaces. (See this technet guide for a sample implementation).
Since I want to develop a generic agent for managing identities in a MySQL database, I don't know the database layout at compile time. When the enduser wants to use the management agent, he needs to decide, which attributes of the identities he'd like to manage. So I need to give the user some way to configure the management agent. My main question is, how to design the classes to save this configuration.
Lets look at a simple example:
Say you want to manage employee identities. To keep it simple, we have three attributes:
firstName
lastName
department
In this example case it could be f.e. just one single table with 4 columns (the attributes plus an id). But it could also be the much better design, which uses two tables, one user table and one department table, using a 1:1 relation to define the users department.
FIM requires me to consolidate these attributes in one object. It provides a class CSEntryChange which has an AttributeChanges collection member. I would then create some instances of AttributeChange (which basically contains the attribute name und it's value) and add them to the collection. So the user-editable configuration must tell the management agent how it can get the users with all defined attributes from the db and how to create and modify users in that database.
So ideally I'd have an intance of some "MySQLSchema" class (which is configured by the user up front), that could return a List<CSEntryChange> (I wouldn't actually use the CSEntryChange class for the sake of decoupling, but you should get the point) that contains all users in the db (pagination might be a requirement but I can figure that out later). In addition I'd like to able to pass it a CSEntryChange which would result in the corresponding database entries beeing updated (or created if not yet present).
I hope this clear it up a bit more :)
I think that your real question is, "How to access MySQL entities over C#?"
To begin with, I hope you are building this in as a MVC application.
I would suggest sticking to a full Microsoft stack for purposes of learning and ease of implementation.
With this in mind, you will want to create an EntityFramework MySQL data provider in the following steps:
Create a new project and and EntityFramework either through the Nuget package manager UI or package manager console by typing Install-Package EntityFramework -Version 6.0.2 (and add a reference to this project from your web project). Look half way down the page for "Configure EntityFramework to work with a MySQL database".
Install the MySQL provider for entity framework through the Nuget package manager UI or by typing Install-Package MySql.Data.Entity in the package manager console
The next step requires understanding of db configuration changes, that are nicely detailed here - Configure EntityFramework to work with a MySQL database.
You should end up with a nice class structure which will allow you to traverse your entities' navigation properties through EF.
Depending on the level of security your application requires, you may also want to create data transfer objects (DTOs) that contains only the data required for your remote calls - keeping your data calls efficient.
This is by no means a definitive guide on how to do this, but hopefully gives you a start in the right direction.
With regards to your step #1 above:
I could just save a select query that merges/joins the data, so that
the result is a single “table” with all the desired attributes. The
problem with this is that I think I would have to do some kind of
parsing on this query-string to create a fim-compatible-schema out of
it (which is basically the name of the object type (f.e. “person”) and
a list of attributes). This schema needs to be creatable from the
query-string alone without actually executing the query (I could
execute some fake queries if that would simplify the process).
I am slightly confused by this. Are you saying that you want to dynamically update your database schema based application requests?
You can use NHibernate with MySQL, and NHibernate is a full featured ORM, where C# classess maps with your MySQL tables, and the rest will be a breeze, once you get a hang of NHibernate.
A sample is here for your reference.
http://www.codeproject.com/Articles/26123/NHibernate-and-MySQL-A-simple-example
When you use the MySQL Connector/Net you can also use Entity Framework like this example from MSDN:
using (var db = new BloggingContext())
{
// Create and save a new Blog
Console.Write("Enter a name for a new Blog: ");
var name = Console.ReadLine();
var blog = new Blog { Name = name };
db.Blogs.Add(blog);
db.SaveChanges();
}
I have some experience with .NET <-> MySQL communication and I've used Entity Framework in the past for the communication - I had a lot of problems with it and performance issues and soon came to regret using it (this was 1-2 years ago, so may be they fixed it up). Of course, using an ORM framework adds a layer on top of your db communication which in my case proved to be not desired in terms of performance and flexibility.
Finally, I chose to take the following approach:
1) Create models with POCO classes as you would do with Entity Framework. Those models may or may not include relationships - it is up to your preference. I prefer to only add the relationships when I actually need them (so some objects may have their db relationships in the POCO's and some may not). I chose this because it lowers the complexities of when to pre-load the relationships and when not. Basically, if you don't need it - don't add it.
2) Create DAL layer (for example, using the repository pattern) that accepts and works with those objects and fires direct queries to MySQL. No EF required for this - you just need to install the Connector/NET for MySQL and you are ready to go.
A quick example of this would be the following (note: example is of the top of my head and it is just to illustrate the classes. I would use command parameters as well to prevent injection and so on):
public class Person{
public string Name {get;set;}
}
public interface IPersonRepository{
void AddPerson(Person p);
}
public class PersonRepository{
public void AddPerson(Person p){
using(var connection = new MySqlConnection("some connection string"){
connection.Open();
var command = new MySqlCommand(connection);
command.Text = string.Format("insert into Person (Name) values ({0})", p.Name)l
command.ExecuteNonQuery();
}
}
}
The benefits of this approach for me are:
Performance - my application need to insert large amounts of data int MySQL. Entity Framework could not cope with this. If your application doesn't handle a lot of data you might be alright with EF.
Flexibility - writing my own queries allows me to have better control over the communication. You can choose, for example, to use bulk inserts in MySQL (from file - really powerful and fast when you need to handle large amounts of data) for which you will need to bypass Entity Framework. I also found out that EF generates some funky queries
The main drawback is, of course, more work - you will get some things for "free" with the Entity Framework.
So, I can recommend the following:
Consider the amounts of data that you need to handle and make a small exercise application with those amounts. How does EF (or any other ORM) handle it? What about direct queries to the database? That will give you a somewhat accurate idea of how the communication will perform.
Consider how much time you have for building this application - if you are looking for a quick solution and are willing to sacrifice a bit of performance - go for EF or another ORM framework. If you have more time on your hands and would like to make a flexible solution - go for direct queries to the database.
Good luck!
Use Entity Framework Code First.
http://msdn.microsoft.com/en-us/data/jj193542.aspx
It is still a lot of work, but I think this is the quickest approach.
Create a C# classes according to the user and create the DB schema from those classes.
We are developing an ASP.NET MVC Application that currently uses it's own database ApplicationData for the domain models and another one Membership for the user management / membership provider.
We do access restrictions using data-annotations in our controllers.
[Authorize(Roles = "administrators, managers")]
This worked great for simple use cases.
As we are scaling our application our customer wants to restrict specific users to access specific areas of our ApplicationData database.
Each of our products contains a foreign key referring to the region the product was assembled in.
A user story would be:
Users in the role NewYorkManagers should only be able to edit / see products that are assembled in New York.
We created a placeholder table UserRightsRegions that contains the UserId and the RegionId.
How can I link both the ApplicationData and the Membership databases in order to work properly / having cross-database-key-references? (Is something like this even possible?)
All help is more than appreciated!
In my opinion, you should be able to integrate your database with the standard aspnet_db reliably, but I would advise against duplicating or replacing the aspnet_users table.
That is the focal point of all the providers that use the aspnet_db schema, including custom providers that may augment but do not implement custom replacement.
To maximize reuse of strong tested infrastructure code in the provider stack/API it is best to go with that flow.
You will want to be very attentive to any modified membership core functions and ensure that the way your new constraints behave in an expected fashion in each case.
The facet of the membership story that I have found needs the most attention is deleting a user, and a simple modification/addition to the delete user sproc can manage this capably.
It sounds like you might need to create your own customized Membership Provider. You can probably (not positive here) extend the existing one so you don't have to completely reinvent it. Here is a video from ASP.net that describes how to do that. Google "asp.net membership provider" for tons more.
You can try rolling your own membership or just extend is like Dave suggests.
Create your own [Users] Table which can be populated based off the aspnet_Membership table. So therefore you could have more control over it.
You could also just implement a more involved Profiles system. The .NET team has improved the way profiles are stored now, so instead of "blobicizing" them, you can set them up to be stored in an actual table now [thank god].
Table Profile Provider
If you find the right articles, it's really easy to extend the membership provider to allow for extra functionality. I've moved my users table to my main SQL server table and have written my own role manager that gets values from a separate table. What it sounds like you need to do is to set up a table in your users DB with the location of each user, then create a method on the user object something like "GetLocation()" that returns the user's location from the DB, you could then user that to filter your data from your main DB. Here's a few articles I had kicking aroundin my bookmarks, see if they help, if you have a look on the main ASP.NET site or google for membership provider extending articles, there are plenty around.
http://msdn.microsoft.com/en-us/library/ms998347.aspx
https://web.archive.org/web/20211020202857/http://www.4guysfromrolla.com/articles/120705-1.aspx
http://msdn.microsoft.com/en-us/library/aa479048.aspx
As the others have pointed out there are many good resources available that can help you with creating your custom provider using the existing database.
It looks like you are headed in the right direction with mapping tables. I think the one piece you are missing is Distributed Queries. This link is specific to Sql Server 2008. There is a link there to the documentation for Sql Server 2005 if that is what you are using.