Injecting dependencies into AuthorizeAttribute in a class library

Question

I've run into an interesting design issue with a class library I am writing. I have a custom implementation of the AuthorizeAttribute that I want clients to be able to use like this:

[Protected("permission_name")]

In the above code, PermissionAttribute inherits from AuthorizeAttribute and uses a local default (DefaultContext created using HttpContext).

Behind the scenes, the attribute uses a SecurityService to check users, roles and permissions against (the SecurityService itself uses a client-provided persistence service that they can wire up in the composition root of their app).

So my attributes need a reference to the SecurityService to function. Since Attribute constructors can only have compile-time constants, I cannot use constructor injection.

I don't want to force my clients to use a DI framework - they should be able to discover and wire up the necessary dependencies in their composition root without using an IoC library, if they so choose.

Here are my options:

Have the library use a singleton SecurityService.
Use property injection, which would work but
1. it would make the dependency seem optional, which it is not and
2. I don't know where I can do property injection in an MVC app on an authorize attribute.

A possible solution to 2. above is to do set an instance of SecurityService as a static property on the attribute at application startup and use a guard clause to prevent it from being set more than once, like this:

class ProtectedAttribute : ...
{
    private static ISecurityService _SecurityService ;
    public static ISecurityService SecurityService
    {
        get 
        {
            return _SecurityService ;
        }
        set 
        {
            if (_SecurityService != null)
                throw new InvalidOperationException("You can only set the SecurityService once per lifetime of this app.") ;
            _SecurityService = value ;
        }
    }
}

The SecurityService could be an abstract service facade so that it can be extended/replaced by a different implementation.

Is there a better way to solve this problem?

UPDATE: Adding some code to show how I am going to do it:

Add a public property on the attribute that returns the permission name:

public class ProtectedAttribute : ...
{
  private string _Permission ;
  public string Permission { get { return _Permission ; } /*...*/ }

  public ProtectedAttribute(string permission) { /*...*/ }
}

Setup an authorization filter and configure dependency via Ninject (if using Ninject):

using Ninject.Web.Mvc.FilterBindingSyntax;

public class MyModule : Ninject.Modules.NinjectModule
{
  public override void Load()
  {
    // mySecurityService instance below can have a singleton lifetime - perfect!
    this.BindFilter<MyAuthorizationFilter>(FilterScope.Action, 0)
        .WhenActionMethodHas<ProtectedAttribute>()
        .WithConstructorArgument("securityService", mySecurityService)
        .WithConstructorArgumentFromActionAttribute<ProtectedAttribute>("permission", p => p.PermissionName) ;
  }
}

Ohhh it's...beautiful sniffle

@Darin: Yes requiring a minimum of MVC 3 is acceptable. Updated the tags. — Shashi Penumarthy, Jan 06 '12 at 15:53
Related: http://stackoverflow.com/questions/7192543/injecting-dependencies-into-asp-net-mvc-3-action-filters-whats-wrong-with-this/7194467#7194467 — Mark Seemann, Jan 06 '12 at 16:11

score 7 · Accepted Answer · edited May 23 '17 at 12:06

7

With ASP.NET MVC 3 you could use constructor injection with action filters thanks to the new IFilterProvider. This way you no longer need to decorate your controller actions with action filters. You could apply them thanks to this interface and using a marker attribute.

And if you don't wanna bother implementing it manually you could always use an existing DI framework such as Ninject which provides a fluent way to define action filter dependencies.

edited May 23 '17 at 12:06

Community

1
1

answered Jan 06 '12 at 15:58

Darin Dimitrov

1,023,142
271
3,287
2,928

+1 for `IFilterProvider` that gives quite clean solution. Similar problem [ASP.NET MVC IFilterProvider and separation of concerns](http://stackoverflow.com/questions/10708565/asp-net-mvc-ifilterprovider-and-separation-of-concerns) (Castle Windsor). – Michał Powaga Nov 14 '13 at 20:29

score 0 · Answer 2 · edited May 31 '12 at 00:04

My applications inherit from a base Application class that exposes the IOC container.

public interface IInjectableApplication
    {
        IUnityContainer Container { get; }
    }

Then I have a base attribute class, which is aware of this

public abstract IocAwareActionFilterAttribute : ActionFilterAttribute{
    protected T ResolveItem<T>(ResultExecutedContext context)
        {
            var app = context.HttpContext.ApplicationInstance as IInjectableApplication;
            if (app == null) { throw new NullReferenceException("Application is not IInjectable."); }

            T c = (T)app.Container.Resolve(typeof(T));

            if (c == null) { throw new NullReferenceException(string.Format("Could not find injected {0}.", typeof(T).FullName)); }
            return c;
        }

}

While this is not true Injection, since Attributes aren't constructed 'normally', this provides a similar behavior. No reason it should not be adaptable to other IOCs

Injecting dependencies into AuthorizeAttribute in a class library

2 Answers2