One big problem developers often face is dealing with private information that moves through API requests. Requests not appropriately checked can create weak spots that let bad people see or take private information. To fix this, teams can use middleware to check, clean, and hide private information before it gets to the main program.

This article will show you how to build middleware in .NET Core that makes APIs safer by cleaning and hiding private data. You will learn how to catch and change incoming requests, work with settings that can change, and make things run fast while letting your program grow bigger. After reading this guide, you will know how to make a strong, safe middleware layer for your APIs.

Middleware in .NET Core and How It Handles API Requests

Middleware is a key part of the Asp.Net Core system, working as the main piece of how requests and responses flow. In a web app, middleware parts handle HTTP requests as they move through this flow, letting developers add special tasks at different steps. These parts can change requests, add safety checks, save records of what happens, or fix errors, making them very important for building strong APIs.

Middleware works between when a client asks for something and when an API gives an answer. In Asp.Net Core, middleware is a small, separate part that can either work with requests and send them to the next part in the line or stop and make an answer. Middleware is set up in the Program.cs or Startup.cs file, letting developers make a custom and growing request line.

You need to use Startup.cs if your project is targeting

1. Asp.Net Core 1.x

2. Asp.Net Core 2.x

3. Asp.Net Core 3.x

4. .Net 5

You need to use Program.cs if your project is targeting

1. .Net 6

2. .Net 7

3. .Net 8

The Asp.Net Core middleware line works with requests one after another, ensuring each middleware part runs in the order it was put in. This setup lets developers make middleware for many uses, including:

• Checking who someone is and what they can do.

• Writing down what happens and watching how things work.

• Dealing with problems when they happen.

• Changing and checking data.

APIs often handle private data, like personal, money, and login details. Showing this information without protection can cause safety problems, like data theft and people getting in who should not. Middleware helps fix this by letting developers filter and hide private data before it gets to the main Program.

Filtering requests means looking at what is in them to find and remove harmful or unwanted parts. Hiding data means replacing private information with fake values so it is not shown during work or record-keeping. Together, these make API work safer and more trustworthy.

Main Things About Middleware for Filtering and Hiding

Using middleware for filtering and hiding requests in .NET Core gives several good things:

1. Better Safety: Middleware can stop private data from being shown in records, answers, or other systems, making data theft less likely.

2. Following Rules: Middleware can help APIs follow data protection laws like GDPR or HIPAA by keeping private information safe.

3. Working Better: By filtering out wrong or bad requests, middleware makes program errors less likely and makes the whole system work better.

4. Easy to Change and Grow: Middleware parts are easy to make, test, and update, letting developers fix new safety needs without significant program changes.

5. Exact Data Handling: Middleware ensures private data is handled the same way across all API endpoints, making fewer mistakes and differences.

Before we start making middleware in .NET Core to check and hide parts of API requests, you need to have the right tools and basic understanding. Here's what you need:

1. You will need the Visual Studio code

2. You will need a .NET framework

3. You will need the postman for testing

!! Important Note !!

If you have all the tools and setup ready, you can skip the installation steps. Go straight to the Middleware Design and Workflow section to learn how to make it work and how middleware handles requests and responses.

Setting up Visual Studio Code

Visual Studio Code (VS Code) is a small, free code-writing tool made by Microsoft. Many developers use it because it is flexible, fast, and works with many coding languages. VS Code runs well on Windows, macOS, and Linux.

Key features of Visual Studio Code include:

Extensibility: A considerable store of add-ons for languages, frameworks, and tools.

Built-in Git Integration: This makes working together and tracking changes easier.

Intelligent Code Editing: Gives IntelliSense for competent code help, color-coded text, and problem-finding.

Customizability: This lets you change looks, keyboard shortcuts, and workspace settings to match what you like.

Visual Studio Code is a small editor with strong abilities and has become popular with developers who make different things, from websites to cloud programs.

Type Visual Studio code download into Google and click the first link.

On the next page, you must pick which matches your computer type. I will pick Mac and get it.

You will find the file in your downloads folder when it finishes downloading. You need to open it by clicking on the zip file.

Setting up .Net Framework

Microsoft's .NET Framework is a strong and complete software building system, mainly for creating and running Windows programs. It gives a controlled setting with many valuable tools and libraries, letting developers make different programs, including desktop, web, and server programs.

Key components of the .NET Framework include:

1. Common Language Runtime (CLR): The main engine that controls program running, memory, cleaning unused data, and safety.

2. Base Class Library (BCL): A set of ready-to-use tools and libraries for everyday tasks like working with files, databases, and XML.

3. Language Support: Works with many coding languages, like C#, VB.NET, and F#, making developers' choices easier.

In 2002, the .NET Framework changed Windows program building by making things like memory control and safety setup easier. Over time, newer systems like .NET Core and .NET 5/6/7/8/9 have come after it, focusing on better speed, growth ability, and support for Windows, macOS, and Linux. Even with these changes, the .NET Framework remains important for keeping old Windows programs working and ensuring older software runs well and stays stable.

Go to Install .NET on macOS Microsoft page and click on Download .Net

On the next page, let’s download .NET 8.0 (Long Term Support)

After selecting .NET 8.0, you must choose an option that matches your computer type. I will pick Arm64 because I have an M chip.

If you have an M chip computer, you should download Arm64; if not, download x64 instead.

When the download finishes correctly, you will find the package in your download folder

Now install the .NET framework. Open the package to begin installing and select Continue

On the next screen, you need to select Install

If you want to put it somewhere else, you can select Change Install Location.

When the installation finishes appropriately, you will see a screen and can end it by selecting Close

If everything works right, we can check the version in the terminal. Open a terminal and type dotnet --version.

Setting up Postman

Postman is a well-liked API-making and testing tool that makes building, testing, and handling APIs easier. It gives developers a simple way to work with APIs without writing complex code. You can get it as a computer program or use it in a web browser, which works on Windows, macOS, and Linux.

Key features of Postman include:

API Testing lets users send requests and look at answers in different forms like JSON and XML.

Automation: Works with JavaScript to write scripts and run tests by itself.

Collaboration: Let teams share their work, settings, and written guides.

Mock Servers: Creates fake API endpoints for building and testing.

With its many useful features and simple design, Postman has become an essential tool for making, fixing, and connecting APIs in many different types of work.

When we finish coding, we need to check our work, so we must download Postman. Pick the download option that matches your computer's chip.

Once the download finishes, you will find the zip file in your downloads folder

Click the zip file to start Postman

If you get asked Move to Application Folder, go ahead and move it

If everything works right, you will see this screen. We will not make an account now, so choose Continue without an account and keep going

On the next screen, select Open Lightweight API Client

If you did each step right, you should now see this form

Middleware Design and Workflow

Middleware in .NET Core helps manage API requests, letting developers check and change requests and responses at different points. When making middleware to filter and hide sensitive data, you need to plan what it will do, how it fits in, and how it handles requests.

In ASP.NET Core, middleware pieces work one after another to handle web requests coming in and going out. Middleware does two main things:

Intercepting Requests: Middleware grabs and works on requests as they come in. It can change the request, pass it on, or stop it.

Processing Responses: Middleware can also handle responses, letting developers change them before sending them back. Middleware that filters and hides sensitive data mainly focuses on catching and changing requests before they reach the main program. This keeps sensitive info safe as early as possible.

The middleware follows clear steps to handle requests well:

Intercepting Requests

The middleware catches every web request that comes in. At this point:

1. The HttpContext object lets you see request details, like headers, query strings, and what is in the request.

2. The middleware checks if the request has content that needs looking at (like POST or PUT requests with JSON data)

Filtering Requests

The middleware looks at the request content for sensitive data. This means:

1. Breaking down the request content (like JSON) into a format it can check.

2. Looking for sensitive info by comparing what is there with a list of words, patterns, or data types.

Masking or Deleting Data

If it finds sensitive data, the middleware hides it by putting placeholder text (like *****) instead. Alternatively, the middleware can remove the sensitive parts altogether.

{
  "username": "firat",
  "password": "verysecret",
  "ssn": "123456789"
}

The above JSON would be modified to

{
  "username": "firat",
  "password": "*****",
  "ssn": "*****"
}

After filtering and hiding, the middleware makes a new changed request:

1. The updated content is turned back into JSON.

2. The old request content has been replaced with new content.

3. The request moves on to the next middleware or handler. This ensures everything downstream gets a clean request, stopping any chance of showing sensitive data by accident.

Creating a New ASP.NET Core Web API Project

We are making an API project with middleware to change requests and responses.

Start by opening a terminal and run dotnet new webapi -n MiddlewareProcess

• dotnet new webapi is used to create a Web API project template

  -n <ProjectName> is used to give a name for the project

Execute code . to open the project in Visual Studio Code

When it is done correctly, you will see several project files

To test if it works, execute dotnet run and look for the port number your computer shows

You can visit http://localhost:5256/swagger/index.html in your browser

In Program.cs, you will find code for a Minimal API. This is something different we might learn later. You can delete it since we will not use Minimal API

app.MapGet("/weatherforecast", () =>
{
    var forecast =  Enumerable.Range(1, 5).Select(index =>
        new WeatherForecast
        (
            DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
            Random.Shared.Next(-20, 55),
            summaries[Random.Shared.Next(summaries.Length)]
        ))
        .ToArray();
    return forecast;
})

First, install the C# extension

After installing C#, make a new folder called Controller, then make a new C# file with any name you choose

Now, implement the API code in your new file

using Microsoft.AspNetCore.Mvc;

namespace MiddlewareExample.Controllers
{
    [ApiController]
    [Route("api/[controller]")]
    public class MiddlewareController : ControllerBase
    {
        [HttpGet]
        public IActionResult GetText()
        {
            return Ok("test");
        }
    }
}

[ApiController] indicates that the class is a controller and enables automatic binding and validation.

[Route("api/[controller]")] sets the web address to api/middleware (using the controller's name).

[HttpGet] specifies that this action method responds to HTTP GET requests.

GetText() is what we call this piece of code, which is not part of the web address itself, and it sends back the word test with a message 200 OK saying everything worked.

return Ok("test"); returns the string "test" in an OkObjectResult to indicate a successful response.

You also need to change Program.cs to make your controller work. Go to Program.cs and write builder.Services.AddControllers(); and app.MapControllers();

Program.cs should match what is shown below

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
// Learn more about configuring Swagger/OpenAPI at https://aka.ms/aspnetcore/swashbuckle
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();
builder.Services.AddControllers(); // Add this line 

var app = builder.Build();

// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
    app.UseSwagger();
    app.UseSwaggerUI();
}

app.UseHttpsRedirection();
app.MapControllers(); // add this line

app.Run();

Execute dotnet run after setting everything up and using Postman to send a request to http://localhost:{your port}/api/middleware

Now we know our controller and API work correctly. We need to make a list of words that we want to hide or remove. This list will help us filter content.

Make a new folder called Model, and inside it, make a new C# file called SensitiveData.cs.

Write your code precisely like what's shown below

public static class SensitiveData
{
    public static readonly List<string> Keywords = new()
    { 
        "password", 
        "ssn", 
        "creditCard", 
        "accountnumber"
    };
}

We use a static class because it holds information everyone shares, and we will not need to start the class.

Readonly makes sure the list cannot be changed.

Now, let us make our middleware class. Create a folder called Middleware and put a new C# file called FilteringMiddleware.cs in it

Let us begin writing our middleware class. We will start by adding the namespaces we need

using System.Text.Json;
using System.Text;

System.Text.Json has classes and tools for JSON data. It helps turn JSON data into C# objects we can use.

System.Text lets us read and write data streams. We need this to handle data coming into our program.

The next function will be RequestDelegate.

private readonly RequestDelegate _next;

The line private readonly RequestDelegate _next; is very important because it helps pass web requests to the next part of your ASP.NET Core program.

In ASP.NET Core, middleware uses a pattern called chain of responsibility. This means each request goes through a line of helpers, and each helper can either work on it or pass it along.

RequestDelegate is like a pointer showing which middleware is next in the request line.

We need two settings to help us hide or remove private information.

private readonly bool _maskSensitiveData;  
private readonly bool _removeSensitiveFields;

We'll make a starter (constructor) function for our middleware.

public RequestFilteringMiddleware(RequestDelegate next, bool maskSensitiveData = true, bool removeSensitiveFields = false)
{
   _next = next;
   _maskSensitiveData = maskSensitiveData;
   _removeSensitiveFields = removeSensitiveFields;
}

By default, maskSensitiveData will be set to true and removeSensitiveFields will be set to false.

RequestFilteringMiddleware starts up (constructor) when we make new middleware. ASP.NET Core calls it when we add app.UseMiddleware<RequestFilteringMiddleware>() to our program.

RequestDelegate next shows what comes next in line. ASP.NET Core gives us this information when it makes the middleware.

_next = next; saves the next step so we can use it later with _next(context).

Finally, we will make the core part that does the work. This runs every time a web request comes in.

public async Task InvokeAsync(HttpContext context)

HttpContext context represents all HTTP-specific information about the current request and response.

We will put our logic work into the InvokeAsync method to clean up or hide data. Here's how it works.

public async Task InvokeAsync(HttpContext context)
{
    if (context.Request.Method == HttpMethods.Post)
    {
        context.Request.EnableBuffering(); 

        using (var reader = new StreamReader(context.Request.Body, Encoding.UTF8, leaveOpen: true))
        {
            var body = await reader.ReadToEndAsync();
            context.Request.Body.Position = 0; 

            if (!string.IsNullOrWhiteSpace(body))
            {
                using (var jsonDocument = JsonDocument.Parse(body))
                {
                    var rootElement = jsonDocument.RootElement.Clone();
                    var filteredJson = ProcessJsonElement(rootElement);

                    var modifiedBody = JsonSerializer.Serialize(filteredJson);
                    var memoryStream = new MemoryStream(Encoding.UTF8.GetBytes(modifiedBody));
                    context.Request.Body = memoryStream;
                    context.Request.Body.Position = 0; 
                }
            }
        }
    }

    await _next(context);
}

Let’s look at each step

if (context.Request.Method == HttpMethods.Post)

This part makes sure we only work on POST requests.

context.Request.EnableBuffering();

This step is important because, normally, you can only read a request once in ASP.NET Core. EnableBuffering() let’s read it many times.

using (var reader = new StreamReader(context.Request.Body, Encoding.UTF8, leaveOpen: true))
{
    var body = await reader.ReadToEndAsync();
    context.Request.Body.Position = 0;
}

StreamReader helps us read the requested data as text.

await reader.ReadToEndAsync() gets all the data at once (asynchronously).

leaveOpen: true keeps the data available for others to use later.

context.Request.Body.Position = 0; goes back to the start so others can read the data, too.

using (var jsonDocument = JsonDocument.Parse(body))
{
    var rootElement = jsonDocument.RootElement.Clone();
}

JsonDocument.Parse(body) turns the text into a format we can work with.

RootElement.Clone() makes a copy we can change.

var filteredJson = ProcessJsonElement(rootElement);

ProcessJsonElement looks through the data and changes sensitive fields based on our rules.

var modifiedBody = JsonSerializer.Serialize(filteredJson);

It turns our changed data back into text using JsonSerializer.Serialize.

var memoryStream = new MemoryStream(Encoding.UTF8.GetBytes(modifiedBody));
context.Request.Body = memoryStream;
context.Request.Body.Position = 0;

MemoryStream puts our changed data in place of the original.

context.Request.Body.Position = 0 resets the stream position so endpoints or downstream middleware can read the processed body.

await _next(context);

It ensures the request continues to be processed after the middleware has completed its logic.

Now, we will make the ProcessJsonElement function. Here is how it looks.

private object ProcessJsonElement(JsonElement element)
{
    switch (element.ValueKind)
    {
        case JsonValueKind.Object:
            var processedObject = new Dictionary<string, object>();
            foreach (var property in element.EnumerateObject())
            {
                if (SensitiveData.Keywords.Contains(property.Name))
                {
                    if (_maskSensitiveData)
                    {
                        processedObject[property.Name] = "*****"; // Mask the sensitive value
                    }
                    else if (!_removeSensitiveFields)
                    {
                        processedObject[property.Name] = null; // Set sensitive value to null
                    }
                }
                else
                {
                    processedObject[property.Name] = ProcessJsonElement(property.Value);
                }
            }
            return processedObject;

        case JsonValueKind.Array:
            var processedArray = new List<object>();
            foreach (var item in element.EnumerateArray())
            {
                processedArray.Add(ProcessJsonElement(item));
            }
            return processedArray;

        case JsonValueKind.String:
            return element.GetString();

        case JsonValueKind.Number:
            return element.GetDouble();

        case JsonValueKind.True:
        case JsonValueKind.False:
            return element.GetBoolean();

        case JsonValueKind.Null:
        default:
            return null;
    }
}

Let’s investigate our code and understand the steps

case JsonValueKind.Object:
    var processedObject = new Dictionary<string, object>();
    foreach (var property in element.EnumerateObject())
    {
        if (SensitiveData.Keywords.Contains(property.Name))
        {
            if (_maskSensitiveData)
            {
                processedObject[property.Name] = "*****"; 
            }
            else if (!_removeSensitiveFields)
            {
                processedObject[property.Name] = null; 
            }
        }
        else
        {
            processedObject[property.Name] = ProcessJsonElement(property.Value);
        }
    }
return processedObject;

JSON can have layers inside layers, so we check every level for sensitive information.

Dictionary<string,object> is used to store the processed object.

EnumerateObject helps us look at property.Name and property.Value

SensitiveData.Keywords.Contains(property.Name) checks for sensitive

• Changes values to "*****" if _maskSensitiveData is true

• Makes values null if _maskSensitiveData is false and _removeSensitiveFields is false

• Takes out the whole piece if _removeSensitiveFields is true

return processedObject; gives back the processed data.

case JsonValueKind.Array:
 var processedArray = new List<object>();
 foreach (var item in element.EnumerateArray())
 {
   processedArray.Add(ProcessJsonElement(item));
 }
return processedArray;

JSON arrays can have nested objects inside, so we check everything.

case JsonValueKind.String:
return element.GetString();

JsonValueKind.String keeps primitive string values correctly included in the modified JSON without modification.

case JsonValueKind.Number:
return element.GetDouble();

JsonValueKind.Number keeps numerical values preserved in the modified JSON.

case JsonValueKind.True:
case JsonValueKind.False:
return element.GetBoolean();

JsonValueKind.True and JsonValueKind.False keep boolean values preserved in the modified JSON.

case JsonValueKind.Null:
default:
    return null;

JsonValueKind.Null handles empty values correctly.

We're done implementing our middleware. Now add app.UseMiddleware<RequestFilteringMiddleware>(false, true); to Program.cs. Your Program.cs should look like this.

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
// Learn more about configuring Swagger/OpenAPI at https://aka.ms/aspnetcore/swashbuckle
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();
builder.Services.AddControllers();

var app = builder.Build();

// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
    app.UseSwagger();
    app.UseSwaggerUI();
}

app.UseHttpsRedirection();

app.UseMiddleware<RequestFilteringMiddleware>(false, true);

app.MapControllers();

app.Run();

One more thing - we need to update our controller to send back what it gets. It should look like this.

using Microsoft.AspNetCore.Mvc;

namespace MiddlewareExample.Controllers
{
    [ApiController]
    [Route("api/[controller]")]
    public class RequestController : ControllerBase
    {
        [HttpPost]
        public IActionResult ReturnResponse([FromBody] Dictionary<string, object> requestData)
        {
            return Ok(new
            {
                Data = requestData
            });
        }
    }
}

We use Dictionary<string,object> because JSON data is structured as key-value pairs

Time to test our work. Here's what to do:

1. Run dotnet run

2. 

   Use Postman to make a request to http://localhost:{your port}/api/middleware

You can set your port in launchSettings.json

3. Click Body, pick raw then JSON. Use this test data.

{
    "data": {
        "user": {
            "name": {
                "first": "Firat",
                "last": "Tonak"
            },
            "email": "firattonak.com@firattonak.com",
            "ssn": "123-45-6789"
        },
        "order": {
            "paymentMethod": {
                "card": {
                    "accountnumber": "1111 222 3333 1111"
                }
            }
        }
    }
}

Let's start testing. First, set maskSensitiveData to true and removeSensitiveData to false in Program.cs

app.UseMiddleware<RequestFilteringMiddleware>(true, false);

After updating Program.cs, run dotnet run and try it. You should see this.

{
    "data": {
        "data": {
            "user": {
                "name": {
                    "first": "Firat",
                    "last": "Tonak"
                },
                "email": "firattonak.com@firattonak.com",
                "ssn": "*****"
            },
            "order": {
                "paymentMethod": {
                    "card": {
                        "accountnumber": "*****"
                    }
                }
            }
        }
    }
}

See how sensitive information is now masked.

Next, let's try removing sensitive information. Change Program.cs to this.

app.UseMiddleware<RequestFilteringMiddleware>(false, true);

Send another request, and you should see this.

{
    "data": {
        "data": {
            "user": {
                "name": {
                    "first": "Firat",
                    "last": "Tonak"
                },
                "email": "firattonak.com@firattonak.com"
            },
            "order": {
                "paymentMethod": {
                    "card": {}
                }
            }
        }
    }
}

Notice how sensitive information is now gone from the response.

The logic will work no matter how complex your response is.

Middleware is critical in today's API development, working as the primary system for handling and changing requests before they get to the main app code. When we use middleware to check and hide parts of requests, we fix two big problems in API safety: protecting private information and following data privacy rules like GDPR, HIPAA, and PCI-DSS. This helps developers reduce risks early, making people trust the systems they create.

Middleware for checking and hiding requests is a tool and a foundation for safe and strong API systems. Using this method creates a base for protecting data, following rules, and being reliable. However, it can do even more than that. By making innovative additions like recording hidden request data, adding tools to understand usage, or limiting how many requests can come in to stop misuse, this middleware can grow into a complete answer for what modern APIs need.

APIs are not fixed things; they get bigger, change, and face new problems in our always-changing digital world. Middleware becomes the quiet helper in this process, letting APIs change easily for new needs while staying safe and fast.

In the end, middleware is more than just computer code; it's a way of thinking about change, a promise to keep things safe, and a path to new ideas in API development.

You can access the code here

This guide is created to serve as a reference for future articles, and it focuses on the installation and setup.

What is Terraform?

Terraform is an infrastructure as code (IaC) tool that allows you to manage your resources through code. With Terraform, you can create and modify your infrastructure easily and efficiently.

Terraform provides:

1. An infrastructure-as-code approach that helps you create, modify, and delete your resources through code.

2. Automation of resource creation, modification, and destruction, which reduces direct human interaction with resources and minimizes the risk of human error.

3. Support for multiple cloud providers.

4. The ability to collaborate with your team by sharing Terraform files.

5. State management features that allow you to make and revert changes to your resources easily.

6. The capability to handle complex and large infrastructures.

Installing Terraform

Installing Terraform is a straightforward process that requires you to visit their website.

Follow the steps based on your operating system.

Since I use macOS, I selected Homebrew on macOS. Open a terminal and execute the command brew tap hashicorp/tap.

Then execute the command brew install hashicorp/tap/terraform.

After the installation is complete, run the command brew update, and then finally, execute brew upgrade hashicorp/tap/terraform.

Testing Terraform

After following all the steps, we should test Terraform to verify it’s working correctly. To do this, execute the command terraform -help. You should see the following output if Terraform is installed on your machine.

Configuring AWS for Terraform

We need to make sure that aws cli is installed on our computer before we start managing AWS resources. Let's install the aws cli by executing the command brew install awscli. You should see a similar output at the end of the process.

Then, let's verify the installation by executing the command aws --version.

Since we can see the version of the aws cli, we can run aws configure to configure AWS credentials. First, go to the AWS Management Console and create an Access Key and Secret Access Key. Search for IAM and select the first result.

Click on Users and then click on Create User

Enter a User name then click on Next

On the Set Permissions page, select Attach policies directly and search for AdministratorAccess. Assign it to the user, as we will need admin access to test our Terraform configuration. Then click on Next.

Review all the details and click on Create User if everything looks good.

If the process is successful, you should see the user in the list.

Now, we need to create an Access Key. To do this, click on the User Name, select Security Credentials, and then click on Create Access Key.

On the next page, select Command Line Interface (CLI) because we want to use the AWS CLI. Check the Confirmation box, then click on Next.

You can enter a description if you want, as it is optional, and then click on Create Access Key.

On the next page, you will see your Access Key and Secret Access Key. You must save these details because you will not see Secret Access Key again after clicking on Done. You can either download them or save them to a notepad.

Now, go back to the terminal and create a folder by executing the command mkdir <folder_name>. Navigate to the folder you just created and run code . to open it in VS Code.

Open a Terminal and execute the command aws configure, then enter your AWS credentials.

Let's go to Extensions in VS Code and install the HashiCorp Terraform extension.

Testing Terraform Configuration

Now, we can create a Terraform file and test our configuration to verify it's working. Create a file named main.tf and copy the following configuration code.

data "aws_ami" "linux"{
    most_recent = true

    filter{
        name = "name"
        values = ["amzn2-ami-hvm-*-x86_64-gp2"]
    }

    filter{
        name = "owner-id"
        values = ["137112412989"] # Amazon's official AMI owner ID
    }
}

resource "aws_instance" "ecommerce_server" {
  ami           = data.aws_ami.linux.id
  instance_type = "t2.micro"

    tags = {
    Name = "Terraform Test"
  }
}

Next, we need to execute these commands in sequence:

1. terraform init to initialize the configuration requirements

2. terraform plan to preview what will be created

3. terraform apply -auto-approve to create the EC2 instances

The -auto-approve flag allows us to skip the approval step after executing terraform apply. Without this flag, you would need to type yes when Terraform asks for approval.

Go to the AWS Management Console and check the EC2 instance list to verify the deployment.

If you can see Terraform Test in the instance list, it means our configuration is working, and we can use Terraform from now on to create our infrastructure on AWS.

We need to run the command terraform destroy -auto-approve to avoid additional costs.

In this article, we covered how to install and configure Terraform on macOS to manage AWS infrastructure. As a result, following these simple steps will help you set up Terraform and start managing AWS resources.

You can access the code here.

What is a Provisioner?

A provisioner is a mechanism that is used to execute commands or scripts on a resource after the resource has been created. It is part of the infrastructure deployment process, allowing you to install the necessary software or apply the required configurations.

There are three types of provisioners:

1. File Provisioner: Used to transfer files or directories from the local machine to a remote resource.

2. Remote-Exec Provisioner: Used to execute commands on the remote resource using SSH or WinRM, which is why the remote resource must support SSH or WinRM.

3. Local-Exec Provisioner: Used to execute commands on the local machine (the machine running Terraform).

File Provisioner

As we mentioned earlier, it is used to transfer files or directories from a local machine to remote resources.

Let's imagine we will create an e-commerce platform and want to host our backend on EC2 in AWS. We will need to define critical details such as database connections, payment gateway configurations, and so on for the backend server.

In this case, we need to use the File Provisioner to upload the configuration file from the local machine to the EC2 server.

We need to create a configuration file named ecommerce.conf and add some details to it.

[database]
host = "database info"
port = 1234
username = firat
password = firat1234

Our database configuration file is ready, and we can start writing the Terraform configuration code to create EC2 in AWS.

You can check how to configure AWS CLI if you have not.

Create a folder and move your configuration file under the folder because we want to keep the configuration file where our main.tf file is.

Now we need to write our EC2 configuration code and get started with fetching the latest Linux AMI. I will use Linux because it will not be charged for the operating system additionally.

We need a key pair for EC2 creation and connection. Please follow the steps here before moving forward.

Here is the data block configuration code.

# Get the latest Amazon Linux 2 AMI
data "aws_ami" "linux"{
    most_recent = true

    filter{
        name = "name"
        values = ["amzn2-ami-hvm-*-x86_64-gp2"]
    }

    filter{
        name = "owner-id"
        values = ["137112412989"] # Amazon's official AMI owner ID
    }
}

The filter is used to narrow down the results that come from the provider. You do not have to use it. It is optional.

name is a key that is used by the filter. For example, the result will be filtered by name. If you want to filter the result by architecture, then you need to create code like that below.

filter{
    name = "architecture"
    values = ["x86_64"]
}

If you want to learn more details about filters, you can visit here

Now, we are able to fetch the latest AMI , and it's time to create our EC2 instance. In this case, we will use the default security group that AWS provides us.

We need to make sure that our default security group allows SSH (port 22) from our IP address. If it allows All traffic, then you do not have to configure anything. However, keeping your security group as All traffic is not recommended.

Let's check our security group details first. Go to the EC2 page and hit the Security Groups on the left side.

Go to Inbound rules and hit Edit Inbound rules

Hit Add rule and add the line like the one below, and then hit Save rules

As I mentioned before, if your security group allows all traffic, you do not have to set up SSH. Let’s create an EC2 instance code.

resource "aws_instance" "ecommerce_server" {
  ami           = data.aws_ami.linux.id
  instance_type = "t2.micro"
  key_name      = "ProvisionerKeyPair"

  vpc_security_group_ids = ["sg-00138b47ec51588d2"] # the security group that we just created
  associate_public_ip_address = true # SSH does not work without public IP. this line ensures that EC2 gets a public IP.

  provisioner "file" {
    source      = "ecommerce.conf"
    destination = "/home/ec2-user/ecommerce.conf"

    connection {
      type        = "ssh"
      user        = "ec2-user"
      private_key = file("./ProvisionerKeyPair.pem")
      host        = self.public_ip
    }
  }

  tags = {
    Name = "EcommerceServer"
  }
}

We need to test our code after creation; that is why we need a public IP. We will use the out keyword to output the public IP.

output "ec2_instance_public_ip"{
    value = aws_instance.ecommerce_server.public_ip
}

Our configuration is ready now. We will execute terraform init, terraform plan, and terraform apply commands respectively and create an EC2 instance.

The entire code should be like the one below.

data "aws_ami" "linux"{
    most_recent = true

    filter{
        name = "name"
        values = ["amzn2-ami-hvm-*-x86_64-gp2"]
    }

    filter{
        name = "owner-id"
        values = ["137112412989"] # Amazon's official AMI owner ID
    }
}

resource "aws_instance" "ecommerce_server" {
  ami           = data.aws_ami.linux.id
  instance_type = "t2.micro"
  key_name      = "ProvisionerKeyPair"

  vpc_security_group_ids = ["sg-00138b47ec51588d2"] # the security group that we just created
  associate_public_ip_address = true # SSH does not work without public IP. this line ensures that EC2 gets a public IP.

  provisioner "file" {
    source      = "ecommerce.conf"
    destination = "/home/ec2-user/ecommerce.conf"

    connection {
      type        = "ssh"
      user        = "ec2-user"
      private_key = file("./ProvisionerKeyPair.pem")
      host        = self.public_ip
    }
  }

  tags = {
    Name = "EcommerceServer"
  }
}

output "ec2_instance_public_ip"{
    value = aws_instance.ecommerce_server.public_ip
}

Let's start with the terraform init command. You should see a similar following result when you execute the command.

Time to execute terraform plan and see what Terraform will create.

If you encounter an error like the one below, you need to give your user proper permissions. I will give AmazonEC2FullAccess in this article for now.

After configuring the permission issue, you should see the plan after you execute the terraform plan command. The plan shows all the details about what Terraform will do once you execute terraform apply.

Let's execute terraform apply and create our EC2 instance and upload the ecommerce.conf file. It will ask you a question like 'Do you want to perform these actions?' when you execute the code, and you need to type yes if you want to move forward.

Keep in mind that if you want to run terraform apply without any confirmation, you should use the -auto-approve flag.. More details

You should see a similar result once you have finished executing the terraform apply command.

We created our server and uploaded the configuration file. However, we should test our infrastructure and see the configuration file on the server.

First, let's check to see if the EC2 instance is created or not. You should see a server named EcommerceServer in the instances list.

If we are good with creating EC2 instances, let's go and check our configuration file. Now, we will try to connect to our EC2 instance. You need to give proper permissions again to your key pair file if you might run into the following error.

You need to execute chmod 400 and ssh -i ./ProvisionerKeyPair.pem ec2-user@<Your EC2 Public IP> respectively, and then you should see the result below.

You can access your EC2 server and you should check your configuration file by typing the dir command. It will list all files in the directory.

Now, let's check if the file is correct or not by checking what is inside. You need to execute the cat command to see the content of the file.

[ec2-user@ip-172-31-80-65 ~]$ cat ecommerce.conf
[database]
host = "database info"
port = 1234
username = firat
password = firat1234

If you are done with checking the details, you can execute the exit command to return to the local machine.

[ec2-user@ip-172-31-80-65 ~]$ exit
logout
Connection to 3.84.8.181 closed.

Local-Exec Provisioner

Local-exec command is used to run commands on the local machine where Terraform is working. It is useful for informing users, running scripts, logging information, and so on during the processes.

The important point is that you need to write local-exec in the resource definition block.

The scenario will be the same, and we want to create an EC2 instance on AWS. We will store the public IP of the EC2 instance in a text file after creation is done.

Let's create the resource code and execute terraform plan and terraform apply respectively.

resource "aws_instance" "ecommerce_server" {
  ami           = data.aws_ami.linux.id
  instance_type = "t2.micro"
  key_name      = "ProvisionerKeyPair"

  vpc_security_group_ids = ["sg-00138b47ec51588d2"] # the security group that we just created
  associate_public_ip_address = true # SSH does not work without public IP. this line ensures that EC2 gets a public IP.

  provisioner "local-exec"{
    command = "echo ${self.public_ip} > instance_public_ip.txt"
  }

  tags = {
    Name = "EcommerceServer"
  }
}

As you can see above, the resource code is almost the same. The only differences are that we removed the file provisioner implementation and wrote the local-exec implementation. However, you can implement both file and local-exec provisioners.

The final code should be like the one below.

data "aws_ami" "linux"{
    most_recent = true

    filter{
        name = "name"
        values = ["amzn2-ami-hvm-*-x86_64-gp2"]
    }

    filter{
        name = "owner-id"
        values = ["137112412989"] # Amazon's official AMI owner ID
    }
}

resource "aws_instance" "ecommerce_server" {
  ami           = data.aws_ami.linux.id
  instance_type = "t2.micro"
  key_name      = "ProvisionerKeyPair"

  vpc_security_group_ids = ["sg-00138b47ec51588d2"] # the security group that we just created
  associate_public_ip_address = true # SSH does not work without public IP. this line ensures that EC2 gets a public IP.

  provisioner "local-exec"{
    command = "echo ${self.public_ip} > instance_public_ip.txt"
  }

  tags = {
    Name = "EcommerceServer"
  }
}

You should see your EC2 instance after you execute the commands. If you see the EC2 instance, you should see the instance_public_ip.txt file in the directory where main.tf is located in the local-exec provisioner. You will see the IP address when you check the details of the txt file.

Remote-Exec Provisioner

Remote-exec provisioner is used to execute commands on a remote machine after your infrastructure has been created.

It is used to install software packages, configure services, run setup scripts, and so on.

You have to specify the connection details such as WinRM for Windows or SSH for Linux instances. Terraform needs connection details to make communication with the remote resource.

The scenario will be the same, and we want to create an EC2 instance. We will write "Hello from Terraform" into a text file after creation is done.

You can install the Apache server by following the codes, but you may face some additional costs.

sudo yum update -y # it updates the system packages
sudo yum install -y httpd # it installs Apache HTTP Server
sudo systemctl start httpd # it starts the Apache service
sudo systemctl enable httpd # it configures Apache to start on boot

Let's create a resource code for the EC2 instance and execute terraform plan and terraform apply respectively.

resource "aws_instance" "ecommerce_server" {
  ami           = data.aws_ami.linux.id
  instance_type = "t2.micro"
  key_name      = "ProvisionerKeyPair"

  connection {
        type = "ssh"
        user = "ec2-user"
        private_key = file("./ProvisionerKeyPair.pem")
        host = self.public_ip
    }

  provisioner "remote-exec"{
    inline = [ 
        "echo 'Hello from Terraform!' > /home/ec2-user/testfile.txt"
     ]
  }

  tags = {
    Name = "EcommerceServer"
  }
}

As you can see, we specify connection details like what we did for the file provisioner earlier and create a text file to store our message.

The final code should be like the one below.

data "aws_ami" "linux"{
    most_recent = true

    filter{
        name = "name"
        values = ["amzn2-ami-hvm-*-x86_64-gp2"]
    }

    filter{
        name = "owner-id"
        values = ["137112412989"] # Amazon's official AMI owner ID
    }
}

resource "aws_instance" "ecommerce_server" {
  ami           = data.aws_ami.linux.id
  instance_type = "t2.micro"
  key_name      = "ProvisionerKeyPair"

    connection {
        type = "ssh"
        user = "ec2-user"
        private_key = file("./ProvisionerKeyPair.pem")
        host = self.public_ip
    }

  provisioner "remote-exec"{
    inline = [ 
        "echo 'Hello from Terraform!' > /home/ec2-user/testfile.txt"
     ]
  }

  tags = {
    Name = "EcommerceServer"
  }
}

output "server_public_IP" {
  value = aws_instance.ecommerce_server.public_ip
}

You should see the EC2 instance in the list on the AWS management console.

If you execute the following command, you will connect to your EC2 instance that you just created.

ssh -i ProvisionerKeyPair.pem ec2-user@<Your EC2 Public IP>

Let's check to see if our message is stored on the server or not. We need to use the cat command to see the details.

cat /home/ec2-user/testfile.txt

When Keyword

The When keyword is used to tell the provisioner when it should run. The keyword is for the local-exec provisioner and remote-exec provisioner. You cannot use it for the file provisioner.

Let's use the keyword and learn how to use it. local-exec will be used for it. You need to add the when keyword in the provisioner and decide when the provisioner should run. I will define when = "destroy" and execute the terraform apply command.

As you can see, the EC2 has been created but there is no text file in the directory. Let's destroy the EC2 using terraform destroy and see if the text file has been created or not.

As you can see above, the text file has been created after the destroy process.

We checked on how to use Provider in Terraform with examples. You can use the details according to your needs or projects. If we summarize what we did:

1. If you want to upload a file, you need to use the file provisioner

2. If you want to execute a command on the local machine where Terraform is working, you need to use the local-exec provisioner

3. If you want to execute a command on a remote resource after the infrastructure has been created, you need to use the remote-exec provisioner

Since the article is for educational purposes, we should execute the terraform destroy command before we leave to avoid additional costs.

You can access the entire code here.

This article will set up a key pair using the AWS Management Console. Setting up a key pair does not require any coding skills. By the end of this article, you will learn how to create a key pair and how to connect to your EC2 instance.

Please ensure that you have a valid AWS account before proceeding with this article.

Go to the AWS Management Console, search for EC2, and select the first option in the results list.

On this page, select Key Pairs under Network & Security, then click Create key pair.

Now, we will enter details for setting up a key pair.

The Name field is where you enter your key pair name.

There are two different types of key pairs:

1. RSA: A cryptographic system that uses public and private keys for secure communication and authentication in systems.

2. ED25519: A modern public-key cryptography algorithm that offers high performance and security. Its key size is smaller than RSA.

There are two different types of file formats:

1. .pem is for SSH

2. .ppk is for PuTTY

Enter your details as shown below and click Create key pair.

You should see the key pair in the list, and it will be downloaded automatically.

Note that you must keep it safe.

Let's create an EC2 instance and verify that our key pair is working.

Go to EC2 on the AWS Management Console, click Instances, and then click Launch instances.

Since we'll use the Free tier in this article, select the t2.micro instance type. Then, select the key pair you just created and click Launch instance.

We will not cover all EC2 details in this article.

After the process is complete, you should see your EC2 instance on the list.

Now, we'll learn how to connect to our EC2 instance using the key pair. Let's open a Terminal.

We must set the correct permissions for our key pair file AWSKeyPair.pem by executing the chmod 400 command.

chmod 400 ~/Downloads/AWSKeyPair.pem

After setting permissions, we need to get our EC2's public IP. Go to the AWS Management Console and find the Public IPv4 address on the Instances page under Details.

Execute the following command using the Public IP.

ssh -i ~/Downloads/AWSKeyPair.pem ec2-user@54.196.249.211

After executing the command, you'll receive a connection verification prompt. Type yes, and if successful, you'll see the EC2 console.

Following these steps, you can create a key pair and connect to your EC2 instance. A key pair ensures that only you can access the instance, so keep your .pem file secure and never share it. You can now use this knowledge for key pair management and EC2 creation in your projects.

Please ensure that you have a valid AWS account before proceeding with this article.

Go to your AWS Management Console and search for IAM.

Click on Users in the menu on the left side, then click the Create user button.

Enter a user name and click the Next button.

Click the Next button again

Create the user by clicking the Create user button.

Then go to the user you just created, select Security credentials from the menu, and click Create access key

Select the following options and click the Next button

Enter a description if you want (it's optional), then click Create access key

You now have an Access Key and a Secret Access Key. If you want, you can download them by clicking Download .csv file to save it to your machine.

Make sure to save the Access Key details somewhere because you will never be able to see the Secret Access Key again after you click the Done button.

Now, it's time to configure the AWS CLI in the terminal. Execute the aws configure command and enter the following details.

Now, you're ready to run your Terraform configuration codes for AWS. If you have properly configured the AWS CLI with access keys and secrets, you can integrate your Terraform code with AWS efficiently and securely.

We use specifiers to manage the accessibility of our classes and methods. There are four different types of specifiers: public, private, protected, internal, and protected internal.

Public Specifier

The public specifier is accessible at all levels of the project.

An important point is that the public specifier can also be accessed by other assemblies when your DLL is referenced.

Product.cs

namespace Specifiers;

public class Product
{
    private string? _productName;
    public string? ProductName
    {
        get { return _productName; }
        set { _productName = value; }
    }
    public string GetProductName()
    {
        return ProductName ?? "";
    }
}

Program.cs

Product newProduct = new Product();
newProduct.ProductName = "Test Product";
newProduct.GetProductName();

As you can see, we can access the public methods and fields anywhere in the project.

Private Specifier

The private specifier is accessible only within the class where it is defined.

The private specifier cannot be accessed by other assemblies, even when your DLL is referenced.

Product.cs

namespace Specifiers;

public class Product
{
    private string? _productName;
    public string? ProductName
    {
        get { return _productName; }
        set { _productName = value; }
    }
    public string GetProductName()
    {
        if (!IsProductAvailable())
        {
        return "Product is not available";
        }
        return ProductName ?? "";
    }

    private bool IsProductAvailable()
    {
        return false;
    }
}

As you can see, we cannot access the private method in Program.cs. However, we can access the private method in Product.cs

Protected Specifier

The protected specifier can be accessed within the same class and in derived classes.

If your derived class is in another assembly, your protected methods are still accessible.

Product.cs

namespace Specifiers;

public class Product
{
    private string? _productName;
    public string? ProductName
    {
        get { return _productName; }
        set { _productName = value; }
    }

    private decimal? _productPrice;
    public decimal? ProductPrice
    {
        get { return _productPrice; }
        set { _productPrice = value; }
    }

    private bool? _productStatus;
    public bool? ProductStatus
    {
        get { return _productStatus; }
        set { _productStatus = value; }
    }
    public string GetProductName()
    {
        if (!CheckProductIsAvailable())
        {
        return "Product is not available";
        }
        return ProductName ?? "";
    }

    private bool IsProductAvailable()
    {
        return false;
    }

    protected bool? GetProductStatus()
    {
        return _productStatus;
    }
}

As you can see, we cannot access the GetProductStatus method in the Program.cs file.

However, when I make the Product.cs class abstract, we can access the protected methods in the derived class.

Product.cs

namespace Specifiers;

public abstract class Product
{
    private string? _productName;
    public string? ProductName
    {
        get { return _productName; }
        set { _productName = value; }
    }

    private decimal? _productPrice;
    public decimal? ProductPrice
    {
        get { return _productPrice; }
        set { _productPrice = value; }
    }

    private bool? _productStatus;
    public bool? ProductStatus
    {
        get { return _productStatus; }
        set { _productStatus = value; }
    }
    public string GetProductName()
    {
        if (!IsProductAvailable())
        {
        return "Product is not available";
        }
        return ProductName ?? "";
    }

    private bool IsProductAvailable()
    {
        return false;
    }

    protected virtual bool? GetProductStatus()
    {
        return _productStatus;
    }
}

Computer.cs

namespace Specifiers;

public class Computer : Product
{
    protected override bool? GetProductStatus()
    {
    return base.GetProductStatus();
    }
}

Internal Specifier

The internal specifier can be accessed anywhere within the project.

The internal specifier cannot be accessed by other assemblies, even when your DLL is referenced.

Product.cs

namespace Specifiers;

public abstract class Product
{
    private string? _productName;
    public string? ProductName
    {
        get { return _productName; }
        set { _productName = value; }
    }

    private decimal? _productPrice;
    public decimal? ProductPrice
    {
        get { return _productPrice; }
        set { _productPrice = value; }
    }

    private bool? _productStatus;
    public bool? ProductStatus
    {
        get { return _productStatus; }
        set { _productStatus = value; }
    }
    public string GetProductName()
    {
        if (!IsProductAvailable())
        {
        return "Product is not available";
        }
        return ProductName ?? "";
    }

    private bool IsProductAvailable()
    {
        return false;
    }

    protected virtual bool? GetProductStatus()
    {
        return _productStatus;
    }

    internal decimal? GetProductPrice()
    {
        return ProductPrice ?? 0;
    }

}

Program.cs

using Specifiers;

Product computer = new Computer();
computer.ProductPrice = 150;
computer.GetProductPrice();

ProtectedInternal Specifier

The protectedInternal specifier is accessible at all levels within the project, as well as by other assemblies when your DLL is referenced.

If your derived class is in another assembly, your protectedInternal methods are accessible.

I have tried to explain the different types of specifiers in C# and why they are needed.

I did not include an example of the protectedInternal specifier because it is very similar to the public specifier. The only difference is that while the public specifier is accessible everywhere, including in other assemblies and external code, the protectedInternal specifier cannot be accessed by external code in other assemblies."

You can reach the code here

You can find more details about try-catch block here

I assume that you have already created a Web API project for implementation. If so, your project structure should look as follows:

Let’s create a folder named Exceptions where we will develop custom exception classes. These classes will inherit from the Exception class.

The first one will be BadRequestException, which will inherit from the Exception class in the System namespace.

namespace ExceptionHandlingInMiddleware.Exceptions;

public class BadRequestException : Exception
{
    public BadRequestException(string message) : base(message)
    {

    }
}

The second one will be NotFoundException

namespace ExceptionHandlingInMiddleware.Exceptions;

public class NotFoundException : Exception
{
    public NotFoundException(string message):base(message)
    {

    }
}

The third one will be NotImplementedException

namespace ExceptionHandlingInMiddleware.Exceptions;

public class NotImplementedException : Exception
{
    public NotImplementedException(string message) : base(message)
    {

    }
}

The last one will be UnauthorizedException

namespace ExceptionHandlingInMiddleware.Exceptions;

public class UnauthorizedException:Exception
{
    public UnauthorizedException(string message):base(message)
    {

    }
}

Now that we have finished creating the custom exception classes, you can still create additional custom exception classes if needed.

After creating all the classes, your structure should look as follows:

Now, we need to integrate our exceptions into middleware. To do this, we will create a folder named Configurations, where we will implement our middleware and utilize it in the Program.cs file.

After creating the folder, we will create a middleware class named ExceptionMiddlewareConfiguration and begin implementing it.

First, we will add a request delegate to intercept the request pipeline. For more details about the request pipeline, refer to the following:

namespace ExceptionHandlingInMiddleware.Configurations;

public class ExceptionMiddlewareConfiguration
{
    private readonly RequestDelegate _next;
    public ExceptionMiddlewareConfiguration(RequestDelegate next)
    {
    _next = next;
    }

    public async Task Invoke(HttpContext context)
    {
        try
        {
            await _next(context);
        }
        catch (Exception excp)
        {
        // we will implement exceptions here
        }
    }

}

Next, we need to check the type of exception being passed and determine the appropriate status code to return.

using ExceptionHandlingInMiddleware.Exceptions;
using System.Net;
using System.Text.Json;

namespace ExceptionHandlingInMiddleware.Configurations;

public class ExceptionMiddlewareConfiguration
{
    private readonly RequestDelegate _next;
    public ExceptionMiddlewareConfiguration(RequestDelegate next)
    {
        _next = next;
    }

    public async Task Invoke(HttpContext context)
    {
        try
        {
            await _next(context);
        }
        catch (Exception excp)
        {
            await ExceptionAsync(context, excp);
        }
    }

    private static Task ExceptionAsync(HttpContext context, Exception ex)
    {
    // Here, the HTTP codes will be determined based on exceptions
        HttpStatusCode statusCode;
        string message = "Unexpected error";

        // We need to identify the type of the exception
        var excpType = ex.GetType();

        // Let's check what kind of exceptions are passed
        if (excpType == typeof(BadRequestException))
        {
            statusCode = HttpStatusCode.BadRequest;
            message = ex.Message;
        }
        else if (excpType == typeof(NotFoundException))
        {
            statusCode = HttpStatusCode.NotFound;
            message = ex.Message;
        }
        else if (excpType == typeof(Exceptions.NotImplementedException))
        {
            statusCode = HttpStatusCode.NotImplemented;
            message = ex.Message;
        }
        else if (excpType == typeof(UnauthorizedException))
        {
            statusCode = HttpStatusCode.Unauthorized;
            message = ex.Message;
        }
        else
        {
            statusCode = HttpStatusCode.InternalServerError;
            message = ex.Message;
        }

        var result = JsonSerializer.Serialize(new { message = message });
        context.Response.ContentType = "application/json";
        context.Response.StatusCode = (int)statusCode;

        return context.Response.WriteAsync(result);

    }
}

As shown above, we can check the type of exception and return the appropriate status code.

Now, we need to inject our middleware class into the Program.cs file.

To do this, let’s create a static class named ApplicationBuilderConfiguration under the Configurations folder.

namespace ExceptionHandlingInMiddleware.Configurations;

public static class ApplicationBuilderConfiguration
{
    public static IApplicationBuilder ErrorHandler(this IApplicationBuilder applicationBuilder) => applicationBuilder.UseMiddleware();
}

Next, we need to call the ApplicationBuilderConfiguration static class after Add.MapController() in the Program.cs file.using ExceptionHandlingInMiddleware.Configurations;

var builder = WebApplication.CreateBuilder(args);

// Add services to the container

builder.Services.AddControllers();
// Learn more about configuring Swagger/OpenAPI at https://aka.ms/aspnetcore/swashbuckle
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

var app = builder.Build();

// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
    app.UseSwagger();
    app.UseSwaggerUI();
}

app.UseHttpsRedirection();

app.UseAuthorization();

app.MapControllers();

app.ErrorHandler();

app.Run();

Now, it’s time to test our exception handling implementation. Let’s create a controller called TestController and implement an HttpGet API.

using ExceptionHandlingInMiddleware.Exceptions;
using Microsoft.AspNetCore.Mvc;
using NotImplementedException = ExceptionHandlingInMiddleware.Exceptions.NotImplementedException;

namespace ExceptionHandlingInMiddleware.Controllers
{
    [Route("api/[controller]")]
    [ApiController]
    public class TestController : ControllerBase
    {
        public TestController()
        {

        }
        [HttpGet]
        [Route("TestExceptions")]
        public IActionResult TestExceptions(int number)
        {
            CheckTheNumber(number);
            return Ok();
        }

        private void CheckTheNumber(int number)
        {
            if (number == 1)
            {
                throw new BadRequestException("Number = 1 is the bad request exception");
            }
            else if (number == 2)
            {
                throw new NotFoundException("Number = 2 is the Not found exception");
            }
            else if (number == 3)
            {
                throw new NotImplementedException("Number = 3 is the Not implemented exception");
            }
            else if (number == 4)
            {
                throw new UnauthorizedException("Number = 4 is the unauthorized exception");
            }
        }

    }
}

As you can see below, the exceptions are working as expected.

When the number is 1

When the number is 2

When the number is 3

When the number is 4

Additionally, you can implement a default response type to inform consumers of the API.

Simply use ProducesResponseType to define the response type for a controller, as shown below:

using ExceptionHandlingInMiddleware.Exceptions;
using Microsoft.AspNetCore.Mvc;
using NotImplementedException = ExceptionHandlingInMiddleware.Exceptions.NotImplementedException;

namespace ExceptionHandlingInMiddleware.Controllers
{
    [Route("api/[controller]")]
    [ApiController]
    public class TestController : ControllerBase
    {
        public TestController()
        {

        }
        [HttpGet]
        [Route("TestExceptions")]
        [ProducesResponseType(StatusCodes.Status200OK)]
        [ProducesResponseType(StatusCodes.Status400BadRequest)]
        [ProducesResponseType(StatusCodes.Status404NotFound)]
        [ProducesResponseType(StatusCodes.Status501NotImplemented)]
        [ProducesResponseType(StatusCodes.Status401Unauthorized)]
        public IActionResult TestExceptions(int number)
        {
            CheckTheNumber(number);
            return Ok();
        }

        private void CheckTheNumber(int number)
        {
            if (number == 1)
            {
                throw new BadRequestException("Number = 1 is the bad request exception");
            }
            else if (number == 2)
            {
                throw new NotFoundException("Number = 2 is the Not found exception");
            }
            else if (number == 3)
            {
                throw new NotImplementedException("Number = 3 is the Not implemented exception");
            }
            else if (number == 4)
            {
                throw new UnauthorizedException("Number = 4 is the unauthorized exception");
            }
        }
    }
}

This way, users can understand what kind of response type they might expect from the API.

Note that if you want to pass an object through a custom exception model, you need to change the parameter type from string to object. This will allow you to pass your model as the response type.

You can check the code below:

namespace ExceptionHandlingInMiddleware.Exceptions;

public class BadRequestException : Exception
{
    public BadRequestException(object message) : base(message.ToString())
    {

    }
}

In conclusion, implementing global exception handling in ASP.NET Core middleware is a crucial step in enhancing the robustness and reliability of your applications. By creating custom exception classes and integrating them into middleware, you can efficiently manage errors and provide clear, consistent responses to API consumers.

This approach not only simplifies error handling but also improves the overall user experience by ensuring that exceptions are handled gracefully and appropriately. As demonstrated, the process is straightforward and can be tailored to meet specific application needs, allowing for scalable and maintainable error management solutions.

You can refer to the code here.

• Try block: Any errors that occur within the try block trigger a transfer of control to the catch block.

• Catch block: In the catch block, we define the logic for handling errors, which may include returning error messages or logging.

• Finally block: The code in the finally block is executed regardless of whether an exception occurs, making it the ideal place to implement finalization logic.

try
{
    int first = 0;
    int second = 0;

    int result = first / second;
}
catch (Exception excp)
{
    Console.WriteLine("Divide by zero error :\n"+excp.ToString());
}
finally
{
    Console.WriteLine("\nWe got an error and need to change the logic here");
}

Indeed, as evident from the preceding explanation, when an error occurs, the try block directs the code flow to the catch block, which in turn directs it to the finally block.

One common source of confusion in exception handling is whether it’s possible to use multiple catch blocks. The answer is affirmative; you can have multiple catch blocks, but only one of them will be executed, depending on the type of exception that matches the error encountered.

Another area of confusion in exception handling revolves around whether it’s permissible to use only a try block without incorporating a catch block. The answer is affirmative; you can use a try block by itself, but it is obligatory to include a finally block as part of the structure.

The final aspect to consider in exception handling is distinguishing between “throw ex” and “throw.” This distinction is crucial for pinpointing the exact source of the issue.

When you employ the throw keyword, it allows you to identify the precise line responsible for the problem while throw ex rethrows the exception, potentially losing the original stack trace.

try
{
    DivideZero(); // line 25
}
catch (Exception excp)
{    
    Console.WriteLine(excp.StackTrace);
}

void DivideZero()
{
    try
    {
        int first = 0;
        int second = 0;

        int result = first / second; // line 39
    }
    catch (Exception excp)
    {
        throw;
    }
}

The line number may vary depending on your specific environment and configuration.

When you use throw ex, it will indicate the line where the throw ex keyword is located, potentially masking the original line number where the exception was initially thrown. This can make it harder to trace the root cause of the issue. To preserve the original stack trace, it's better to use throw without the ex keyword.

try
{
    DivideZero(); // line 25
}
catch (Exception excp)
{
    Console.WriteLine(excp.StackTrace);
}

void DivideZero()
{
    try
    {
        int first = 0;
        int second = 0;

        int result = first / second;
    }
    catch (Exception excp)
    {
        throw excp;// line 43
    }
}

This is why throw should be preferred over throw ex.

It’s important to emphasize that error handling should be implemented at a higher level rather than at a lower level. When error handling is implemented at the lower level, it becomes impossible to catch errors that occur at the higher level. Conversely, by implementing error handling at the higher level, errors can be captured wherever they occur in the code.

In conclusion, understanding and implementing effective error handling in C# is essential for developing robust and reliable software applications.

By utilizing try-catch-finally blocks, developers can manage exceptions gracefully, ensuring that applications can handle unexpected situations without crashing.

The ability to use multiple catch blocks allows for specific handling of different exception types, while the distinction between throw and throw ex is crucial for maintaining accurate stack traces. Prioritizing error handling at a higher level in the code structure further enhances the application's stability. By mastering these techniques, developers can significantly improve the quality and resilience of their software solutions.

To access the accompanying code, please follow the provided link.