Disabling Controllers in .NET Core Web API with Custom C# Attribute

To disable controllers in a .NET Core Web API, create a custom attribute inheriting from Attribute and implement an IActionFilter. This filter checks for the attribute on the controller or action during execution and returns a 404 Not Found status code if present. This approach provides a clean, declarative way to hide endpoints without modifying routing configurations.

Understanding the Requirement

In many enterprise applications, there is a need to temporarily or permanently disable specific API endpoints. While one might consider removing routes or using conditional middleware, these approaches often lack granularity or require significant architectural changes. A custom attribute offers a lightweight solution that keeps the logic close to the affected controllers. This method allows developers to mark controllers or individual actions as disabled directly in the code, making it easy to toggle availability through configuration or simple comments.

Why Not Just Remove Routes?

Removing routes entirely can break client-side references or cause confusion during deployment cycles where features are toggled based on environment variables. Using an attribute ensures that the code remains in place but is effectively invisible to the HTTP pipeline. This is particularly useful for deprecated endpoints that should still exist in the codebase for historical reference but must not respond to live traffic.

Creating the Custom Attribute

The first step is to define a custom attribute class. In C#, attributes are classes that inherit from System.Attribute. You can add properties to this attribute if you need to pass additional information, such as a reason for disabling or an expiration date. For basic functionality, a simple marker attribute is sufficient.

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, AllowMultiple = false)]
public class DisableControllerAttribute : Attribute
{
    public string Reason { get; set; }
    
    public DisableControllerAttribute(string reason = "Disabled")
    {
        Reason = reason;
    }
}

This attribute can be applied to either the entire controller class or specific action methods. By setting AllowMultiple to false, we ensure that the attribute is only applied once per target, preventing potential conflicts or ambiguous states.

Implementing the Filter Logic

Attributes themselves do not execute logic; they merely store metadata. To act on this metadata, you need a filter. Implementing IActionFilter is the most appropriate choice because it runs after the action has been selected but before it executes. This allows you to intercept the request and short-circuit the response.

public class DisableControllerFilter : IActionFilter
{
    public void OnActionExecuting(ActionExecutingContext context)
    {
        // Check if the attribute exists on the controller or action
        var disableAttr = context.ActionDescriptor.EndpointMetadata
            .OfType()
            .FirstOrDefault();

        if (disableAttr != null)
        {
            context.Result = new NotFoundResult();
        }
    }

    public void OnActionExecuted(ActionExecutedContext context)
    {
        // No logic needed here
    }
}

The OnActionExecuting method inspects the EndpointMetadata of the current action descriptor. If the DisableControllerAttribute is found, it sets the Result property to a NotFoundResult. This immediately terminates the request pipeline and sends a 404 response to the client, bypassing the actual controller logic entirely.

Registering the Filter

Once the filter is defined, it must be registered in the dependency injection container so that ASP.NET Core knows to invoke it. This is typically done in the Program.cs file or the Startup.cs file, depending on your project structure.

builder.Services.AddControllers(options =>
{
    options.Filters.Add();
});

By adding the filter globally, it will check every incoming request against any controller or action marked with the DisableControllerAttribute. If you prefer to apply it only to specific controllers, you can register it as an instance within the controller itself, but global registration is generally cleaner for cross-cutting concerns like this.

Applying the Attribute

With the infrastructure in place, applying the attribute is straightforward. Simply place the attribute above your controller class or specific action methods.

[DisableController("Deprecated endpoint")]
[ApiController]
[Route("api/[controller]")]
public class OldDataController : ControllerBase
{
    [HttpGet]
    public IActionResult Get()
    {
        return Ok(new { message = "This will never be reached" });
    }
}

In this example, any GET request to /api/olddata will result in a 404 Not Found error. The underlying logic in the Get method is never executed. This is ideal for sunsetting APIs where you want to avoid returning 500 errors or exposing sensitive data from legacy systems.

Handling Configuration-Based Disabling

If you need to disable controllers based on runtime configuration rather than static code, you can enhance the attribute to accept configuration keys. However, this requires injecting IConfiguration into the filter, which adds complexity. For most use cases, static attributes provide sufficient control and maintainability.

Benefits of This Approach

Using a custom attribute for disabling controllers offers several advantages over alternative methods. It keeps the code DRY (Don't Repeat Yourself) by centralizing the logic in one filter. It also improves readability, as developers can instantly see which endpoints are inactive by scanning the attribute usage. Furthermore, it integrates seamlessly with existing MVC pipelines, requiring no changes to routing tables or middleware stacks.

For more insights on managing .NET Core components effectively, you might find Alternative to avoid calculating the total record count when performing pagination helpful for optimizing other aspects of your API performance.

Frequently Asked Questions

Can I return a different status code instead of 404?

Yes, you can return any IActionResult you choose. For example, use new StatusCodeResult(410) for Gone or new BadRequestObjectResult("Disabled") for a clearer error message. Changing the result type allows you to communicate the deprecation status more accurately to clients.

Does this affect Swagger documentation?

Standard Swagger generators like Swashbuckle scan controller types and actions regardless of runtime filters. Therefore, disabled endpoints may still appear in the generated documentation. You would need to configure Swagger to ignore specific controllers or actions manually if you wish to hide them from the UI.

Is there a performance impact?

The performance impact is negligible. The filter runs extremely quickly, simply checking metadata and setting a result. It avoids the overhead of executing the actual controller logic, which is beneficial if the disabled controller contained expensive database queries or external service calls.

How do I handle authentication for disabled endpoints?

Since the filter runs in OnActionExecuting, it executes after authentication middleware has completed its work. If you want to skip authentication entirely for disabled endpoints, you should place the filter logic earlier or ensure that the 404 response is sent before authentication costs are incurred. Typically, however, security best practices suggest that disabled endpoints should still respect authentication policies.

Can I use this attribute in ASP.NET Framework?

While the concept is similar, ASP.NET Framework uses ActionFilterAttribute which inherits from both Attribute and IActionFilter. The implementation details differ slightly, particularly in how you access metadata. You would need to adapt the code to fit the older framework's event model.