Roles.IsUserInRole != Context.User.IsInRole

Discussion in 'ASP .Net Security' started by Lyndon Hills, Oct 20, 2006.

  1. Lyndon Hills

    Lyndon Hills Guest

    Hi,

    I'm hoping that someone might enlighten me as to how the Roles.IsUserInRole
    functionality works.

    I have my custom role provider set up and working, but realised that the
    caching wasn't working. When my c# code hit the line Roles.IsUserInRole I saw
    the identity property of my role principal being accessed and then, despite
    the roles being cached, the code goes off to establish if the user has the
    role from the role store.

    If I use Context.User.IsInRole the same thing happens but the role
    membership is established in the role principal from the cached roles.

    This is a web page where there is no impersonation -
    Context.Request.LogonUserIdentity.Name = the machine\IUSR account.
    Context.user.Identity.name = the login id supplied (via forms).
    Thread.CurrentPrincipal.Identity.Name is also the forms supplied user.

    Would I be right in thinking that Roles.IsUserInRole is looking for the
    roles of the context.LogonUserIdentity? Is there any way I persuade it to use
    Context.user.Identity.Name - without doing impersonation?

    Roles.IsUserInRole(Thread.CurrentPrincipal.Identity.Name, "TestRole")
    and
    Roles.IsUserInRole(Context.User.Identity.Name, "TestRole")

    also don't work, in that they don't use my cached roles they go back to the
    store, they do provide the correct result once that's done.

    This is part of a solution intended to handle windows/domain users, domain
    users not using windows/IE (primarily Apple) and non-domain users stored in
    ADAM.

    While it would be nice to be able to use the built in Roles functionality, I
    can live without it by using Context.User.IsInRole. I would like to know
    what I'm doing wrong in any case, or to properly understand why it doesn't
    work.

    Thanks for any assistance or explanation.

    Lyndon Hills
    Lyndon Hills, Oct 20, 2006
    #1
    1. Advertising

  2. Roles.IsUserInRole will directly call the roles provider which e.g. in the
    case of the SqlRoleProvider will do a database roundtrip.

    Context.User.IsInRole calls the RolePrincipal class. The caching is done
    in this class which calls Role.GetRolesForUser and then caches the list for
    subsequent calls.

    read also here:
    http://www.leastprivilege.com/RolePrincipalVsRoleProviderPrincipal.aspx


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

    > Hi,
    >
    > I'm hoping that someone might enlighten me as to how the
    > Roles.IsUserInRole functionality works.
    >
    > I have my custom role provider set up and working, but realised that
    > the caching wasn't working. When my c# code hit the line
    > Roles.IsUserInRole I saw the identity property of my role principal
    > being accessed and then, despite the roles being cached, the code goes
    > off to establish if the user has the role from the role store.
    >
    > If I use Context.User.IsInRole the same thing happens but the role
    > membership is established in the role principal from the cached roles.
    >
    > This is a web page where there is no impersonation -
    > Context.Request.LogonUserIdentity.Name = the machine\IUSR account.
    > Context.user.Identity.name = the login id supplied (via forms).
    > Thread.CurrentPrincipal.Identity.Name is also the forms supplied user.
    >
    > Would I be right in thinking that Roles.IsUserInRole is looking for
    > the roles of the context.LogonUserIdentity? Is there any way I
    > persuade it to use Context.user.Identity.Name - without doing
    > impersonation?
    >
    > Roles.IsUserInRole(Thread.CurrentPrincipal.Identity.Name, "TestRole")
    > and
    > Roles.IsUserInRole(Context.User.Identity.Name, "TestRole")
    > also don't work, in that they don't use my cached roles they go back
    > to the store, they do provide the correct result once that's done.
    >
    > This is part of a solution intended to handle windows/domain users,
    > domain users not using windows/IE (primarily Apple) and non-domain
    > users stored in ADAM.
    >
    > While it would be nice to be able to use the built in Roles
    > functionality, I can live without it by using Context.User.IsInRole.
    > I would like to know what I'm doing wrong in any case, or to properly
    > understand why it doesn't work.
    >
    > Thanks for any assistance or explanation.
    >
    > Lyndon Hills
    >
    Dominick Baier, Oct 20, 2006
    #2
    1. Advertising

  3. Lyndon Hills

    Lyndon Hills Guest

    Thanks for that.

    I don't quite see why Roles.IsUserInRole accesses my roleprincipal.identity,
    but it does make it clear how I should be coding in my pages. I don't think
    I've ever seen the distinction made this clearly before. It's probably in
    your (excellent) book somewhere, but I've only read the relevant bits twice,
    while trying to get this stuff straight in my head!

    Thanks again.
    Lyndon


    "Dominick Baier" wrote:

    > Roles.IsUserInRole will directly call the roles provider which e.g. in the
    > case of the SqlRoleProvider will do a database roundtrip.
    >
    > Context.User.IsInRole calls the RolePrincipal class. The caching is done
    > in this class which calls Role.GetRolesForUser and then caches the list for
    > subsequent calls.
    >
    > read also here:
    > http://www.leastprivilege.com/RolePrincipalVsRoleProviderPrincipal.aspx
    >
    >
    > ---
    > Dominick Baier, DevelopMentor
    > http://www.leastprivilege.com
    >
    > > Hi,
    > >
    > > I'm hoping that someone might enlighten me as to how the
    > > Roles.IsUserInRole functionality works.
    > >
    > > I have my custom role provider set up and working, but realised that
    > > the caching wasn't working. When my c# code hit the line
    > > Roles.IsUserInRole I saw the identity property of my role principal
    > > being accessed and then, despite the roles being cached, the code goes
    > > off to establish if the user has the role from the role store.
    > >
    > > If I use Context.User.IsInRole the same thing happens but the role
    > > membership is established in the role principal from the cached roles.
    > >
    > > This is a web page where there is no impersonation -
    > > Context.Request.LogonUserIdentity.Name = the machine\IUSR account.
    > > Context.user.Identity.name = the login id supplied (via forms).
    > > Thread.CurrentPrincipal.Identity.Name is also the forms supplied user.
    > >
    > > Would I be right in thinking that Roles.IsUserInRole is looking for
    > > the roles of the context.LogonUserIdentity? Is there any way I
    > > persuade it to use Context.user.Identity.Name - without doing
    > > impersonation?
    > >
    > > Roles.IsUserInRole(Thread.CurrentPrincipal.Identity.Name, "TestRole")
    > > and
    > > Roles.IsUserInRole(Context.User.Identity.Name, "TestRole")
    > > also don't work, in that they don't use my cached roles they go back
    > > to the store, they do provide the correct result once that's done.
    > >
    > > This is part of a solution intended to handle windows/domain users,
    > > domain users not using windows/IE (primarily Apple) and non-domain
    > > users stored in ADAM.
    > >
    > > While it would be nice to be able to use the built in Roles
    > > functionality, I can live without it by using Context.User.IsInRole.
    > > I would like to know what I'm doing wrong in any case, or to properly
    > > understand why it doesn't work.
    > >
    > > Thanks for any assistance or explanation.
    > >
    > > Lyndon Hills
    > >

    >
    >
    >
    Lyndon Hills, Oct 20, 2006
    #3
  4. thanks :)

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

    > Thanks for that.
    >
    > I don't quite see why Roles.IsUserInRole accesses my
    > roleprincipal.identity, but it does make it clear how I should be
    > coding in my pages. I don't think I've ever seen the distinction made
    > this clearly before. It's probably in your (excellent) book somewhere,
    > but I've only read the relevant bits twice, while trying to get this
    > stuff straight in my head!
    >
    > Thanks again.
    > Lyndon
    > "Dominick Baier" wrote:
    >
    >> Roles.IsUserInRole will directly call the roles provider which e.g.
    >> in the case of the SqlRoleProvider will do a database roundtrip.
    >>
    >> Context.User.IsInRole calls the RolePrincipal class. The caching is
    >> done in this class which calls Role.GetRolesForUser and then caches
    >> the list for subsequent calls.
    >>
    >> read also here:
    >> http://www.leastprivilege.com/RolePrincipalVsRoleProviderPrincipal.as
    >> px
    >> ---
    >> Dominick Baier, DevelopMentor
    >> http://www.leastprivilege.com
    >>> Hi,
    >>>
    >>> I'm hoping that someone might enlighten me as to how the
    >>> Roles.IsUserInRole functionality works.
    >>>
    >>> I have my custom role provider set up and working, but realised that
    >>> the caching wasn't working. When my c# code hit the line
    >>> Roles.IsUserInRole I saw the identity property of my role principal
    >>> being accessed and then, despite the roles being cached, the code
    >>> goes off to establish if the user has the role from the role store.
    >>>
    >>> If I use Context.User.IsInRole the same thing happens but the role
    >>> membership is established in the role principal from the cached
    >>> roles.
    >>>
    >>> This is a web page where there is no impersonation -
    >>> Context.Request.LogonUserIdentity.Name = the machine\IUSR account.
    >>> Context.user.Identity.name = the login id supplied (via forms).
    >>> Thread.CurrentPrincipal.Identity.Name is also the forms supplied
    >>> user.
    >>>
    >>> Would I be right in thinking that Roles.IsUserInRole is looking for
    >>> the roles of the context.LogonUserIdentity? Is there any way I
    >>> persuade it to use Context.user.Identity.Name - without doing
    >>> impersonation?
    >>>
    >>> Roles.IsUserInRole(Thread.CurrentPrincipal.Identity.Name,
    >>> "TestRole")
    >>> and
    >>> Roles.IsUserInRole(Context.User.Identity.Name, "TestRole")
    >>> also don't work, in that they don't use my cached roles they go back
    >>> to the store, they do provide the correct result once that's done.
    >>> This is part of a solution intended to handle windows/domain users,
    >>> domain users not using windows/IE (primarily Apple) and non-domain
    >>> users stored in ADAM.
    >>>
    >>> While it would be nice to be able to use the built in Roles
    >>> functionality, I can live without it by using Context.User.IsInRole.
    >>> I would like to know what I'm doing wrong in any case, or to
    >>> properly understand why it doesn't work.
    >>>
    >>> Thanks for any assistance or explanation.
    >>>
    >>> Lyndon Hills
    >>>
    Dominick Baier, Oct 20, 2006
    #4
  5. ah - and feel free to write a review on amazon if you like it :)

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

    > Thanks for that.
    >
    > I don't quite see why Roles.IsUserInRole accesses my
    > roleprincipal.identity, but it does make it clear how I should be
    > coding in my pages. I don't think I've ever seen the distinction made
    > this clearly before. It's probably in your (excellent) book somewhere,
    > but I've only read the relevant bits twice, while trying to get this
    > stuff straight in my head!
    >
    > Thanks again.
    > Lyndon
    > "Dominick Baier" wrote:
    >
    >> Roles.IsUserInRole will directly call the roles provider which e.g.
    >> in the case of the SqlRoleProvider will do a database roundtrip.
    >>
    >> Context.User.IsInRole calls the RolePrincipal class. The caching is
    >> done in this class which calls Role.GetRolesForUser and then caches
    >> the list for subsequent calls.
    >>
    >> read also here:
    >> http://www.leastprivilege.com/RolePrincipalVsRoleProviderPrincipal.as
    >> px
    >> ---
    >> Dominick Baier, DevelopMentor
    >> http://www.leastprivilege.com
    >>> Hi,
    >>>
    >>> I'm hoping that someone might enlighten me as to how the
    >>> Roles.IsUserInRole functionality works.
    >>>
    >>> I have my custom role provider set up and working, but realised that
    >>> the caching wasn't working. When my c# code hit the line
    >>> Roles.IsUserInRole I saw the identity property of my role principal
    >>> being accessed and then, despite the roles being cached, the code
    >>> goes off to establish if the user has the role from the role store.
    >>>
    >>> If I use Context.User.IsInRole the same thing happens but the role
    >>> membership is established in the role principal from the cached
    >>> roles.
    >>>
    >>> This is a web page where there is no impersonation -
    >>> Context.Request.LogonUserIdentity.Name = the machine\IUSR account.
    >>> Context.user.Identity.name = the login id supplied (via forms).
    >>> Thread.CurrentPrincipal.Identity.Name is also the forms supplied
    >>> user.
    >>>
    >>> Would I be right in thinking that Roles.IsUserInRole is looking for
    >>> the roles of the context.LogonUserIdentity? Is there any way I
    >>> persuade it to use Context.user.Identity.Name - without doing
    >>> impersonation?
    >>>
    >>> Roles.IsUserInRole(Thread.CurrentPrincipal.Identity.Name,
    >>> "TestRole")
    >>> and
    >>> Roles.IsUserInRole(Context.User.Identity.Name, "TestRole")
    >>> also don't work, in that they don't use my cached roles they go back
    >>> to the store, they do provide the correct result once that's done.
    >>> This is part of a solution intended to handle windows/domain users,
    >>> domain users not using windows/IE (primarily Apple) and non-domain
    >>> users stored in ADAM.
    >>>
    >>> While it would be nice to be able to use the built in Roles
    >>> functionality, I can live without it by using Context.User.IsInRole.
    >>> I would like to know what I'm doing wrong in any case, or to
    >>> properly understand why it doesn't work.
    >>>
    >>> Thanks for any assistance or explanation.
    >>>
    >>> Lyndon Hills
    >>>
    Dominick Baier, Oct 20, 2006
    #5
  6. Thanks for Dominick's informative inputs.

    Hi Lyndon,

    As for the difference between Roles.IsUserInRole and
    Context.User.IsInRole, it is due to the internal implementation of
    Roles.IsUserInRole method.

    As for "Context.User.IsInRole", it uses the Context.User class
    instance(when you enable role manager, it is an instance of RolePrincipal
    class), and this class will cache roles and the IsInRole method will search
    cached roles first.

    While for the "Roles" class, its "IsUserInRole" method has the following
    code logic:

    1) first check whether Thread.CurrentPrincipal is null, if not return this
    principal

    2) #1 != null, check whether the principal is of type "RolePrincipal" or
    derived type and whether the current principal's provider equals the
    configured provider, if match, the Thread.Principal object will be used for
    check roles,(and this is the same as Context.User.IsInRole).

    3) if #1 is null or #2 not match, it will use the underlying RoleProvider
    to query the roles from backend database storage(e.g. SQL Server...)
    instead of the RolePrincpal class


    Here is the disassemblied code of the "Roles.IsUserInRole" from reflector

    ===================
    ................
    IPrincipal principal1 = Roles.GetCurrentUser();
    if (((principal1 != null) && (principal1 is RolePrincipal)) &&
    ((((RolePrincipal) principal1).ProviderName == Roles.Provider.Name) &&
    StringUtil.EqualsIgnoreCase(username, principal1.Identity.Name)))
    {
    flag1 = principal1.IsInRole(roleName);
    }
    else
    {
    flag1 = Roles.Provider.IsUserInRole(username, roleName);
    }

    =====================

    I think for your scenario, you have writen your custom role provider, does
    it also use a custom Principal class(is it derived from RolePrincipal
    class)? I think this maybe the cause why you get different result.

    Anyway, if you have any further questions on this, please feel free to post
    here.

    Sincerely,

    Steven Cheng

    Microsoft MSDN Online Support Lead



    This posting is provided "AS IS" with no warranties, and confers no rights.
    Steven Cheng[MSFT], Oct 23, 2006
    #6
  7. Which Book is that..
    Very well interested i have been looking for a book Dominick and Joe.K were
    to release..
    I have been out of the forum for sometime but 'm back now :)
    Patrick

    "Dominick Baier" <dbaier@pleasepleasenospam_leastprivilege.com> wrote in
    message news:...
    > ah - and feel free to write a review on amazon if you like it :)
    >
    > ---
    > Dominick Baier, DevelopMentor
    > http://www.leastprivilege.com
    >
    >> Thanks for that.
    >>
    >> I don't quite see why Roles.IsUserInRole accesses my
    >> roleprincipal.identity, but it does make it clear how I should be
    >> coding in my pages. I don't think I've ever seen the distinction made
    >> this clearly before. It's probably in your (excellent) book somewhere,
    >> but I've only read the relevant bits twice, while trying to get this
    >> stuff straight in my head!
    >>
    >> Thanks again.
    >> Lyndon
    >> "Dominick Baier" wrote:
    >>
    >>> Roles.IsUserInRole will directly call the roles provider which e.g.
    >>> in the case of the SqlRoleProvider will do a database roundtrip.
    >>>
    >>> Context.User.IsInRole calls the RolePrincipal class. The caching is
    >>> done in this class which calls Role.GetRolesForUser and then caches
    >>> the list for subsequent calls.
    >>>
    >>> read also here:
    >>> http://www.leastprivilege.com/RolePrincipalVsRoleProviderPrincipal.as
    >>> px
    >>> ---
    >>> Dominick Baier, DevelopMentor
    >>> http://www.leastprivilege.com
    >>>> Hi,
    >>>>
    >>>> I'm hoping that someone might enlighten me as to how the
    >>>> Roles.IsUserInRole functionality works.
    >>>>
    >>>> I have my custom role provider set up and working, but realised that
    >>>> the caching wasn't working. When my c# code hit the line
    >>>> Roles.IsUserInRole I saw the identity property of my role principal
    >>>> being accessed and then, despite the roles being cached, the code
    >>>> goes off to establish if the user has the role from the role store.
    >>>>
    >>>> If I use Context.User.IsInRole the same thing happens but the role
    >>>> membership is established in the role principal from the cached
    >>>> roles.
    >>>>
    >>>> This is a web page where there is no impersonation -
    >>>> Context.Request.LogonUserIdentity.Name = the machine\IUSR account.
    >>>> Context.user.Identity.name = the login id supplied (via forms).
    >>>> Thread.CurrentPrincipal.Identity.Name is also the forms supplied
    >>>> user.
    >>>>
    >>>> Would I be right in thinking that Roles.IsUserInRole is looking for
    >>>> the roles of the context.LogonUserIdentity? Is there any way I
    >>>> persuade it to use Context.user.Identity.Name - without doing
    >>>> impersonation?
    >>>>
    >>>> Roles.IsUserInRole(Thread.CurrentPrincipal.Identity.Name,
    >>>> "TestRole")
    >>>> and
    >>>> Roles.IsUserInRole(Context.User.Identity.Name, "TestRole")
    >>>> also don't work, in that they don't use my cached roles they go back
    >>>> to the store, they do provide the correct result once that's done.
    >>>> This is part of a solution intended to handle windows/domain users,
    >>>> domain users not using windows/IE (primarily Apple) and non-domain
    >>>> users stored in ADAM.
    >>>>
    >>>> While it would be nice to be able to use the built in Roles
    >>>> functionality, I can live without it by using Context.User.IsInRole.
    >>>> I would like to know what I'm doing wrong in any case, or to
    >>>> properly understand why it doesn't work.
    >>>>
    >>>> Thanks for any assistance or explanation.
    >>>>
    >>>> Lyndon Hills
    >>>>

    >
    >
    Patrick.O.Ige, Oct 31, 2006
    #7
  8. Lyndon Hills

    Joe Kaplan Guest

    My book is on .NET Directory Services (LDAP) programming and has been out
    since May. You can get it at the link below. Dominick's book is all about
    ASP.NET Security and can be found here:

    http://www.microsoft.com/mspress/books/9989.asp

    They are separate efforts that don't overlap very much contentwise, so if
    you are interested, I'd suggest buying both. :)

    Joe K.

    --
    Joe Kaplan-MS MVP Directory Services Programming
    Co-author of "The .NET Developer's Guide to Directory Services Programming"
    http://www.directoryprogramming.net
    --
    "Patrick.O.Ige" <> wrote in message
    news:OseQWNK$...
    > Which Book is that..
    > Very well interested i have been looking for a book Dominick and Joe.K
    > were to release..
    > I have been out of the forum for sometime but 'm back now :)
    > Patrick
    >
    > "Dominick Baier" <dbaier@pleasepleasenospam_leastprivilege.com> wrote in
    > message news:...
    >> ah - and feel free to write a review on amazon if you like it :)
    >>
    >> ---
    >> Dominick Baier, DevelopMentor
    >> http://www.leastprivilege.com
    >>
    >>> Thanks for that.
    >>>
    >>> I don't quite see why Roles.IsUserInRole accesses my
    >>> roleprincipal.identity, but it does make it clear how I should be
    >>> coding in my pages. I don't think I've ever seen the distinction made
    >>> this clearly before. It's probably in your (excellent) book somewhere,
    >>> but I've only read the relevant bits twice, while trying to get this
    >>> stuff straight in my head!
    >>>
    >>> Thanks again.
    >>> Lyndon
    >>> "Dominick Baier" wrote:
    >>>
    >>>> Roles.IsUserInRole will directly call the roles provider which e.g.
    >>>> in the case of the SqlRoleProvider will do a database roundtrip.
    >>>>
    >>>> Context.User.IsInRole calls the RolePrincipal class. The caching is
    >>>> done in this class which calls Role.GetRolesForUser and then caches
    >>>> the list for subsequent calls.
    >>>>
    >>>> read also here:
    >>>> http://www.leastprivilege.com/RolePrincipalVsRoleProviderPrincipal.as
    >>>> px
    >>>> ---
    >>>> Dominick Baier, DevelopMentor
    >>>> http://www.leastprivilege.com
    >>>>> Hi,
    >>>>>
    >>>>> I'm hoping that someone might enlighten me as to how the
    >>>>> Roles.IsUserInRole functionality works.
    >>>>>
    >>>>> I have my custom role provider set up and working, but realised that
    >>>>> the caching wasn't working. When my c# code hit the line
    >>>>> Roles.IsUserInRole I saw the identity property of my role principal
    >>>>> being accessed and then, despite the roles being cached, the code
    >>>>> goes off to establish if the user has the role from the role store.
    >>>>>
    >>>>> If I use Context.User.IsInRole the same thing happens but the role
    >>>>> membership is established in the role principal from the cached
    >>>>> roles.
    >>>>>
    >>>>> This is a web page where there is no impersonation -
    >>>>> Context.Request.LogonUserIdentity.Name = the machine\IUSR account.
    >>>>> Context.user.Identity.name = the login id supplied (via forms).
    >>>>> Thread.CurrentPrincipal.Identity.Name is also the forms supplied
    >>>>> user.
    >>>>>
    >>>>> Would I be right in thinking that Roles.IsUserInRole is looking for
    >>>>> the roles of the context.LogonUserIdentity? Is there any way I
    >>>>> persuade it to use Context.user.Identity.Name - without doing
    >>>>> impersonation?
    >>>>>
    >>>>> Roles.IsUserInRole(Thread.CurrentPrincipal.Identity.Name,
    >>>>> "TestRole")
    >>>>> and
    >>>>> Roles.IsUserInRole(Context.User.Identity.Name, "TestRole")
    >>>>> also don't work, in that they don't use my cached roles they go back
    >>>>> to the store, they do provide the correct result once that's done.
    >>>>> This is part of a solution intended to handle windows/domain users,
    >>>>> domain users not using windows/IE (primarily Apple) and non-domain
    >>>>> users stored in ADAM.
    >>>>>
    >>>>> While it would be nice to be able to use the built in Roles
    >>>>> functionality, I can live without it by using Context.User.IsInRole.
    >>>>> I would like to know what I'm doing wrong in any case, or to
    >>>>> properly understand why it doesn't work.
    >>>>>
    >>>>> Thanks for any assistance or explanation.
    >>>>>
    >>>>> Lyndon Hills
    >>>>>

    >>
    >>

    >
    >
    Joe Kaplan, Oct 31, 2006
    #8
    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. John Saunders

    Re: Question: COntext.User.IsInRole

    John Saunders, Aug 6, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    3,418
    John Saunders
    Aug 6, 2003
  2. VB Programmer

    Wierd results with Roles.IsUserInRole

    VB Programmer, Jan 15, 2006, in forum: ASP .Net
    Replies:
    3
    Views:
    2,839
    =?Utf-8?B?Sm9l?=
    Jan 15, 2006
  3. =?Utf-8?B?QmVuIFIu?=

    Roles.IsUserInRole maps call to GetRolesForUser... Why?

    =?Utf-8?B?QmVuIFIu?=, Mar 20, 2006, in forum: ASP .Net
    Replies:
    7
    Views:
    887
    Steven Cheng[MSFT]
    Mar 24, 2006
  4. Jim McLeod

    ASP.NET Context.User.IsInRole XP Problem

    Jim McLeod, Jun 7, 2004, in forum: ASP .Net Security
    Replies:
    0
    Views:
    138
    Jim McLeod
    Jun 7, 2004
  5. Codifier

    AzMAN/ADAM-Roles.IsUserInRole() issues

    Codifier, Jan 19, 2010, in forum: ASP .Net Security
    Replies:
    1
    Views:
    959
    Codifier
    Jan 19, 2010
Loading...

Share This Page