Membership provider to use or not to use?

Question

I am developing a website that uses Facebook. Now for managing users I thought of using MembershipProvider and chose to develop a custom membership provider. My problem is that my database schema doesn't match the standard membership schema and the functions provided to override take different arguments than I expect. For example, membership uses username as a username to log in. But I have to use user email ID as the username. Also its searching functions are based on using username as a way to search but I want it to search by UserID. Same Goes for User insertion, deletion, modification.

While adding new user I also want to save user's facebook related data... like UID and access token.

Edit

Its just an idea, would it be feasible to forcefully pass my values in the arguments and then handle them in my code?

Update

I found that there is a object providerUserKey argument in the Create user method. In the MSDN documentation I found that it is used to pass a unique key like a GUID for each new row. But in my db I already have provisions for UID of new row. So should I use this extra parameter to pass my Custom data as object through this argument and handle it there in my custom provider code.

Greenes

Answer 1

If the choice is between rolling your own authentication/login or going with Membership and coding a mapping layer then I would definitely go with the later, you can always build on what Membership offers you, if not through the API then with the DB tables directly.

Inevitably you will get authentication wrong and pay the price later if you roll your own.

As an alternative you might want to look into OpenID authentication, i.e. see this SO thread: OpenID authentication in ASP.NET?

EDIT:

I don't think you need a custom Membership provider. In a project I have done in the past, we had our own user management before we integrated with ASP.NET Membership. Besides adding the SQL membership tables to our DB all we had to do is provide a mapping between our users (which had a regular bigint as key at the time) and the Membership user GUID. With this sort of mapping you could also save all your facebook related data (just a FK relationship with Membership user)

Other than that I do think Membership already allows logging in using an email address, so I don't think you will run into too much trouble there.

Philodendron

@Shekhar_Pro: What's done can be undone. What makes you think you're stuck with what you've already done? – Sacchariferous

well thanx for your opinion , but do you have to say any thing about about object provider key,as a workaround...I just want some custom data to be passed with other Usual data... i will handle the rest in my code. In any way i am the one who will call the methods of membership class (not using wizards etc) is it good thing to do.. – Greenes

@Jon-Skeet See the scheme is this.. i am using facebook connect so the user name will be as that in facebook, now in facebook user names are not unique insted user email and his Uid is what we have unique way of identifying user. more over i dont wanna show a signup window to fill fields.. i fetch them myself (That's what FBConnect is for). And ssign a UserId for my website too and then create user. Even facebook uses email id as user name to log in. Now what to do and what to change... – Greenes

@Greenes ~ I agree with JonSkeet on this one, it's hardly ever considered unacceptable to scrap bad code and start over with new code once you've learned something new. Now, if you feel you haven't learned anything on this topic, then that's fine. But don't be afraid to start over. – Personate

@Shekhar: Since you are going to create users using API call, it doesn't matter if you pass email or anything else in your username field. And yes, providerkey is fine as well to access and since username is also unique I am not sure why you think it's going to cause an issue. Check this to store additional user data: asp.net/security/tutorials/… – Authorized