15 comments

Add a comment…

Sign in

prestine

Your email address

Check!

invalid email

(thinking…)

Reset

or sign in with

• 
• 

UserVoice password

Forgot password?

Create a password

Your name

I agree to the terms of service

Signed in as (Sign out)

Close

Close

Post comment Submitting...

• Wayne Brantley commented  ·  August 20, 2012 10:05 p.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  Open source the new universal providers.

• Flávio Oliveira commented  ·  July 27, 2012 8:22 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  interesting if membership could have a OAuth mechanism to interact with facebook or twitter...

• Mehrdad commented  ·  May 6, 2012 12:16 p.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  It is cumbersome to use it with ORM based solutions such as nhibernate.

• Emil commented  ·  December 10, 2011 3:49 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  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  ·  October 10, 2010 4:11 p.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  Id based providers instead of name based ones would be extremely helpful.

• Eugene Agafonov commented  ·  March 3, 2010 7:35 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  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  ·  February 23, 2010 8:02 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  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  ·  February 22, 2010 1:14 p.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  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.

  greetings.

• Peter Kellner commented  ·  February 22, 2010 11:13 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  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  ·  February 22, 2010 9:57 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  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  ·  February 22, 2010 9:25 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  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.

• haacked commented  ·  February 22, 2010 9:09 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  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  ·  February 18, 2010 10:28 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  Native support for Azure Table Storage would be awesome.

• Michael Paterson commented  ·  February 18, 2010 10:10 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  I love the provider functionality but CANNOT STAND the implementations.

• Powerz commented  ·  February 18, 2010 5:42 a.m.  ·  Flag as inappropriateFlag as inappropriate  ·  Delete

  Membership provider must support Guid UserId and BigInt UserId.