Update Asp Net Providers
The asp.net providers (membership, profiles, roles, etc) are a bit dated. This does not only include the specific implementation of the providerrs (SQL providers) but also the base classes themselves.
Please try ASP.NET Identity where we added support for OpenID, OAuth provides as first class support in membership.
Along with this we have alsomade it easier to store the membership information in non relational databases as well
Wayne Brantley commented
Open source the new universal providers.
Flávio Oliveira commented
interesting if membership could have a OAuth mechanism to interact with facebook or twitter...
It is cumbersome to use it with ORM based solutions such as nhibernate.
The lot of phones have normality internet communication tools.Ai peg pardon but ai am not internet sick because to my mind it is expensive for simple unemployed human.
Kenji Kina commented
Id based providers instead of name based ones would be extremely helpful.
Eugene Agafonov commented
First of all, I dislike providers singleton implementation, which is very bad for obvious reasons. The contract is too huge, there shouldn't be enforced paging implementation there. As for things like Guid UserId, perhaps you can introduce generic interfaces for providers. Also, providers infrastructure is nailed to the asp.net runtime, which is awful for testing.
So, give me simple interfaces, allow the extension via provider factories / IoC containers (perhaps even MEF), and decouple providers from asp.net runtime.
If only I could get such providers framework I would be SOO happy :)
Imar Spaanjaars commented
Besides the aforementioned items, there are a couple of other improvements that could be made:
1. Double opt-in
E.g. activate accounts only after they've been confirmed by the user through an e-mail. Possible features could include: Expiration policy (where non-confirmed accounts expire (and get deleted) after X period of time, "Thank you" page property where users are sent after confirmation, a registration ID that is used in the e-mail and that's available in the message template for the e-mail that gets sent, API access to the registration / confirmation.
2. Different data model for Profile
The current profile storage mechanism for Profile makes it nearly impossible to query for something like "Give me all users with Red as their favorite color). Right now you have to pull all data in the application and query there. Using the table based approached used in the "Sandbox ASP.NET Table Profile provider" would make this easy with EF or L2S.
3. Make Profile a property of Membership user
Probably not easy due its dynamic nature, but would make it much easier to do batch processing of users and minimize DB overhead. For example, when sending out a newsletter you need to query each and every profile individually.
4. Add some standard profile fields to MembershipUser
Many of the personalization scenarios feature a first name and a last name. Currently you can use Profile to store this data but it would be easier if these two fields were available to the user as well, solving a large percentage of the personalization needs, removing the need for Profile in these cases.
5. Make Profile available to WAP as well
Currently, it's possible to use Profile in a WAP but it requires some manual work, or a (custom) build task creating the necessary code for you. (http://code.msdn.microsoft.com/WebProfileBuilder)
I’m sure there’s more. Will post a follow up if the come to mind…
Jorge Pedraza commented
Hi, suggestion important related (membership,profiles,roles,etc.) is do more friendly the permission configuration in controls of an Web Form. eg 3 button in Web Form can be viewed by some roles and others not.
purpose of this es get more productivity.
Peter Kellner commented
Should be IoC and test friendly as SteveS says above. Also, should have an easy extension point to link to other tables when using relational database as data store. That is, Profile providers are good for demo's and user theme's IMHO, but that's about it and they are also unfriendly towards WAP.
Ben Scheirman commented
The current Role & Membership API is very thread-unfriendly. If you want to use a single system to house the roles & memberships for multiple sites, you have to put a thread lock around the Application property.
All of the methods take parameters for their context, except Application is assumed to be static.
Steve Smith commented
The providers should be IoC and Unit Test friendly. To that end, they should have interfaces and other extension points that make it possible to assert various user conditions without an HttpContext, for example.
Could you provide more details on what exactly is out-dated and what you'd like to see in the new providers? What problems are you running into?
Dave Savage commented
Native support for Azure Table Storage would be awesome.
Michael Paterson commented
I love the provider functionality but CANNOT STAND the implementations.
Membership provider must support Guid UserId and BigInt UserId.