Coder Legion - Recent posts tagged aspnet8

How To Create Custom Middlewares in ASP.NET Core

Mon, 13 May 2024 13:40:47 +0000

ASP.NET Core's middleware architecture offers a powerful way to build and configure the HTTP request pipeline in your applications. In this post, you'll explore what middleware is and how to create a custom middlewares in ASP.NET Core.

What is Middleware in ASP.NET Core?

Middleware in ASP.NET Core is a software component that is a part of application pipeline that handles requests and responses. In ASP.NET Core there are multiple middlewares that are combined in a chain with each other.

Each middleware component in the pipeline is responsible for invoking the next component in the sequence. Any middleware can stop other middlewares from execution by short-circuiting the chain if necessary. Middlewares in ASP.NET Core is a classic implementation of chain of responsibility design pattern.

ASP.NET Core has a lot of built-in middlewares and many provided by Nuget packages. The order in which middlewares are added to the application pipeline is critical. It defines how the incoming HTTP requests travel through the pipeline and in what sequence the responses are sent back.

Middlewares are executed in the order they are added to the pipeline in the WebApplication object. If you want to learn more about common middlewares and their correct order - read my blog post.

How To Create Custom Middleware in ASP.NET Core

You can create a custom middleware in the following ways:

provide a delegate for Use method in WebApplication class
create a Middleware class by convention
create a Middleware class by inheriting from IMiddleware interface

With a Use Method in WebApplication Class

You can call a Use method on the WebApplication class to create a middleware:


    var builder = WebApplication.CreateBuilder(args);
    
    builder.Logging.AddConsole();
    
    var app = builder.Build();
    
    app.Use(async (context, next) =>
    {
        Console.WriteLine("Request is starting...");
    
        await next();
    
        Console.WriteLine("Request has finished");
    });
    
    app.MapGet("/api/books", () =>
    {
        var books = SeedService.GetBooks(10);
        return Results.Ok(books);
    });
    
    await app.RunAsync();

In this example when calling a /api/books endpoint, the middleware declared in the Use method is called first. await next.Invoke() calls the books endpoint itself, but before and after we have a message logged to console:


    Request is starting...
    Request has finished

Middlewares are executed in the order they are added to the pipeline in the WebApplication object. Each middleware can perform operations before and after the next middleware:

Before: executing operations before calling the next middleware can include tasks like logging, authentication, validation, etc.

After: operations after calling the next middleware can include tasks like response modification or error handling.

The real power of middlewares is that you can chain them freely in any order you want. To stop the request from executing and short-cut the middleware chain (stop other middlewares from executing) - write a response directly into HttpContext instead of calling the await next.Invoke() method:


    await context.Response.WriteAsync("Some response here");

With a Middleware Class by Convention

You can extract a middleware to a separate class that follows the specific convention:


    public class LoggingMiddleware
    {
        private readonly RequestDelegate _next;
    
        public LoggingMiddleware(RequestDelegate next)
        {
            _next = next;
        }
    
        public async Task InvokeAsync(HttpContext context)
        {
            Console.WriteLine($"Request: {context.Request.Method} {context.Request.Path}");
    
            await _next(context);
    
            Console.WriteLine($"Response: {context.Response.StatusCode}");
        }
    }

To add this middleware to the pipeline, call the UseMiddleware method on the WebApplication class:


    app.Use(async (context, next) =>
    {
        // Middleware from previous example
    });
    
    app.UseMiddleware();

As a result of executing this middleware the following will be logged to the console when executing an /api/books endpoint:


    Request is starting...
    Request: GET /api/books
    
    Response: 200
    Request has finished

This approach is called by convention, because middleware class must follow these rules:

middleware class should have a InvokeAsync method with a required HttpContext argument
middleware class should inject a next RequestDelegate in the constructor
middleware class call the next RequestDelegate delegate and pass it the HttpContext argument

With a Middleware Class That Implements `IMiddleware` Interface

The previous approach has its drawbacks: the developer needs to create a middleware class that follows all mentioned above rules, otherwise a middleware won't work. But there is a safer way to create a middleware: implement the IMiddleware interface:


    public class ExecutionTimeMiddleware : IMiddleware
    {
        public async Task InvokeAsync(HttpContext context, RequestDelegate next)
        {
            var watch = Stopwatch.StartNew();
            
            await next(context);
            
            watch.Stop();
            
            Console.WriteLine($"Request executed in {watch.ElapsedMilliseconds}ms");
        }
    }

This approach is much safer as the compiler tells how the middleware class should look like.

For this approach you need to manually register ExecutionTimeMiddleware in the DI container:


    builder.Services.AddScoped();

To add this middleware to the pipeline, call the UseMiddleware method on the WebApplication class:


    app.Use(async (context, next) =>
    {
        // Middleware from previous example
    });
    
    app.UseMiddleware();
    app.UseMiddleware();

As a result of executing this middleware the following will be logged to the console when executing an /api/books endpoint:


    Request is starting...
    Request: GET /api/books
    Request executed in 68ms
    
    Response: 200
    Request has finished

Middlewares and Dependency Injection

Middlewares by convention have Singleton lifetime by default and all dependencies injected in constructor must be singletons too. As we already know, middlewares run per each request, and you can inject scoped dependencies in the InvokeAsync method after HttpContext. Here we are injecting a ILoggingService that is registered as scoped service in DI:


    builder.Services.AddScoped();

    public class LoggingMiddleware
    {
        private readonly RequestDelegate _next;
    
        public LoggingMiddleware(RequestDelegate next)
        {
            _next = next;
        }
    
        public async Task InvokeAsync(HttpContext context, ILoggingService loggingService)
        {
            loggingService.LogRequest(context.Request.Method, context.Request.Path);
    
            await _next(context);
    
            loggingService.LogResponse(context.Response.StatusCode);
        }
    }

This approach is suitable only for middleware classes created by convention. To inject scoped services into middleware classes that implement IMiddleware interface, simply use the constructor:


    public class ExecutionTimeMiddleware : IMiddleware
    {
        private readonly ILoggingService _loggingService;

        public ExecutionTimeMiddleware(ILoggingService loggingService)
        {
            _loggingService = loggingService;
        }

        public async Task InvokeAsync(HttpContext context, RequestDelegate next)
        {
            // ...
        }
    }

NOTE: when creating a middleware class that implements IMiddleware interface - you are responsible for selecting an appropriate DI lifetime for it. You can create Singleton, Scoped or Transient middleware, select what suits the best in each use case.

Summary

You can create a custom middleware in the following ways:

provide a delegate for Use method in WebApplication class
create a Middleware class by convention
create a Middleware class by inheriting from IMiddleware interface

My preferred choice is to create a middleware by inheriting from the IMiddleware interface. This approach offers a safer, more convenient way to create middlewares and a straightforward dependency injection strategy through a constructor. And it also gives a full control over the middleware lifetime.

Rate limiting middleware in ASP.NET Core using .NET 8.0

Sat, 11 May 2024 20:54:38 +0000

Rate limiting middleware in ASP.NET Core is a concept commonly associated with an API, where it states (a rate limiter in a web API) is a mechanism used to control the number of requests that a client can make to an API within a certain time frame. It helps prevent API misuse or abuse by limiting the number of requests from a particular client or IP address, ensuring fair usage, and protecting server resources from being overwhelmed.

Note: This concept has been integrated as a middleware with .NET 7 and later.

In the .Net environment, we have 4 types of algorithms that we can use in this regard:

1) Fixed window limiter

2) Sliding window limiter

3) Token bucket limiter

4) Concurrency limiter

We will explain each of them in a simplified manner.

1) Fixed window limiter

Fixed window limiter stipulates that there is a time limit for the window in which a number of requests can be executed, meaning that the number of requests must not exceed the permitted number in a specific, pre-determined time.

For example, 6 seconds for the window. You can execute a number of requests, for example 1 requests. If it exceeds this number, it must go to the waiting queue, for which we can also prepare an expected space, for example, 1 waiting requests. If the number of requests exceeds this number, an error message will be returned to the user because he has exceeded his permissible limit of requests, in most cases 429 in the case of an answer.

builder.Services.AddRateLimiter(option =>
{
    option.AddFixedWindowLimiter("FixedWindowPolicy", opt =>
    {
        opt.PermitLimit = 1; // items allow processing
        opt.Window = TimeSpan.FromSeconds(6); // time need to process PermitLimit items's
        opt.QueueLimit = 1; // items allow be in Queue waiting

        opt.QueueProcessingOrder = System.Threading.RateLimiting.QueueProcessingOrder.OldestFirst;//Order the items in Queue Waiting
    }).RejectionStatusCode = 429; // This means that this request is not allowed at this time due to the large number of requests received now
});

2) Sliding Window Limiter

The sliding window limiter is similar to the fixed window limiter but offers more flexibility. It processes old requests while tracking ongoing ones, allowing it to handle new requests based on the status of previously submitted but incomplete requests.

For example, I have a window that lasts 6 seconds and receives 4 requests for this window. I can divide the window into three sliding windows (three segments per window). Here, this one window processes 4 requests. It executes what it can from it and passes it to the second window. And so, it goes for the second window as well. It executes and passes it to the window. The first is that if the sliding window has space to receive new requests, it pops up again in order to receive new requests while taking into account old requests that have not been completed.

builder.Services.AddRateLimiter(option =>
{
    option.AddSlidingWindowLimiter("SlidWindowPolicy", opt =>
    {
        opt.PermitLimit = 4; // items allow processing
        opt.Window = TimeSpan.FromSeconds(6); // time need to process PermitLimit items's
        opt.QueueLimit = 5; // items allow be in Queue waiting
        opt.QueueProcessingOrder = System.Threading.RateLimiting.QueueProcessingOrder.OldestFirst;//Order the items in Queue Waiting
        opt.SegmentsPerWindow = 3;
    }).RejectionStatusCode = 429; // This means that this request is not allowed at this time due to the large number of requests received now
});

3) Token Bucket Limiter

The token bucket limiter is a straightforward yet effective rate limiting technique. It uses a bucket to hold a set number of tokens, each representing permission to handle one request. When a request is made, a token is removed from the bucket. If the bucket is empty, the request is denied until more tokens become available.Tokens are replenished at a fixed rate over time, ensuring that the system can handle bursts of requests followed by idle periods.

For example, in a token bucket rate limiting algorithm, you might have a bucket that can hold up to 100 tokens. Each incoming request consumes one token, so the bucket's token count decreases with each request. To ensure that the system can handle bursts of requests, new tokens are added to the bucket at a specified interval (e.g., 3 tokens every 5 seconds), without exceeding the maximum bucket size of 100 tokens. This mechanism prevents request flooding while allowing occasional spikes in request rate.

builder.Services.AddRateLimiter(option =>
{
    option.AddTokenBucketLimiter("TokenBucketPolicy", opt =>
    {
        opt.TokenLimit = 100; // Maximum number of tokens in the bucket
        opt.QueueLimit = 10; // Number of requests that can wait in the queue
        opt.QueueProcessingOrder = System.Threading.RateLimiting.QueueProcessingOrder.OldestFirst; // Order of processing queued requests
        opt.ReplenishmentPeriod = TimeSpan.FromSeconds(5); // Time period for adding new tokens
        opt.TokensPerPeriod = 3; // Number of tokens added each period
    }).RejectionStatusCode = 429; // Status code returned when rate limit is exceeded
});

4) Concurrency limiter

Concurrency limiter limits the number of concurrent requests. Each request reduces the concurrency limit by one. When the order is completed, the limit is increased by one.

For example, we have a synchronization limit of 1 operation. Here, only one will be responsible for performing 1 simultaneous operation, meaning it must not exceed this limit.

builder.Services.AddRateLimiter(option =>
{
    option.AddConcurrencyLimiter("ConcurrencyPolicy", opt =>
    {
        opt.PermitLimit = 1; // Maximum number of concurrent requests allowed
        opt.QueueLimit = 10; // Number of requests that can wait in the queue
        opt.QueueProcessingOrder = System.Threading.RateLimiting.QueueProcessingOrder.OldestFirst; // Order of processing queued requests
    }).RejectionStatusCode = 429; // Status code returned when rate limit is exceeded
});

In the end, to connect it to the endpoint you can use two methods:

By using Controller endpoint:

[HttpGet("GetConcurrency")]
[EnableRateLimiting("ConcurrencyWindowPolicy")]

public IActionResult GetConcurrency()
{
    return Ok("Concurrency");
}  

[HttpGet("GetFixed")]
[EnableRateLimiting("FixedWindowPolicy")]

public IActionResult GetFixed()
{
    return Ok("Fixed");
}

[DisableRateLimiting]
public ActionResult NoLimit()
{
    return Ok("NoLimit");
}

The EnableRateLimiting attribute is used to apply a specified rate limiting policy to an action method. When this attribute is applied to a method, the rate limiting rules defined by the specified policy are enforced for that method. This means that any incoming requests to the action will be subject to the constraints of the policy, such as the maximum number of requests allowed in a given time period.

By using Minimal endpoint:

 app.MapGet("/", () => Results.Ok("fixed")).RequireRateLimiting("FixedWindowPolicy");

The RequireRateLimiting method is similar to EnableRateLimiting, but it is used in the context of endpoint routing. It attaches a rate limiting policy directly to an endpoint defined in the routing configuration. When a request matches the route, the specified rate limiting policy is applied.

Importance of Rate Limiting for API Providers

1. Maintaining Service Reliability
Rate limiting helps ensure that an API remains responsive and available, even under heavy load.

2. Preventing Abuse
APIs are often targets for malicious activities, such as denial-of-service (DoS) attacks, scraping, and other forms of abuse. Rate limiting acts as a safeguard against these threats by limiting the rate at which requests can be made, thereby reducing the impact of automated attacks and ensuring that legitimate users can access the service.

3. Ensuring Fair Resource Allocation
Rate limiting ensures that resources are distributed fairly among all users. Without rate limiting, a few users might consume a disproportionate amount of server resources, leading to poor performance or service degradation for others.

In the end

In the end, these rate limiting algorithms can be fine-tuned using additional parameters, such as client IP addresses or user authorization levels, to impose more detailed limits tailored to specific user profiles. By implementing rate limiting with precise parameters, API providers can ensure optimal performance, fair resource allocation, and protection against abuse across all user interactions with the API.

Fine-Tuning Rate Limiting

Client IP Addresses: Apply rate limits based on the IP address of the client, allowing more granular control over request rates from different sources.

User Authorization Levels: Differentiate rate limits based on user roles or authorization levels, providing higher limits for premium users and lower limits for regular users.

Custom Rules: Create custom rate limiting rules to accommodate specific application needs, such as limiting requests based on geographic regions or specific API endpoints.

More resources

https://www.youtube.com/watch?v=bOfOo3Zsfx0

https://learn.microsoft.com/en-us/aspnet/core/performance/rate-limit?view=aspnetcore-8.0

Null Reference Exceptions in C# - Fixed

Sat, 10 Feb 2024 03:09:53 +0000

Sometimes, during our projects, we might get a Null Reference Exception coming from a deep and forgotten part of our code.

In this article, we will understand why it happens, and explore a few ways to solve it.

Whenever you try to access an object or variable, which is not properly instantiated or initialized, you might get a Null Reference Exception.

Let's look at the example below. We have a class called People, with a property called Name, which type is a class. Although the property FullName treats the error of getting its value before its being assigned, returning a default empty string, we don't have the same for Name property within People class.

try
{

    var joel = new People();
    var joelsName = joel.Name.FullName; //throws an Exception
    
}
catch (System.Exception exp)
{
    System.Console.WriteLine(exp);
}

class People {
public Name Name { get; set; }
}
class Name { 
    public string FullName { get; set; } = String.Empty;
}

Running the code above results in the following:

constructor. Consider declaring the property as nullable. [..\dotnetlabs\NullReference\NullReference.csproj]
System.NullReferenceException: Object reference not set to an instance of an object.
   at Program.<Main>$(String[] args) in

Note: I removed the path information once that is private. In your
case the location of your program would be shown instead.

Now that we understand why this error happens, it's time to solve it. I listed three solutions you can take in your code to avoid getting this Exception.

Solution 1: Declaring variables as being nullable

If you intend to use null in your logic, then you must declare the variables as nullable by adding a question mark at the end of the name.

try
{
    var joel = new People();

    var joelsName = joel.Name?.FullName; // we don't get NullReference Exception any more
    
}
catch (System.Exception exp)
{
    
    System.Console.WriteLine(exp);
}

class People {
public Name? Name { get; set; }
}
class Name { 
    public string FullName { get; set; } = String.Empty;
}

Observe that I put the question mark in the property declaration and also when I invoke it to access the FullName property.
The code above doesn't throw an Exception anymore, once the program understands now that a null value is expected from Name property.

Solution 2: Treating the getter

Another option is to intercept when the program tries to read the Name property, so whenever the program tries to read the property it checks if it is null first, if so then returns a new instance of the object:

try
{
    var joel = new People();

    var joelsName = joel.Name.FullName; // we don't get NullReference Exception any more

}
catch (System.Exception exp)
{

    System.Console.WriteLine(exp);
}

class People
{
    private Name? _name;

    public Name Name
    {
        get
        {
            if (_name is null) 
            { 
                return new Name(); 
            }

            return _name;
        }
        set
        {
            _name = value;
        }
    }
}
class Name
{
    public string FullName { get; set; } = String.Empty;
}

Solution 3: Using constructors

A third option is to guarantee the properties and variable values using constructors. Whenever a constructor is defined, it forces you to instantiate the object. You should use the constructor logic to make sure none of your variables and properties are null.

try
{
    var joel = new People("Joel Smith");

    var joelsName = joel.Name.FullName;

    Console.WriteLine(joelsName);

}
catch (System.Exception exp)
{

    System.Console.WriteLine(exp);
}

class People
{
    public Name Name { get; set; }

    public People(string name)
    {
        Name = new Name(name);
    }
}
class Name
{
    public string FullName { get; set; } = String.Empty;
    public Name(string name)
    {
        FullName = name;
    }
}

Conclusion

In the majority of cases, you should avoid working with null values, as they might be a bad idea if not handled properly. However, there are a few cases in which we can use nulls to represent badly parsed data or a no value when querying some database. If so, you must treat them correctly to avoid your program breaking unexpectedly.