3

Is it possible to create a custom MembershipProvider without the use of the MembershipUser class?

I'd like to use my own User class and to keep things tidy, I'd like to not have to use the MembershipUser class which has a lot of properties I really don't want or need.

abatishchev
  • 98,240
  • 88
  • 296
  • 433
Johan Alkstål
  • 5,225
  • 9
  • 36
  • 48

4 Answers4

4

No it's not. But you can always write your own abstraction on top of it using a Repository pattern or similar, and then use your own User model in the application.

public UserRepository : IUserRepository
{
   private MembershipProvider provider;
   private UserAdapter userAdapter;

   public UserService(MembershipProvider provider, UserAdapter userAdapter)
   {
       this.provider = provider;
       this.userAdapter = userAdapter;
   }

   public MyUser GetUser(string email)
   {
       MembershipUser user = provider.GetUser(username, false);
       MyUser myUser= userAdapter.Map(user);
       return myUser;
   }
}
TheCodeKing
  • 19,064
  • 3
  • 47
  • 70
  • Thanks for the example. While I've decided to not use the ASP.NET membership structure, you answer my question "Is it possible to create a custom MembershipProvider without the use of the MembershipUser class?" – Johan Alkstål Sep 02 '11 at 06:01
  • @JohanVauhkonen Got the same problem and i think the easiest solution is to create our own system. You can easily reproduce the behavior of the membership provider but will require a bit of work. – Rushino Dec 05 '11 at 18:05
1

If you really want to build-in your provider in ASP.NET Membership infrastructure, you should.

Membership.Provider returns abstract MembershipProvider also containing:

public abstract MembershipUser CreateUser(..);
public abstract MembershipUser GetUser(..);

and other methods returning MembershipUser class.

abatishchev
  • 98,240
  • 88
  • 296
  • 433
  • Thank you and I already knew about implementing the abstract MembershipProvider. What I was interested in learning was if it's possibel to omit MembershipUser and use something else together with the Membership infrastructure. Clearly it's not. – Johan Alkstål Sep 02 '11 at 06:03
0

this is my solution

customerUser.cs

public class DZMembership
{
    public virtual Guid Id { get; set; }
    public virtual string UserName { get; set; }
    public virtual string Password { get; set; }
    public virtual DateTime TimeCreated { get; set; }

}

customerProvider.cs

 public class DZMembershipProvider : MembershipProvider
{

    IDALMembership dal = DalFactory.GetDalMembership();
    #region override of membership provider
    public override string ApplicationName
    {
        get
        {
            throw new NotImplementedException();
        }
        set
        {
            throw new NotImplementedException();
        }
    }

    public override bool ChangePassword(string username, string oldPassword, string newPassword)
    {
        DZMembership member = dal.GetMemberByName(username);
        string encryptedOldPsw =  FormsAuthentication.HashPasswordForStoringInConfigFile(oldPassword, "MD5");
        string encryptedNewPsw = FormsAuthentication.HashPasswordForStoringInConfigFile(newPassword, "MD5");
        if (member.Password != encryptedOldPsw) return false;
        member.Password = encryptedNewPsw;
        dal.ChangePassword(member);
        return true;
    }
public override MembershipUser GetUser(string username, bool userIsOnline)
    {

        DZMembership user = dal.GetMemberByName(username);
        if (user == null) return null;
        MembershipUser mu = new MembershipUser("DZMembershipProvider",
             username, user.Id, "", "", string.Empty,
             true, true, DateTime.Now,
             DateTime.Now, DateTime.Now, DateTime.Now, DateTime.Now);
        return mu;

    }

when the method need returning a MembershipUser type, build a new one with your customer user's infomation . in most case, it will be fine. because the build-in Controls(login, loginstatus.) doesn't need more than those. but i sugguest custom your ownuser by inheriting the MembershipUser,the additional properties will not bite you ,but the lackness will.

phiree
  • 409
  • 6
  • 15
0

You can create a custom memembership provider without using/inheriting from the membership user depending upon your usage. If you are not using the built in createuser method (the user is created in another source system), then you really don't need the membership user object. Otherwise, just create another object that inherits from membershipuser with your extra properties.

Alex J
  • 1,547
  • 2
  • 26
  • 41
  • you mean Membership User? i was saying not to inherit Membership user not provider. I see how my wordings can be a little confusing. I meant use a custom membership provider, but not really use a membership user object if you don't have to. – Alex J Sep 01 '11 at 19:53