I created a DbContext connection using Entity Framework and have "DbContext" connection string in my web.config file.
Then, I tried to log in, and my website required me to have another "defaultConnection" string for creating user tables.
In this case, do I need to have two connections? Or should I have one connection by somehow combining the two?
Which is better performance-wise? I started building my project using Internet Application template.
By default for membership and roles, the ASP.net infrastructure uses the default membership and role providers that stores that membership and roles data in different database. Run your application and if you register for a user from login page you can see the database at location "App_Data" folder created. The database is different hence the connection string is different. You are using entity framework so there are 2 ways to go from here.
1) Change the connection string and use the same default asp.net membership and role providers to store data in the database that your entity framework configuration is using. By this I mean the default membership and role providers use the database that you EF configuration points to.
2) Use EF to manage the membership and roles data. So the users and groups would be entities manages by the DBcontext as other entities.
I have recently implemented the second approach. The ASP.net membership provides hooks (extensibility) to implement your own providers and register them in the web.config file. Then create the User and Role entity and include them in DBContext. Of-course before registering the providers you need to implement them first by deriving from MembershipProvider and RoleProvider abstract classes. These classes are in `System.Web.Security' namespace.
You can follow this project for more details http://codefirstmembership.codeplex.com/
I believe the connections to separate database will not have any impact on the performance. As in the web model even if you use same database for incoming requests we have to make connections to database separately and the incoming requests can come concurrent. In fact keeping the database separate will take to database load to another server. But now you have 2 servers to back up and maintain. This will not be maintainable unless you want your membership data to be separate for some reasons like it is shared by other applications also.
I would suggest combining the two, since at some point you will probably want foreign key's from various tables to the Users table.
I would have one connection in the web.config, "DefaultConnection".
Then when you initialize your DbContext, use the DbContext(string) overload to use the DefaultConnection, like so: var context = new YourDbContext("DefaultConnection");
That way your data and Users/Roles tables live together, happily ever after.
Related
I have a web application which requires two types of users, well 3 but the third one doesn't require a role: Admins which can access every page including the admin page which allows control over members; Members which can access every page except the admin page and they can post their data (high scores of a game); and guests which can visit all pages except the admin page and they can't do anything really.
Looking around I found out that ASP.NET has roles but they are tied to only three types of role providers(SqlRoleProvider, WindowsTokenRoleProvider, and AuthorizationStoreRoleProvider). Also I'm unsure but I assume that ASP.NET's Roles are connected to the whole Membership thing which means that unless I use the ASPNETDB.mdb database everything fails.
Anyway I have to restrict everyone but the admins from entrance to the admin page and allow members to post their scores. The idea I have now is that upon login, when I authenticate the user I store the user role into the cookiless session data and read it on every page load and proceed accordingly. Is there a better way?
Asp.net membership is not tied to a DB, you can roll your own, but I am assuming that you will be storing your users in a database of some sort, so the SqlProfileProvider is probably sufficent (this can be any database, does not need to be ASPNETDB.mdb).
Details on adding this support to existing DB is here: Create ASP.Net membership database structure in existing database
You will need something like the membership, as you will need to login, you need roles, and this is what the membership API is all about. It also uses industry standard storage etc., so that you don't code yourself a security hole by rolling it yourself.
You can then restrict either individual pages, or more commonly entire folders (e.g. an admin folder) by role using web.config files.
Well, it doesn't really matter how you call your database as long as you register the membership and roles services in your own database. It is as simple as running the aspnet_regsql command prompt tool without any parameters whatsoever and it will launch a wizard (.net style) to guide you through the installation of these services. ALL it does is create sql server objects in the database you wish (schemas, tables, sprocs, etc)
Now, if you dont like these built in providers (particularly I don't) there's nothing stopping you from implementing your own, it's quite simple but maybe a lengthy process due to the amount of abstract or virtual methods you'll need to implement/override depending on your approach or need. You two options to implement your own...
one is implementing theRoleProvider abstract abstract class or
extend/inherit from the SqlRoleProvider class which exposes a lot of virtual methods and properties.
My first question is: Is there difference betwen apsnetmembershipprovider and simplemembershipprovider. I know that aspnetmembershipprovider is disgusting, because it always create temporary tables. so I'm wondering is SimpleMembershipProvider uses AspNetMembership sql queries or anather.
And My Second Question is what membership provider use for Web Api project, where client app will be mobile application.
this description can be helpful:
The WebSecurity helper class is the recommended way to manage user (membership) accounts, passwords, and other membership tasks. The SimpleMembershipProvider class can manage membership tasks; however, it is not recommended because WebSecurity provides a simpler way to implement membership. The SimpleMembershipProvider class is intended for developers who require more precise control over the membership process.
You can read more here, section "Remarks": http://msdn.microsoft.com/en-us/library/webmatrix.webdata.simplemembershipprovider(v=vs.111).aspx
If you don't like the way provider does the tables in the database, you could implement your own provider or use the Entity Framework Membership Provider (if you use EF): http://efmembership.codeplex.com/
We are trying to achieve the multitenancy in our asp.net (Web forms) application. We are providing separate database for each tenant. We have one master database which stores the configuration string for tenant databases.
We are using Application_start (Global.asax) to go trough all connection strings and inject all session (alias) for each tenant. Every thing works fine.
We wanted to introduce the capability where we just create new tenant database and connection strings for it in master database and application should be able to serve new tenant without restarting Website(IIS restart).
Can I get some hint how can I achieve it without restarting web site?
Thanks
Shishir Kumar Mishra
Although this implementation is about testing with an embedded database, but it should be enough to give you an idea.
http://www.codeproject.com/Articles/18348/TDD-using-SqlCE-and-NHibernate
I have an ASP.NET project where I want to keep the membership (SQL Provider) in a separate database and the Roles/Profiles will be per application.
Question
What is the KEY that relates between the Membership database and the Roles/Profile database? Is it the UserID or UserName?
I opened up the tables in separate expolrer and notice the UserID is different in the Membership database from that in the application Roles database.
If I read your question correctly, you wish to store membership in one database instance and roles in another.
This is acceptable and possible by simply providing different connection strings. You no not need to implement a custom provider.
Understanding the fact that roles and membership are truly separate concerns, except for minor bleeding posed by the MembershipProvider.DeleteUser method, and can operate in isolation.
There is no true 'relation' between the roles and membership tables and any that are inferred by the appearance of records in the aspnet_users table are coincidental. If a record is present when a role query is made for a user, that userId is used otherwise a new record with a new userId is created.
The common value used throughout the provider stack is the username field, which, while unique to an application, is not a key.
So, as long as you are aware that you must manually perform deletion of role records when you call Membership.DeleteUser, you may simply use two databases, no custom implementation required.
Good luck
The best thing you can do in this case is implementing your own (custom) MemberShip and Role provider. The relationship between a membership and roles are defined by yourself and the username is commonly used for this.
Remark on Poet's responses:
Perhaps i shouldn't have mentioned "best solution", but in my opinion the default AspNet membership and Role provider accompanies the Aspnet tables which are created using the aspnet -regsql command. If Microsoft's Membership and Role Provider don't fullfil your needs, you should create your own.
If you create your own membership and role provider, it will be clear to other developers that they are dealing with a provider implementation which works or is structured in a different way.
My conclusion is that my solution was perhaps not "the best solution", but more a recommendation. The other thing is that the ASP.NET Providers aren't an example of good software design anyway. We are still using it, because of their compatibility with other controls. Your solution is ok, but mine will do as well and it's up to mr. Saif to choose a solution that fits best in his application.
As Microsoft mentions:
There are two primary reasons for creating a custom membership provider.
•You need to store membership information in a data source that is not supported by the membership providers included with the .NET Framework, such as a FoxPro database, an Oracle database, or other data source.
•You need to manage membership information using a
database schema that is different from
the database schema used by the
providers that ship with the .NET
Framework
I'm in the process up changing a single SQL DB website (ASP.NET/VB.NET) into a multitenant app, where each client has their own database.
In the old site, all the ASP roles, logins and providers pointed to the single database.
Now we have multiple databases, I'm wondering what would the best architecture/techniques to use. There is one database that configures the tenants, such as the company name, various settings (that would normally be in a web.config) and the connection string to their tenant database.
Should we have all the membership & role stuff in the single database that configures the tenants or do we have membership & roles in each individual tenants database? Option 2 seems tricky because I think ASP.NET only likes one set of RoleProviders defined in the web.config.
Has anyone tried this before or got any recommendations?
If you're using the ASP.Net Membership model with the built-in providers' then putting them into one DB is the easiest as you indicated.
One option, and I've not tried this, is to define in your web.config file a provider for each tenant. This would allow each tenant to have their own membership db, and allow you to avoid username collisions between the tenants (if this is a requirement).
You should be able to configure the the ASP.NET membership database connection string at runtime. This thread has a few options including a custom membership provider or changing the value early on in the request lifecycle via Global.asax.cs.