SqlMembershipProvider vs. transactions!

Discussion in 'ASP .Net Security' started by mehdi, Dec 2, 2006.

  1. mehdi

    mehdi Guest

    Hi folks,
    I've been asking some ASP.NET Membership questions here and there for
    the past 8 days (or so) over and over again. But surprisingly, it seems
    that no one takes the Membership/role providers seriously - AFAIK. I've
    been in a fog for the past week, unfortunately. This is my last try to
    solve the real-world problem I've been faced with when using the
    ASP.NET Membership APIs or whatever they are called.

    In a real-world applications, having a single UserName/Password pair in
    a persistent storage (being SQLServer, Active Directory and the like)
    doesn't suffice. It is in one way or another, related to some other
    entities. For example, in a financial application, it's probably
    related to an Employee account where each employee has got one and only
    one UserName/Password assigned. Therefore, we will have another entity
    to manage (besides the membership information), in this scenario,
    Employee accounts.

    An employee should never be inserted into the persistent layer if and
    only if it's counterpart entity (membership info) is also added to the
    persistent layer! i.e., either both or neither! This simply implies
    that we need to do things under a given transaction.

    However, there's no way to ask a Membership provider to do things
    (CreateUser, for instance) under a given transaction and therefore we
    cannot keep the integrity of the whole system. Unfortunately, the
    Membership methods are all declared as static, therefore, developing a
    new SqlMembershipProvider class is not enough since there's no way to
    pass the Transaction object to the above-mentioned class.

    Any help and/or idea to solve the issue would be highly appreciated,

    Thank you for your time,
    Mehdi
    mehdi, Dec 2, 2006
    #1
    1. Advertising

  2. well - you can do somehting like this:

    using (TransactionScope ts = new TransactionScope())
    {
    Membership.CreateUser(..);
    DoSomethingElse(..)

    ts.Complete();
    }


    The Membership class methods are static - not the actual provider. If you
    need more advanced functionality, then membership is not designed for that
    and you have to write a good old class that does your user-management. If
    you need membership because you want to share the implementation between
    several other technologies (SharePoint, WCF) - then you have to live with
    the interface it provides or find whacky ways to pass more data into it (which
    work in one environment or another and kind of defeats the purpose).



    -----
    Dominick Baier (http://www.leastprivilege.com)

    > Hi folks,
    > I've been asking some ASP.NET Membership questions here and there for
    > the past 8 days (or so) over and over again. But surprisingly, it
    > seems
    > that no one takes the Membership/role providers seriously - AFAIK.
    > I've
    > been in a fog for the past week, unfortunately. This is my last try to
    > solve the real-world problem I've been faced with when using the
    > ASP.NET Membership APIs or whatever they are called.
    > In a real-world applications, having a single UserName/Password pair
    > in a persistent storage (being SQLServer, Active Directory and the
    > like) doesn't suffice. It is in one way or another, related to some
    > other entities. For example, in a financial application, it's probably
    > related to an Employee account where each employee has got one and
    > only one UserName/Password assigned. Therefore, we will have another
    > entity to manage (besides the membership information), in this
    > scenario, Employee accounts.
    >
    > An employee should never be inserted into the persistent layer if and
    > only if it's counterpart entity (membership info) is also added to the
    > persistent layer! i.e., either both or neither! This simply implies
    > that we need to do things under a given transaction.
    >
    > However, there's no way to ask a Membership provider to do things
    > (CreateUser, for instance) under a given transaction and therefore we
    > cannot keep the integrity of the whole system. Unfortunately, the
    > Membership methods are all declared as static, therefore, developing a
    > new SqlMembershipProvider class is not enough since there's no way to
    > pass the Transaction object to the above-mentioned class.
    >
    > Any help and/or idea to solve the issue would be highly appreciated,
    >
    > Thank you for your time,
    > Mehdi
    Dominick Baier, Dec 2, 2006
    #2
    1. Advertising

  3. mehdi

    mehdi Guest

    Well, thank you for being straight! The following call will end up in
    MSDTC, although both connections point to the same SQL Server instance.
    Right?

    The other question is that whether the "MSDTC" is available on "Windows
    XP Home Edition"?

    TIA,
    Mehdi

    Dominick Baier wrote:
    > well - you can do somehting like this:
    >
    > using (TransactionScope ts = new TransactionScope())
    > {
    > Membership.CreateUser(..);
    > DoSomethingElse(..)
    >
    > ts.Complete();
    > }
    >
    >
    > The Membership class methods are static - not the actual provider. If you
    > need more advanced functionality, then membership is not designed for that
    > and you have to write a good old class that does your user-management. If
    > you need membership because you want to share the implementation between
    > several other technologies (SharePoint, WCF) - then you have to live with
    > the interface it provides or find whacky ways to pass more data into it (which
    > work in one environment or another and kind of defeats the purpose).
    >
    >
    >
    > -----
    > Dominick Baier (http://www.leastprivilege.com)
    >
    > > Hi folks,
    > > I've been asking some ASP.NET Membership questions here and there for
    > > the past 8 days (or so) over and over again. But surprisingly, it
    > > seems
    > > that no one takes the Membership/role providers seriously - AFAIK.
    > > I've
    > > been in a fog for the past week, unfortunately. This is my last try to
    > > solve the real-world problem I've been faced with when using the
    > > ASP.NET Membership APIs or whatever they are called.
    > > In a real-world applications, having a single UserName/Password pair
    > > in a persistent storage (being SQLServer, Active Directory and the
    > > like) doesn't suffice. It is in one way or another, related to some
    > > other entities. For example, in a financial application, it's probably
    > > related to an Employee account where each employee has got one and
    > > only one UserName/Password assigned. Therefore, we will have another
    > > entity to manage (besides the membership information), in this
    > > scenario, Employee accounts.
    > >
    > > An employee should never be inserted into the persistent layer if and
    > > only if it's counterpart entity (membership info) is also added to the
    > > persistent layer! i.e., either both or neither! This simply implies
    > > that we need to do things under a given transaction.
    > >
    > > However, there's no way to ask a Membership provider to do things
    > > (CreateUser, for instance) under a given transaction and therefore we
    > > cannot keep the integrity of the whole system. Unfortunately, the
    > > Membership methods are all declared as static, therefore, developing a
    > > new SqlMembershipProvider class is not enough since there's no way to
    > > pass the Transaction object to the above-mentioned class.
    > >
    > > Any help and/or idea to solve the issue would be highly appreciated,
    > >
    > > Thank you for your time,
    > > Mehdi
    mehdi, Dec 2, 2006
    #3
  4. right - it will promote to DTC - so the same thing we have been doing for
    years ;)

    I have no idea if DTC is available on Home Edition - but i assume.
    -----
    Dominick Baier (http://www.leastprivilege.com)

    > Well, thank you for being straight! The following call will end up in
    > MSDTC, although both connections point to the same SQL Server
    > instance. Right?
    >
    > The other question is that whether the "MSDTC" is available on
    > "Windows XP Home Edition"?
    >
    > TIA,
    > Mehdi
    > Dominick Baier wrote:
    >
    >> well - you can do somehting like this:
    >>
    >> using (TransactionScope ts = new TransactionScope())
    >> {
    >> Membership.CreateUser(..);
    >> DoSomethingElse(..)
    >> ts.Complete();
    >> }
    >> The Membership class methods are static - not the actual provider. If
    >> you
    >> need more advanced functionality, then membership is not designed for
    >> that
    >> and you have to write a good old class that does your
    >> user-management. If
    >> you need membership because you want to share the implementation
    >> between
    >> several other technologies (SharePoint, WCF) - then you have to live
    >> with
    >> the interface it provides or find whacky ways to pass more data into
    >> it (which
    >> work in one environment or another and kind of defeats the purpose).
    >> -----
    >> Dominick Baier (http://www.leastprivilege.com)
    >>> Hi folks,
    >>> I've been asking some ASP.NET Membership questions here and there
    >>> for
    >>> the past 8 days (or so) over and over again. But surprisingly, it
    >>> seems
    >>> that no one takes the Membership/role providers seriously - AFAIK.
    >>> I've
    >>> been in a fog for the past week, unfortunately. This is my last try
    >>> to
    >>> solve the real-world problem I've been faced with when using the
    >>> ASP.NET Membership APIs or whatever they are called.
    >>> In a real-world applications, having a single UserName/Password pair
    >>> in a persistent storage (being SQLServer, Active Directory and the
    >>> like) doesn't suffice. It is in one way or another, related to some
    >>> other entities. For example, in a financial application, it's
    >>> probably
    >>> related to an Employee account where each employee has got one and
    >>> only one UserName/Password assigned. Therefore, we will have another
    >>> entity to manage (besides the membership information), in this
    >>> scenario, Employee accounts.
    >>> An employee should never be inserted into the persistent layer if
    >>> and only if it's counterpart entity (membership info) is also added
    >>> to the persistent layer! i.e., either both or neither! This simply
    >>> implies that we need to do things under a given transaction.
    >>>
    >>> However, there's no way to ask a Membership provider to do things
    >>> (CreateUser, for instance) under a given transaction and therefore
    >>> we cannot keep the integrity of the whole system. Unfortunately, the
    >>> Membership methods are all declared as static, therefore, developing
    >>> a new SqlMembershipProvider class is not enough since there's no way
    >>> to pass the Transaction object to the above-mentioned class.
    >>>
    >>> Any help and/or idea to solve the issue would be highly appreciated,
    >>>
    >>> Thank you for your time,
    >>> Mehdi
    Dominick Baier, Dec 3, 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. ibiza
    Replies:
    0
    Views:
    440
    ibiza
    Jan 24, 2006
  2. Replies:
    3
    Views:
    534
    =?Utf-8?B?UGV0ZXIgQnJvbWJlcmcgW0MjIE1WUF0=?=
    Mar 5, 2006
  3. Mwob
    Replies:
    0
    Views:
    677
  4. Ryan

    SQLMembershipProvider

    Ryan, Jan 18, 2007, in forum: ASP .Net
    Replies:
    3
    Views:
    694
    sticky
    Jan 29, 2007
  5. Glenn
    Replies:
    0
    Views:
    602
    Glenn
    Jun 21, 2007
Loading...

Share This Page