Method level permission

[Victor Hadianto]

Hi All,

Is it possible to set invoke permission at method level? For example
on a class:

public class MyClass
{
public void MethodA() { ... }

public void MethodB() { ... }
}

Can I somehow set that MethodA() and MethodB() will throw exception
depending who calls it? Yes I realise this is probably a design
catastrophe, but is it technically possible to do this? Without manual
introspection of the call stack hopefully.

Many thanks,
Victor

 

[Marc Gravell]

Yes I realise this is probably a design

catastrophe, but is it technically possible to do this?

Actually, it is good design to think about who can call a method; and
better design to enforce it ;-p

Can I somehow set that MethodA() and MethodB() will throw exception
depending who calls it?

It depends on what you mean by "who?". If you mean "which user of you
app", the you want to look at PrincipalPermissionAttribute, for
example:

// only admins can call MethodA
[PrincipalPermission(SecurityAction.Demand, Role="ADMIN")]
public void MethodA() {}

// only "Fred" can call MethodB (less useful)
[PrincipalPermission(SecurityAction.Demand, Name = "Fred")]
public void MethodB() { }

Your definition of roles and users is up to you, via the "principal",
but you can use the windows user if you like (names and roles would be
domain-qualified):

Thread.CurrentPrincipal = new
WindowsPrincipal(WindowsIdentity.GetCurrent());

You could alternatively use a membership database.

You can also enforce which /code/ can call the method by way of
inheritance demands, but that is harder to illustrate:
http://msdn2.microsoft.com/en-gb/library/x4yx82e6.aspx

Marc

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,


you could check the IPrincipal (using Thread.CurrentPrincipal) and then do
something about.

 

[Nicholas Paldino [.NET/C# MVP]]

Victor,

While limiting access by role is not a design catastrophe (an issue
addressed by other responses to this post), I get the impression that the
solution you are looking for is one based on which method is being used to
call your method.

If this is the case, you want to look into Link Demands. It might only
address the class that is being used to call your code, not the actual
method.

If it doesn't, the worst-case scenario here is to do a stack walk, which
the StackTrace class can help with.

 

[Ben Voigt [C++ MVP]]

Victor,

While limiting access by role is not a design catastrophe (an issue
addressed by other responses to this post), I get the impression that the
solution you are looking for is one based on which method is being used to
call your method.

If this is the case, you want to look into Link Demands. It might only
address the class that is being used to call your code, not the actual
method.

LinkDemands can check the specific directly calling method.

If it doesn't, the worst-case scenario here is to do a stack walk,
which the StackTrace class can help with.

If you need a full stack walk, use Demand, if you want to check only the
immediate caller, use LinkDemand. You don't need to do the stack walk
yourself.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hi All,

Is it possible to set invoke permission at method level? For example
on a class:

public class MyClass
{
public void MethodA() { ... }

public void MethodB() { ... }
}

Can I somehow set that MethodA() and MethodB() will throw exception
depending who calls it? Yes I realise this is probably a design
catastrophe, but is it technically possible to do this? Without manual
introspection of the call stack hopefully.

Many thanks,
Victor

 

[Victor Hadianto]

Hi Nicholas,

If this is the case, you want to look into Link Demands. It might only
address the class that is being used to call your code, not the actual
method.

Ah yes this is actually what I am looking for. Which methods are
calling the specified method.

I still think that this is not such a good idea and the class should
be designed in a way to prevent this from happening. Unfortunately I
*have* to make this method public but still want to limit the
caller :/

Thanks,
Victor