I am creating a custom site using the default membership provider, MVC5, EF6.1.1 using Code First.
The question I have is, what is the best way to link the two user tables? Should I have 2 databases? Should I just build my application into the database for the membership provider? And if that is the case, is there an easy way or a method to extract the GUID that is created when a new user registers to map a foreign key to my user table?
I guess I would rather keep the two separate and not have to deal with writing a custom provider, but I can't seem to wrap my head around the most logical way to do this.
Thanks!
Tony
Related
I’m looking forward to creating a multitenant-based SASS application. I have defined database design like each tenant using different databases (Postgres) with standard objects(tables) like contact, and accounts. So far clean, I can see many SaaS application supports Custom Object(tables), where customer can create their own objects in real-time and required columns. I would want to support the same. Could someone please explain the backend logic behind that? How can we add new tables for custom objects in the database and refresh the DbContext entity at runtime?
Note: I’m aware for custom fields, many choice JSON-type columns in Postgres, it opens ways to add as many custom columns as JSON type in existing tables. But don’t find any recommended way to do custom object support.
EF doesn't really support adding tables at runtime. You can use ADO.NET queries to work with tables whose schemas aren't known at design-time.
I'm new to MVC and currently working with MVC6 (EF7, Identity3, VS2015)...
I would like create two different/independent WebApps in one company domain (in different sub domains).
I would like use common/shared identity/login system for both Apps - in different words I would allow user to have one account across both Apps.
I do not have option for domain authentication (the company doesn't use the domain - I know it's weird), so I must? use Individual User Accounts...
What is the best way/practice to create and use common user account across multiple apps ?
In first place I thought about creating two different DBContext in both App: one for Identity (Users DB) and second for App-Related Db...
Such an approach would give me three different databases:
IdentityDb - common for both WebApps,
App1Db
App2Db
However I have doubts if it's good practice and the best way ?
Probably will be enough one DBContext with proper configuration, but I don't have idea where I should start.
I have read about SSO (Single Sign On) - but as far I understand it's about Authentication process, so it's little bit later - so I'm not sure about this direction.
Anyway can't find example how to create common user account/profile across multiple apps.
UPDATE:
My original question is probably too open... I would like ask not only 'what to do' but also 'how to do in MVC6'...
So my additional question is: how can I achieve this in MVC6? What I have to do? Perhaps some example?
If I decide for a separate User DB - then from the point of view of the application I will have two DB? What to do with this in code? Should I create two separate DBContexts - or just one?
Also I have read few opinion here on SO, that using only one DbContext is better and simpler option...
Anyway I have try yesterday works with 2x DBContext - everything works when I create new controller for IdentityDbContext, but I have error when trying create any controller for second DBContext (not associated with Identity)...
(I've put description of this error to new question: MVC6 Working with two DBContexts and error when create new controller)
Thanks in advance for any advice :)
The answer to your question if having three databases is the best way, is: It depends.
The answer to wether or not this is a good practice is irrelevant.
Let me elaborate.
The notion of every app having its dedicated database stems from old fashioned thinking. Big enterprise architectures are made up of all kinds of persistence storages, each chosen to do what it can do best. So it has nothing to do with good practices. You should store the data where it is suited best. Have a look at Domain Driven Design and Bounded Contexts in particular to get a better understanding of what I am talking about.
So the question if you need three databases, if in your particular situation this is the best option, then that is what you should do. To make this answer complete I' ll describe our situation. We have an old user database with users in it. We can't get rid of it untill all web apps have been phased out. To minimize the effect it has on our customers. So for our new web apps we only use this old database for the users and use azure storage for everything else we need to store. In other words, conceptually our situation is like what you describe. A seperate storage for the users that all other web apps use.
sounds like a good solution to the problem to you?
Update
As to MVC6, Identity Server 3 specific. ID server 3 has the ability to use custom User Service which allowes you to couple any user storage you want. Here are the details: https://identityserver.github.io/Documentation/docs/advanced/userService.html. This is exactly what we have done.
As for your other question; we will put the users in Azure Table Storage probably and retrieve it from there via IdentityServer4 when all old apps are gone. Right now there is nothing left in the legacy MySQL DB but users for us. But there are some old apps still using it, so...
Does this answer your questions?
In previous version of ASP.NET Identity (2) sharing identity cookie across subdomains was the sloution. I'm not sure about ver 3 but you can test it:
change Identity config in Configure method of Startup class:
services.AddIdentity<ApplicationUser, IdentityRole>(config =>
{
config.Cookies.ApplicationCookie.CookieDomain = ".domain.com";
})
.AddEntityFrameworkStores<ApplicationDbContext>()
.AddDefaultTokenProviders();
I'm looking at implemented a muli-tenant portal solution for my SaaS application using Orchard CMS. I'm pleased that it appears multi-tenancy is a first class feature, but it looks like in order to achieve it, I've got to either a) Create a set of tables for each tenant with a table prefix or b) Have separate databases for each tenant.
I'm trying to build a solution for 10,000+ customers, and so anything that requires me to make physical data schema changes per tenant won't scale. In our SaaS application, we use a tenantID column on all tables, plus the use of nHibernate filters and a heck of a lot of indexes to allow us to scale.
I'd like to do the same in Orchard. So instead of a table for each tenant, I'd like ONE set of tables with a tenantID, and then use filters in the data access layer (NHib) to always pull the right data.
Questions:
1) Is this possible?
2) Has anyone done this?
3) Any thoughts on the best way? I was going to modify the MultiTenancy/NHiberate module source directly.
It is possible, but quite hard to do.
It's also most likely not a scenario for Orchard multi-tenancy, but without any further details I cannot be sure.
This feature fits best in cases where you need to have a totally independent applications and (almost) nothing is supposed to be shared between them - like in shared hosting, for instance. The major drawback is the memory overhead, because each tenant has its own copy of the whole internal object infrastructure.
A much easier approach, instead of trying to put a square peg in a round hole tweaking multi-tenancy, would be to use single tenant and implement your desired multi-tenancy scheme in a separate module on your own, from scratch. You could eg. have a "Tenant" content type and build your module around it.
I'm looking into how to integrate [Authorize] within my MVC 2 application... I'm reading articles about it and I've run the aspnet_regsql tool. I see that my database now containes a bunch of new tables and a whole hell of a lot of SPROCs.
Why is all of this necessary? I thought that I would be able to check login credentials in a table that I've already created for Party ... can't I just call a SPROC that checks the login credentials and then logs the user in? Why all of these new tables and SPROCs?
Because it is the way how it is works. If you using ASP.NET Membership by default you need to have database aspnetdb with lots of tables and stored procs. If you want you may customize that. In order to do that you need to implement custom membership provider.
The simple example how to do that you may find here http://msdn.microsoft.com/en-us/library/aa479048.aspx and here http://www.asp.net/general/videos/how-do-i-create-a-custom-membership-provider also source code available.
It sounds like you want to create a custom membership provider. For logging in I think you really only need to override the ValidateUser method:
http://msdn.microsoft.com/en-us/library/f1kyba5e.aspx
For roles you may be able to get by with overriding only the IsUserInRole method:
http://msdn.microsoft.com/en-us/library/8fw7xh74.aspx
I have to write a solution that uses different databases with different structure from the same code. So, when a user logs to the application I determine to which database he/she is connected to at runtime. The user can create tables and columns at any time and they have to see the change on the fly. The reason that I use one and the same code the information is manipulates the same way for the different databases. How can I accomplish this at runtime? Actually is the Entity Framework a good solution for my problem?
Thanks in advance.
You can do this with EF 4 using a code-first model. That said, I tend to avoid changing DB metadata on the fly, with or without EF. Rather, I'd choose a schema which fits the user's changing needs.