Re: ASP.NET 2.0 Membership Provider Customization



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" wrote:

> 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" wrote:
>
> > 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
> >
> > "Dominick Baier [DevelopMentor]" wrote:
> >
> > > 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...
> > >
> > > ---------------------------------------
> > > Dominick Baier - DevelopMentor
> > > http://www.leastprivilege.com
> > >
> > > > 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]" wrote:
> > > >
> > > >> 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...?
> > > >>
> > > >> ---------------------------------------
> > > >> Dominick Baier - DevelopMentor
> > > >> http://www.leastprivilege.com
> > > >>> 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.
> > > >>>
> > >
> > >
> > >
.