Why should we choose PrincipaPermission over IsInRole()?

views:

291

answers:

Why should we choose PrincipaPermission over IsInRole()?

Hello,

Q1 - I’m not sure I understand why we should prefer to use PrincipalPermission.Union() ( or PrincipalPermission.Intersect() ) instead of IsInRole()? If anything, calling IsInRole() several times requires less code than creating multiple PrincipalPermission objects and merging them into one via Union() ( or Intersect() )?

Q2 - One constructor overload of PrincipalPermission object also specifies a IsAuthenticated flag that tells Demand() to verify if user is authenticated. Wouldn’t using that flag only be useful in situations where first two parameters ( name and role ) are both null?

thanx

+1 A:

Q1.

The two function calls make a PrincipalPermission that has the union or intersection of the roles you give it. Thus you end up with a principal that has a very specific set of demands, which you can then call IsInRole() upon. Note that doing this will hit your role provider which may be an SQL server or the active directory and thus have latency involved, so you don't want to do it all the time.

Q2.

Authenticated indicates that the user is logged in against your provider. You may want this if you need only auditing on your application, confirming the user is logged in to your role provider will mean that you can log who they are etc.

You are correct in saying it's only useful where you don't care about who the user is, only that they are logged in.

Spence 2009-05-10 21:05:00

Q1 - but anything we can do with using PrincipalPermission.Union() or PrincipalPermission.Intersect(), we can also do with IsInRole() and with much less typing?!

SourceC 2009-05-10 21:18:47

yes but you must call it twice. You create one prinicipal permission which is the union or intersect of the principals your after and then call IsInRole() once.Also set intersect/union will give you a different result depending on what each role has.http://en.wikipedia.org/wiki/Intersection_(set_theory)http://en.wikipedia.org/wiki/Union_(set_theory)

Spence 2009-05-10 21:37:55

Sorry for dragging this topic - I see this useful only if we will use same merged ( via Intersect/Union ) PrincipalPermission object on several different occasions?! I'm probably missing something very obvious

SourceC 2009-05-10 21:49:54

No, what I mean is that each call to isinrole() involves latency (possibly). So if you grab a permission, union two together, then call IsInRole() that should be faster than calling IsInrole() for both permissions.

Spence 2009-05-11 00:06:45

So main reason for using Union/Intersect instead of IsInRole() is latency? But to my calculations number of method calls is about the same when using Union/Intersect as when using IsInRole! Namely, it takes three calls to create merged PrincipalPermission object: First two calls create two PrincipalPermission objects, which are merged with a third call to Union. Thus number of method calls ( and thus latency ) is even greater when using Union/Intersect. I apologize for being so dumb :(

SourceC 2009-05-11 18:48:41

You don't have to hit the domain to create a principal, nor to union or intersect. To call IsInRole() though you do AFAIK.

Spence 2009-05-12 02:13:54

I really apologize for keep dragging this topic. Anyways, I assume that by "hit the domain" you are referring to the fact that IsInRole can only be called after principal object has been assigned to HttpContext.User property? But how does that relate to IsInRole() causing latency?

SourceC 2009-05-13 19:19:12

PrincipalPermission can rely on anything that can use the ASP.Net roles provider. One of these (and the default for an enterprise) is the windows domain server. Constructing the permission by providing a role name, or by unioning or intersecting doesn't actually do anything to the role provider at all, no calls should be made to the provider.However when you call IsInRole() you are asking the role provider to tell you whether or not the principal you've given matches the role you have, and this can be an expensive call.

Spence 2009-05-13 21:45:56

What did you mean by "rely on anything that can..."?

SourceC 2009-05-14 15:09:40

Go read about Role providers at MSDN. PrincipalPermission falls back to role provider to give it an answer. THis can be a forms database, your own custom provider, or can be a kerberos server, windows domain etc.

Spence 2009-05-14 22:04:34

thank you very much for your kind help ( and of course patience :) )

SourceC 2009-05-15 21:04:13

ansaurus

tags:

views:

answers:

Why should we choose PrincipaPermission over IsInRole()?

related questions