ASP.NET 2.0 Membership Provider Customization

[Oldman]

I think I know the answer to this but I want to make sure before I take the
plunge of implementing my own MembershipProvider.

All I want is a few extra fields to be stored along with the user
information. I really would like to avoid implementing a whole membership
provider just for a few extra fields for the user.

Is there an easier way of extending the User Fields?

Thanks.

 

[Dominick Baier [DevelopMentor]]

Hello Oldman,

to be honest, membership is not really designed to do this...

you can "hack" your way through -

a) derive from SqlMembership
b) override create, update, delete etc user
c) you have to somehow transport your "extra info" to create user - there
is no clean way of doing this - you could set Context.Items before you call
membership
d) create a extra table thats hold your info
e) create a relationship with the membership table (using userid)
f) create a transaction over base.CreateUser and your sql to insert the info

etc..

why not create your own tailored user management library which does _exactly_
what you want instead of trying to teach the membership provider new tricks...?

 

[Oldman]

After rereading your post. Let me say what the approach is for doing it with
Membership.

When you call the CreateUser Method it returns a MembershipUser. This can
be any class derived from MembershipUser. This class would have the extra
fields in it.
The caller of CreateUser could then set the extra info and call UpdateUser.
Then my own membership provider stores the info.
This is how it is recommended to extend the interface.

However, I don't want to rewrite all the code for the Password salting,
question/answer storing. This is already all done for me with the
SqlMembershipProvider. I want to just extend the User to have more fields.
However, your answer does lead me to believe that my assumption was right
that I'll have to rewrite all the membershipprovider methods to get this to
work.

Thanks,

Oldman

 

[Dominick Baier [DevelopMentor]]

Hello Oldman,

as i said - there are several hurdles to take

a) how to transport the extra data to CreateUser if you are using the login
control
b) make the call to the "standard" table and the "extra data" table transactional
c) extend MembershipUser
d) keep all the data in sync in create, delete, update user

this is possible by deriving from SqlMembershipProvider

if you write your own provider you are facing the same problems - btw...

 

[Oldman]

Thanks for your response.

So my options are the following:

-- Write my own MembershipProvider that is derived from SqlMembershipProvider
-- Write my own MembershipProvider from scratch (Benefits include not having
the oddities of two tables for the user data and other coding oddities)
-- Write my own user managment/Roles classes and UI Components.

This is what I thought.

They really should have put some protected methods into the
SqlMembershipProvider that you could override to perform addtional work for
simple things like having more fields for a user.

Thanks again,

Oldman

 

[Fabuloussites]

why not store the extra informaton in the user profile? that's a quick way
to store info the the users, and there are lots of examples out there.

 

[Oldman]

I thought of that and tried that first. But based on how it is stored it
isn't easy or efficient to bring back a result set that looks like the
following:

userID FirstName LastName Email ...

Where UserID and Email come from the membership table and Firstname and
LastName comes from profile table. You would need to do some sort of
cross-tab query.

Chris

 

[Fabuloussites]

well, you can access the username/email like this:
dim user as membership user

username=user.username
email=user.email

and the profile info like this (with address and city defined in the
web.config file):

Dim Profiles as ProfileCommon

Profiles = Profile.GetProfile(user.Username)

address=profile.address
city=profile.city

 

[Oldman]

Thanks for your response.

I understand your point. But that doesn't help when I have a grid of a
bunch of users showing certain properties. The profile is good for getting
and displaying information about the user logged in but it isn't so good at
listing a bunch of users' information.

It is much simpler to query the database for the user information and be
able to get all the user's information in a single row.

 

[Fabuloussites]

Point well taken. you can use a similar method go get all of the info into a
list if
you just want to preview info using a templated field and a loop to make
datalist. but, would not be able to benefit from the benefits for the edit
capablities.

In my case, I only need to have the user edit the info themselves, or to
show a list for an administrator. So, that method was suitable. Like
yourself, i didn't want to have to write my own provider.

Happy coding!