Re: Roles.IsUserInRole != Context.User.IsInRole
- From: "Patrick.O.Ige" <naijacoder@xxxxxxxxxxx>
- Date: Tue, 31 Oct 2006 15:16:23 +1100
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@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message news:4580be631988e8c8c28d82a5f574@xxxxxxxxxxxxxxxxxxxxx
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
.
- References:
- Re: Roles.IsUserInRole != Context.User.IsInRole
- From: Lyndon Hills
- Re: Roles.IsUserInRole != Context.User.IsInRole
- From: Dominick Baier
- Re: Roles.IsUserInRole != Context.User.IsInRole
- Prev by Date: Delegation / Impersonation problem
- Previous by thread: Re: Roles.IsUserInRole != Context.User.IsInRole
- Next by thread: Re: <location> multiple file question
- Index(es):
Relevant Pages
|