Do I need a custom Membership Provider class?

Question

I do not need the Roles stuff. I have only a user with those properties:

Id
Firstname
Last name
Institute
Street
City
Postal
Country
Email
Password
IsCustomer
IsAdmin

When the user log into his account instead of doing:

if (Membership.ValidateUser(model.UserName, model.Password))

I would just call my

if (UserRepository.ValidateUser(model.UserName, model.Password))

and if valid the user exists I still differentiate between IsAdmin or not.

If IsAdmin I redirect to the adminpage or the customer area.

So do I really need all that Membership provider stuff?

score 0 · Answer 1 · answered Dec 27 '11 at 16:08

look here

If a valid, non-expired authentication ticket is found, the FormsAuthenticationModule decodes it to ascertain the requestor’s identity. It creates a new GenericPrincipal object and assigns this to the HttpContext.User object. The purpose of a principal, like GenericPrincipal, is to identify the authenticated user’s name and what roles she belong to.

So, if you will need to work with current user
(i.e. <asp:LoginView ID="LoginView1" runat="server">
or string user = System.Web.HttpContext.Current.User.Identity.Name;
or <authorization> <deny users="*"/> <allow roles="Administrator"/> </authorization> )

you should implement your custom membership provider .

you ask why use membership stuff, I answer some possible reasons. you ask for MVC sample code, I suggest a link with use of Current User in MVC. If you don't need to know Current User or work with Role or use you can avoid implement custom Membership — Emanuele Greco, Dec 29 '11 at 08:33

Emmanuel N · Answer 2 · 2011-12-27T16:27:07.690

0

Yes you need a custome membership provider. On how to create it,there is this article on Code Project you can use as reference

edited Dec 27 '11 at 16:27

answered Dec 27 '11 at 16:11

Emmanuel N

7,350
2
26
36

I have no trouble implementing such a provider. My question was related to the WHY a custom member provider and wether I need it in my situation. Thanks for the link but google is also my friend. – Elisabeth Dec 27 '11 at 16:26
1

Memership provider is mainly to help your application to retrieve user data. Because the user data in your model is different from the default user data, you will need to create a custom membership provider. Its always better to extend or use well proven solution rather than inventing your own solution. – Emmanuel N Dec 27 '11 at 16:37
Generally speaken thats true. But in this case nothing is proven. All the business logic is in the MembershipProvider. Mine could be different and is indeed different. Thus I need a proven solution for my case and that one does not exist so I have to code it. I do not need Roles/Profile stuff. Why carry all that stuff with me? – Elisabeth Dec 27 '11 at 17:01
You need profile and roles. IsAdmin and IsCustomer are roles and all other information you have for your user object is user profile – Emmanuel N Dec 27 '11 at 17:09
IsAdmin and IsCustomer are properties of my User entity so they can not be roles. – Elisabeth Dec 27 '11 at 18:35
They are properties but storage wise/database it make more sense to store theme as roles. – Emmanuel N Dec 27 '11 at 18:53
a flag like IsMarried, IsMale, IsWhatever belongs to a user. There is no need to introduce complexity by saying IsAdmin belong to a role concerning database design. A user can be admin or not point! Just KISS! http://en.wikipedia.org/wiki/KISS_principle – Elisabeth Dec 28 '11 at 17:18
You can still have your property in user object and roles in storage. You can use your property get and set to transit between the two. `public bool IsAdmin{ get { return Roles.IsUserInRole("Admin"); } }`. Your design is simple but what if you want to add more roles? – Emmanuel N Dec 28 '11 at 17:28

score 0 · Answer 3 · answered Dec 27 '11 at 20:04

At the end of the day you can use either of these approaches. I have used used the out of the box asp.net membership provider and stored additional data in a different table with the aspnet_userId as a FK. In other occasions, where I needed more integration of user object with the rest of my domain model, I have used custom MembershipProviders. Since the source for the out of the box providers is now available, it is actually not so difficult/involved to implement your own. In fact, it is not so uncommon based on my experience.

Yes, if you use the built in membership provider, there is some slight overhead involved. However, if you are beginning with asp.net I would recommend that you stick to the built in asp.net membership provider.

BTW, you mention:

I don't need the Roles stuff

Oh yes, you do! At the moment you are limiting yourself to one role: IsAdmin. If you ever down the road need to support additional roles, your proposed implementation will become a problem. There was a lot of thought/experience in designing the asp.net membershipProviders. The price you pay for using them is negligible, you basically loose nothing, and have potentially a lot to gain.

I do not limit myself. My requirements are for a very small business site. I am admin the rest are customers point! — Elisabeth, Dec 28 '11 at 17:16

Do I need a custom Membership Provider class?

3 Answers3