PrincipalPermission attribute on Service contract

Is there a technical reason why a PrincipalPermission can't be placed on a service contract interface? It only works on the class implementing the contract or directly on the class methods.

This doesn't work.

[ServiceContract]
public interface IMyService
{
    [PrincipalPermission(SecurityAction.Demand, Role="Admin")]
    [OperationContract]
    void MyFunction(string str);
}

But it works if I place the attribute on the matching method in the class implementing IMyService.

Upvotes: 4

Views: 1396

Answers (2)

Stix
Stix

Reputation: 495

I know the post is old in attempt to provide a concrete answer to the OPs question the reason lies in the difference between an interface and a class.

Think about it; An interface is a description of an implementation it is not a behavior of an implementation. An interface just describes the class methods and events etc..

Or as Microsoft says it:

An interface defines the signatures for a set of members that implementers must provide. Interfaces cannot provide implementation details ~ (behavior) for the members.

A class that inherits an interface provides the behavior of those methods and events. - that is to say implements the [behavior ~ functionality] of the interface

So then why the Interface:

Do define an interface if you need to provide a polymorphic hierarchy of value types.

Consider defining interfaces to achieve an effect similar to that of multiple inheritance.

https://msdn.microsoft.com/library/ms229013(v=vs.100).aspx

Hope this helps someone else understand.

Upvotes: 1

Simon Mourier
Simon Mourier

Reputation: 138841

The role is checked at runtime, using the attributes put on the implementing method, not the attributes put on the interface the method implements. More generally in .NET there is not direct relation between custom attributes put on a method and custom attributes put on the corresponding interface method, if any.

Upvotes: 3

Related Questions