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/
Related
is there a way to customize the database access in the new MVC5 identity?
I don´t use the DbContext in my web project, because I created some security and validation layers for database access.
Do I have to derive from UserManager or UserStore, implement the interfaces IUserPassword store or something like that?
I heard something about an API to customize identity, but how can I use this API?
You need to implement your own UserStore and User types to match the schema that you want.
You will have to implement the Interfaces for the features that you want in your system
You can reuse the UserManager since UserManager just uses the UserStore and User that you pass in.
The following article explains you in detail how to do it http://www.asp.net/identity/overview/extensibility/overview-of-custom-storage-providers-for-aspnet-identity
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.
Is it possible to override the logic IsInRole in asp.net? I use my own tables of roles in the database and I would like to know how to use own logic.
Something like inheriting from PrincipialBase. Do you know some ways?
I would only use RoleProvider if you are using other aspects of ASP.NET authentication and authorization management. However, if you have your own database for storing role information and already have a UI for managing user roles, you can get away with just creating a GenericPrincipal with your roles and replacing HttpContext.Current.User with it during PostAuthenticateRequest (for ASP.NET).
MVC is slightly different, depending on how you are managing authorization. Here is a related question.
application role management in asp.net mvc (How)?
It is better to load all the roles for a user once per request then to check roles against the database multiple times during the request.
Then you need to implement a custom RoleProvider. Here is a guide to implement a RoleProvider.
Microsoft released the source code for the default providers (membership, role, etc...).
That is also a great reference when implementing your own provider. The one time I implemented a custom role provider, it served me very well.
I read this article here
http://www.codeproject.com/KB/web-security/RolesFormsAuthorization.aspx
What is the limitation of Membership that would require me to implement my own ?
The primary limitation is using the arbitrary database design of the Membership provider along with being relegated to the Membership API.
I have always found the membership provider API to be kludgy (at best) and the database design it requires to work out of box to be atrocious. I have never once used the builtin membership to fruition ... I think ever but absolutely not in any application I have in production.
So to sum it up, the primary reason to not use the membership provider out of box is the database design will not match your design and you will have a hell of a time trying to use your application database + membership database together or you will have a large amount of insidious data duplication of users, ASP.NET user vs application user.
Personally I've found the standard membership provider extreamly flexible. But one reason could be to allow your website to authenticate users against a legacy database containing usernames and passwords created by a different system, or to authenticate against a web service.
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