ASP.NET Membership - Changing the contract

Discussion in 'ASP .Net Security' started by Mr.Underhill, Jan 25, 2006.

  1. Mr.Underhill

    Mr.Underhill Guest

    I want to create a custom provider, that is going to work with an existing
    database (I'm not going to use the aspnetdb). I'm going to need to provide
    additional fields in the creation of a new user account, new fields for
    changing password and also new fields for the login.

    Let's take the MembershipUser as a sample, I know that I would need to
    inherit from MembershipUser and add my custom fields, what's going to happen
    with the UserControls? How am I going to pass the new fields to my new
    extended object?

    The reason of using the Membership is because I have the feeling that there
    is "collaboration" with other new features in VS2005, if I don't use the
    Membership, I feel that I'm going to loose more than just the Membership. To
    make an educated decision, anybody knows what are the "links" between the
    Membership and other features in VS2005, if any?

    Any good advice to approach my problem besides create my own? I'm also
    willing to create my own UI layer and just implement the Provider, but wish
    there is a way to reuse the existing Membership UserControls as much as I can
    if it makes sense.


    Thanks
     
    Mr.Underhill, Jan 25, 2006
    #1
    1. Advertising

  2. Hi,

    i don't know about which "links" you are talking.

    If neither the provider interface nor the controls fit your needs - why do
    you want to use the provider pattern - it will be more work teaching the
    provider your new tricks than writing your own authentication/user mgmt library
    - you have to do that anyways if you write a provider.

    my 2c

    ---------------------------------------
    Dominick Baier - DevelopMentor
    http://www.leastprivilege.com

    > I want to create a custom provider, that is going to work with an
    > existing database (I'm not going to use the aspnetdb). I'm going to
    > need to provide additional fields in the creation of a new user
    > account, new fields for changing password and also new fields for the
    > login.
    >
    > Let's take the MembershipUser as a sample, I know that I would need to
    > inherit from MembershipUser and add my custom fields, what's going to
    > happen with the UserControls? How am I going to pass the new fields
    > to my new extended object?
    >
    > The reason of using the Membership is because I have the feeling that
    > there is "collaboration" with other new features in VS2005, if I don't
    > use the Membership, I feel that I'm going to loose more than just the
    > Membership. To make an educated decision, anybody knows what are the
    > "links" between the Membership and other features in VS2005, if any?
    >
    > Any good advice to approach my problem besides create my own? I'm
    > also willing to create my own UI layer and just implement the
    > Provider, but wish there is a way to reuse the existing Membership
    > UserControls as much as I can if it makes sense.
    >
    > Thanks
    >
     
    Dominick Baier [DevelopMentor], Jan 25, 2006
    #2
    1. Advertising

  3. Mr.Underhill

    Mr.Underhill Guest

    The "links" I'm referring to are posible collaboration between the Membership
    and other features of VS2005 that might be interesting to maintain. I don't
    know if there is any feature in VS2005 that utilizes the Membership API under
    the covers, if there is any, I'll like to know it.

    For example, if you use the Profile feature, then, there is functionality
    that you can use with Binding, if you decide to implement Profile type
    functionality yourself with your own objects, then you lose that
    functionality in the Binding side. This is just an example, I wonder if
    there are features like that in VS2005 that I'm going to lose if I create my
    own Authentication/User mgmt library. Please advise.

    If there is nothing to lose besides the Membership itselft, I'll rather do
    my own.

    Thanks




    "Dominick Baier [DevelopMentor]" wrote:

    > Hi,
    >
    > i don't know about which "links" you are talking.
    >
    > If neither the provider interface nor the controls fit your needs - why do
    > you want to use the provider pattern - it will be more work teaching the
    > provider your new tricks than writing your own authentication/user mgmt library
    > - you have to do that anyways if you write a provider.
    >
    > my 2c
    >
    > ---------------------------------------
    > Dominick Baier - DevelopMentor
    > http://www.leastprivilege.com
    >
    > > I want to create a custom provider, that is going to work with an
    > > existing database (I'm not going to use the aspnetdb). I'm going to
    > > need to provide additional fields in the creation of a new user
    > > account, new fields for changing password and also new fields for the
    > > login.
    > >
    > > Let's take the MembershipUser as a sample, I know that I would need to
    > > inherit from MembershipUser and add my custom fields, what's going to
    > > happen with the UserControls? How am I going to pass the new fields
    > > to my new extended object?
    > >
    > > The reason of using the Membership is because I have the feeling that
    > > there is "collaboration" with other new features in VS2005, if I don't
    > > use the Membership, I feel that I'm going to loose more than just the
    > > Membership. To make an educated decision, anybody knows what are the
    > > "links" between the Membership and other features in VS2005, if any?
    > >
    > > Any good advice to approach my problem besides create my own? I'm
    > > also willing to create my own UI layer and just implement the
    > > Provider, but wish there is a way to reuse the existing Membership
    > > UserControls as much as I can if it makes sense.
    > >
    > > Thanks
    > >

    >
    >
    >
     
    Mr.Underhill, Jan 25, 2006
    #3
  4. Hi,

    there are no such links - also for profile - you will not lose the profile
    functionality - you may need your own provider - but thats another story.

    ---------------------------------------
    Dominick Baier - DevelopMentor
    http://www.leastprivilege.com

    > The "links" I'm referring to are posible collaboration between the
    > Membership and other features of VS2005 that might be interesting to
    > maintain. I don't know if there is any feature in VS2005 that
    > utilizes the Membership API under the covers, if there is any, I'll
    > like to know it.
    >
    > For example, if you use the Profile feature, then, there is
    > functionality that you can use with Binding, if you decide to
    > implement Profile type functionality yourself with your own objects,
    > then you lose that functionality in the Binding side. This is just an
    > example, I wonder if there are features like that in VS2005 that I'm
    > going to lose if I create my own Authentication/User mgmt library.
    > Please advise.
    >
    > If there is nothing to lose besides the Membership itselft, I'll
    > rather do my own.
    >
    > Thanks
    >
    > "Dominick Baier [DevelopMentor]" wrote:
    >
    >> Hi,
    >>
    >> i don't know about which "links" you are talking.
    >>
    >> If neither the provider interface nor the controls fit your needs -
    >> why do you want to use the provider pattern - it will be more work
    >> teaching the provider your new tricks than writing your own
    >> authentication/user mgmt library - you have to do that anyways if you
    >> write a provider.
    >>
    >> my 2c
    >>
    >> ---------------------------------------
    >> Dominick Baier - DevelopMentor
    >> http://www.leastprivilege.com
    >>> I want to create a custom provider, that is going to work with an
    >>> existing database (I'm not going to use the aspnetdb). I'm going to
    >>> need to provide additional fields in the creation of a new user
    >>> account, new fields for changing password and also new fields for
    >>> the login.
    >>>
    >>> Let's take the MembershipUser as a sample, I know that I would need
    >>> to inherit from MembershipUser and add my custom fields, what's
    >>> going to happen with the UserControls? How am I going to pass the
    >>> new fields to my new extended object?
    >>>
    >>> The reason of using the Membership is because I have the feeling
    >>> that there is "collaboration" with other new features in VS2005, if
    >>> I don't use the Membership, I feel that I'm going to loose more than
    >>> just the Membership. To make an educated decision, anybody knows
    >>> what are the "links" between the Membership and other features in
    >>> VS2005, if any?
    >>>
    >>> Any good advice to approach my problem besides create my own? I'm
    >>> also willing to create my own UI layer and just implement the
    >>> Provider, but wish there is a way to reuse the existing Membership
    >>> UserControls as much as I can if it makes sense.
    >>>
    >>> Thanks
    >>>
     
    Dominick Baier [DevelopMentor], Jan 25, 2006
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    6
    Views:
    768
  2. Stanley Braverman

    contract for name changing program

    Stanley Braverman, Sep 12, 2004, in forum: C++
    Replies:
    2
    Views:
    301
    Brian Keener
    Sep 13, 2004
  3. Specialist Verilog Engineers Roles
    Replies:
    0
    Views:
    490
    Specialist Verilog Engineers Roles
    Jun 27, 2007
  4. Paul
    Replies:
    1
    Views:
    334
    sloan
    Nov 29, 2007
  5. Tino Donderwinkel
    Replies:
    2
    Views:
    819
    Tino Donderwinkel
    Jun 18, 2008
Loading...

Share This Page