DEV Community: Eduard Stefanescu

ASP.NET Core Swagger Documentation with Bearer Authentication

Eduard Stefanescu — Sat, 15 Jan 2022 08:55:26 +0000

Originally published at https://eduardstefanescu.dev on January 15, 2022.

In the previous article, we added Swagger Documentation to an existing ASP.NET Core project. This article will use the previous article and the JWT Authentication Symmetric Key source code to add to a project that already have Swagger Documentation the Authentication feature. These two article can be found here:

The Swagger Documentation Authentication feature will be introduced briefly in the first section of this article, and its implementation will be discussed in the second section.

Introduction

As is described in the previous article, Swagger Documentation is a handy tool that generates documentation in a friendly manner from an XML file generated by the .NET Framework. But what if the described API has authentication, then the documentation should have it too. Swashbuckle.AspNetCore.SwaggerGen package provides the authentication feature, but this article will cover only the Bearer Authentication setup.

The Swagger Documentation web interface will act as a REST Client, by sending a request to the Authentication endpoint, receiving the Bearer Authentication Token, and then, with this token, we'll have to put it into an input box in order to set the authentication header for the next requests that we'll be making.

Adding the Security Definition

By specifying the security definition, Swagger will take into account that it will have to add the authorization feature. This feature consists of an “Authorize” button at the top of the page that will set the authorization header. The following code will be added in the AddSwaggerGen extension method of the SwaggerGen package.



options.AddSecurityDefinition(name: "Bearer", securityScheme: new OpenApiSecurityScheme
{
    Name = "Authorization",
    Description = "Enter the Bearer Authorization string as following: `Bearer Generated-JWT-Token`",
    In = ParameterLocation.Header,
    Type = SecuritySchemeType.ApiKey,
    Scheme = "Bearer"
});

Name refers to the name of the header; in this case, the request includes the Authentication header followed by the Bearer Token (i.e., Authorization: Bearer Generated-JWT-Token);
Description is used to help others understand how the authentication works and what value he or she has to enter in the input box;
In refers to the location of the ApiKey, which in this case will be in the Header. For other authentication types, there might be other options, like query or cookie;
Type is the security scheme that we'll be using;
Scheme is the RFC7235 Hyper Transfer Protocol, that will be used. In this case, we’ll be using the Bearer protocol, but this property also accepts all the other protocols that can be found here: https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml;

This five parameters are required in order to define how the security key will act.

Adding the Security Requirement

The AddSecurityRequirement extension method will add an authorization header to each endpoint when the request is sent. This method takes a dictionary of type Dictionary as a parameter, because the endpoints can have different authentication types (e.g. Basic, Saml). The value of the dictionary is a required list of scope names for the execution only if the security scheme is oauth2 or openIdConnect. In our case, this list will be an empty one [1].



options.AddSecurityRequirement(new OpenApiSecurityRequirement
{
    {
        new OpenApiSecurityScheme
        {
            Name = "Bearer",
            In = ParameterLocation.Header,
            Reference = new OpenApiReference
            {
                Id = "Bearer",
                Type = ReferenceType.SecurityScheme
            }
        },
        new List<string>()
    }
});

The parameters above are required to setup the Security Requirement, but there are more. So Microsoft did a great job by defining all these fields and properties on the OpenAPI.NET GitHub page [2] [3].

The result

The Swagger Documentation API page, can be accessed locally using the following URL: http://localhost:5000/swagger/index.html. In the top part of this page, you will notice the “Authorize” button, as in the picture below.

This button will open a pop-up window, where we’ll enter the Bearer Token in order to set the Authorization header. But before doing this, let’s first get the JWT Token from the Authentication endpoint.

Authenticating

By opening the Authentication endpoint block from the Swagger Documentation, we can notice an open padlock in the top right corner of the endpoint, representing that there is no Authorization header set yet.

In this opened block, the Try Out button must be clicked in order to open the request section; where the valid username and password should be entered to generate the JWT Token. Otherwise the response code will be Unauthorized, or depending on your implementation it may not generate a valid Token.

In the picture above, we can see that after executing a valid request, the API responds with OK HTTP Status Code with a Body, that contains the needed Token.

Authorization

After generating the JWT Token, now this Token must be copied and we can return to the top of this page. Doing so, we should press the Authorize button, and a pop-up window should be displayed as in the picture below.

In the Value input box the Authorization header will be set. Firstly as is described in description we need to specify the security scheme, in this case Bearer and after that generated the JWT Token. Then press the Authorize button and close this window to test out if the authentication works.

Requesting an authorized resource

Now, after authenticating and authorization steps, we can test an endpoint that needs authorization. In this example, the WeatherForecast endpoint will be used. By opening it we can see, that the unlocked padlock is not locked, meaning that we are authorized.

In the picture above, is the response of the authorized endpoint. That returns the OK HTTP Status Code with all the available weather forecasts.

The source code from this article can be found on my GitHub account: https://github.com/StefanescuEduard/DotnetSwaggerDocumentation/tree/master/API.WithAuthentication.

Thanks for reading this article, if you find it interesting please share it with your colleagues and friends. Or if you find something that can be improved please let me know.

References

[1]https://github.com/microsoft/OpenAPI.NET/tree/master

[2]https://github.com/microsoft/OpenAPI.NET/blob/master/src/Microsoft.OpenApi/Models/OpenApiSecurityRequirement.cs

[3]https://github.com/microsoft/OpenAPI.NET/blob/master/src/Microsoft.OpenApi/Models/OpenApiSecurityScheme.cs

ASP.NET Core Swagger Documentation

Eduard Stefanescu — Wed, 25 Aug 2021 07:56:06 +0000

Originally published at https://eduardstefanescu.dev on August 25, 2021.

Romanian version at https://www.backto.tech/post/documentarea-codului-în-asp-net-core-folosind-swagger.

Documentation is one of the most effective methods for transferring knowledge about an entire project or a subset of it. The documentation can assist others in comprehending how it works and can also be used as a reference for when someone want to verify that his or her assumptions are right.

However, the primary advantage of documenting before or throughout the development process is that it can bring to light issues or ideas that no one else would have considered.

Thus, this article is about documentation using the Swagger framework; the first section provides an overview, while the second section details the actual implementation. A subsequent article will discuss Swagger documentation with Bearer Token authentication.

Introduction

Swagger is a component of the OpenAPI Initiative and can be used with a variety of other languages, including Java, Spring, and Python. And it includes a number of tools, like Swagger Hub, which can be used to define Web APIs without using a programming language to describe it; and Swagger Inspector, which is a tool for testing API endpoints. However, this article will focus on the Swagger Specification in conjunction with ASP.NET.

The Swagger Specification framework makes use of .NET generated documentation, which I will describe how to enable later, and a UI component that visually illustrates the Web API endpoints, which include the following:

HTTP method of request (e.g. GET, POST);
parameters and query parameters;
response codes (e.g., OK, NotFound);
a description of the endpoint, its parameters, and the type of return;

Prerequisites

For this article the default ASP.NET Core project was generated, that means the WeatherForecastController will be used in order to describe the API.

As was previously mentioned a file is needed by the Swagger Framework in order to create the documentation. So to generate this file, the GenerateDocumentationFile property in the ASP.NET Core project must be set to true.

<PropertyGroup>
  <GenerateDocumentationFile>true</GenerateDocumentationFile>
</PropertyGroup>

By enabling this in the project’s settings file (i.e. csproj), then when the project is being built, the compiler will search for the XML comments and will generate an XML file containing all the written comments [1], in the following format.

<doc>
    <assembly>
        <name>API.WithoutAuthentication</name>
    </assembly>
    <members>
      <member name="T:API.WithoutAuthentication.Controllers.WeatherForecastController">
          <summary>
          List the weather forecasts.
          </summary>
      </member>
    </members>
</doc>

We don’t need to worry too much with the look of this XML file; it’s simply for demonstration purposes.

In the top part, the assembly name is found, meaning that if there are multiple projects, then there will be an XML file for each of them, but only if the GenerateDocumentationFile is enabled.

And then all the members that have XML comments are listed. Only the constructor of the WeatherForecastController class is described in this case, along with a brief summary. However, if the description had been long, comprising many keys such as param or response, they would have been included as well.

After enabling this property and rebuilding the project, a few warnings will appear informing us that some type or members must be described, as shown in the image below.

These warnings are also from classes that don't need to be included in the API documentation, like the Startup or the Program classes, so in order to disable the warnings from these classes, the pragma preprocessor directive must be used, as described below.

#pragma warning disable 1591

The pragma directive takes a few parameters, so there is the pragma-name in this case the warnings that have to be disabled, and then the arguments: disable and 1591 [2]. The last argument is the warning number, which can be found in the Error List window.

Once the useless warnings are disabled, only the useful ones will be seen. In this from the WeatherForecastController class.

After generating the XML file and removing unnecessary warnings, two packages need to be installed in order to generate the Swagger documentation and to visualize it in a more readable way, using a Web page.

Writing XML comments

The XML comments needs to clear and to provide enough information in order for those who want to use the API to understand it without having doubts. There might be some misconceptions about writing comments, but in this case writing these comments will help others to understand what the endpoint does and how to use it, because in most cases they will not have access to the code.

Here are some popular websites that published their API Documentation:

Describing parameters

In the following code, there is a brief summary about what the constructor of the WeatherForecastController class does and the logger parameter.

// <summary>
/// Constructs the controller state.
/// </summary>
/// <param name="logger">Injected logger by the dependency injection container.</param>
public WeatherForecastController(ILogger<WeatherForecastController> logger)
{
    this.logger = logger;
}

This illustrates how the param tag can be set. If there are many parameters, then another param tag under the previous one has to be added [3].

Then in the code below, the returns and response tags are used for the /GET endpoint. These should be the minimum tags needed to be set on an endpoint in order to describe it in an understandable way.

/// <summary>
/// Get the weather forecast 
/// </summary>
/// <returns>Returns a list of five weather forecast elements, with random temperatures
/// between -20 and 55 degrees.</returns>
/// <response code="200">Returns the list of weather forecast elements.</response>
/// <response code="500">If an exception is thrown.</response>
[HttpGet]
public IActionResult Get()
{
    ...
}

Adding Swagger Service Generator

In the Startup class, the Swagger Service Generator must be added, in order to generate the swagger.json file that will be later parsed by a middleware component to display the documentation on a Web page.

For this step, I chose to create an extension method to keep the code organized, but all the code inside this method can be added directly into the Startup class via the ConfigureServices method.

public static IServiceCollection AddSwaggerDocumentation(this IServiceCollection services)
{
    services.AddSwaggerGen(options =>
    {
        options.SwaggerDoc(name: "acme",
            new OpenApiInfo { Title = "Acme API", Version = "v1" });

string xmlFile = $"{Assembly.GetExecutingAssembly().GetName().Name}.xml";
        string xmlFilePath = Path.Combine(AppContext.BaseDirectory, xmlFile);

options.IncludeXmlComments(xmlFilePath);
    });

return services;
}

In the above code, there are the minimum required options in order to generate the Swagger documentation.

On line 5 the API documentation is set up, with the name, title, and version. Then the XML file path of the current assembly is built and passed to the IncludeXmlComments method as a reference that will be used to generate the swagger.json file. All the available properties of the Service Generator can be found on the Swashbuckle.AspNetCore GitHub page https://git.io/JftOr.

Adding Swagger Middleware

As the Swagger Service Generator extension method, there is also one to add two middlewares, one for the Swagger Documentation and another one for the SwaggerUI. These two middlewares can also be added to the Startup class in the Configure method.

public static IApplicationBuilder UseSwaggerDocumentation(this IApplicationBuilder app)
{
    app.UseSwagger();
    app.UseSwaggerUI(options =>
    {
        options.SwaggerEndpoint("/swagger/acme/swagger.json", "Acme API v1");
        options.DocExpansion(DocExpansion.None);
    });

return app;
}

On line 3 the Swagger Documentation middleware is added, that will provide the swagger.json. And then the Swagger UI is added and configured, by specifying the path to the swagger.json file and the name that will be displayed at the top of the page. Please note that what is in between /swagger/ and /swagger.json is the name of the API Documentation that was previously set in the Swagger Generator Service, in this case, the name is acme. If the name is different, then the Swagger Web Page will display the following error.

On line 7 the Expansion option is set to None which will collapse all the API definitions when the Swagger Web Page is opened. This is more of a personal preference. I like to keep those definitions collapsed, because as the application grows, there will be dozens or hundreds of them.

The result

After doing all the above steps, the documentation web page can now be accessed by accessing http://localhost:5000/swagger/index.html. In the picture below is the landing page with the WeatherForecast panel open.

There is a Try it out button through which the endpoint can be tested, this is like testing the endpoint with Postman, Insomnia, or any other REST Client, but much more easily, without having to introduce anything. We’ll see that in the next article where the Bearer Authentication will be added, we’ll have to authenticate only once.

The source code from this article can be found on my GitHub account: https://github.com/StefanescuEduard/DotnetSwaggerDocumentation/tree/master/API.WithoutAuthentcation.

Thanks for reading this article. If you find it interesting, please share it with your colleagues and friends. Or if you find something that can be improved, please let me know.

References

[1] https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/xmldoc

[2] https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/preprocessor-directives/preprocessor-pragma

[3] https://docs.microsoft.com/en-us/dotnet/csharp/codedoc

Notes on Day 2 - The One with Dotnet @Codecamp Romania, 2021

Eduard Stefanescu — Fri, 02 Apr 2021 07:50:21 +0000

Originally published at https://eduardstefanescu.dev/2021/04/02/notes-on-day-2-the-one-with-dotnet-codecamp-romania-2021/

There was a small talk when Raffaele told us what he did in this corona time. So he started working with ML and also Code Generation driven by ML.

There was also a talk about how ML was involved in the industry. For example, every machine now starts having more user-friendly interfaces and through this more things can be automated to provide a much greater experience to end customers. And also to the factories that can apply ML to simulate a result before creating and applying those concepts.

Power your .NET application with the new generation of diagnostics - March 25 14:00 - 14:45 - Raffaele Rialdi

The session goal was to show how to automate the diagnostic process in production.

The first step was when to trigger a diagnostic with the DiagnosticClient library. And the second step was that once the data was captured, we can programmatically analyze the process that gave the problem with ClrMD 2.0 library.

Preemptive profiling or microbenchmark is used on dev machines to analyze specific lines of code that are not performing as expected, by using Benchmark.NET.

In production, the primary source of help are the logs. But those logs should not be too verbose but also not too short, for example containing too little information.

A dump can be a solution by using for example dotnet-dump, but it is not a tool for investigating problems, because the problem can be done after analyzing it, and catching the perfect moment is hard.

In production, the performance can be monitored with dotnet-trace, dotnet-counter and in .NET 5 we can use a new tool dotnet-monitor that can connect to remotely located and locally we can access it through a web interface.

There is also another problem with dumps because there might be sensitive data, for example, the application could be installed in a hospital, so those data can be constrained by privacy and EU regulation like GDPR.

The presented scenario was an ASP.NET Core application and many clients that use the app. There is also a console application used to stress the web service, that can make concurrent requests. The diagnostic application is receiving TraceEvents from the web service. This application uses two libraries: DiagnosticClient and ClrMD 2.0 (the investigating library, that grabs data). When an issue occurs a snapshot with the web service is created by this diagnostic app. By doing so we can capture the exact moment when the problem occurred.

The communication between web service and diag app is the communication that can be made with every .NET application starting with .NET Core 3.0.

The library recommended is https://github.com/raffaeler/PowerDiagnostics.

Diagnostic Demo app was used to capture snapshots and also run different queries to display the root cause of the problem. For example, discovering a big byte array that uses too much memory. Or querying duplicate strings, getting strings by size, list of modules or threads stacks.

The app can also load a dump saved before and that dump can be investigated as dump saved at the runtime.

.NET 5 introduces reversed communication protocol, which can be used to diagnose apps, like subscribing to them and when an event occurs, the diagnosis app can read them.

The (too) Many Faces of Architecture - March 25 15:00 - 15:45 - Mihaela Ghidersa

This presentation was a generic one about architecture, discussing different types of architecture.

Architecture is a technical solution that makes artistic or more abstract concepts materialize.

In the real world, architecture is creating a small module and combining both technical and business concepts into a big schema or structure.

The architecture can be seen as a blueprint. We should define what and why is significant.

The architect is not about the title, he or she has a flexible role, that can collaborate more than giving indications.

Telemetry in .NET distributed applications - March 25 16:00 - 16:45 - Constantin-Ariton Lazar / Mihai Detesan

The presentation was focusing on automotive telemetry by using Bosch sensors.

There was a comparison between the Monolith application and the new way of developing products with microservices.

One of a problem with microservices is with the coherence, which can be difficult to track because each microservice creates request between them. And for example, if an error occurred is a bit hard to know from where it comes.

And also another problem comes from debugging and is also difficult to locate.

In monolith application scaling represents adding more hardware resources, instead of on microservices scaling represents adding more instances of a specific or many microservices.

The "telemetry" word comes from Greek, tele = distance and metron = measure. The "sum" of this to words can be translated as a process of recording and transmitting some logs or reading of a sensor or even a machine.

OpenTelemtry is an observability framework that combines traces and metrics.

Jaeger and Zipkin were used for tracing.

To trace all microservices, each of them has a Trace Id that uniquely identifies each microservice.

The trace collector creates some sort of graph from all traces.

All the Trace IDs are sent from a microservice to another when creating a request, to know which microservice called another one.

The final id is composed of the Trace Id and the Parent Id.

Elasticsearch was used to store the logs with Timestamp, Service context like IP or the microservice name, the operation context like the stack trace, and the Trace Id.

What's New in C# - March 25 17:00 - 17:45 - Chris Sienkiewicz / Fred Silberberg

In C# there are top-level statements, before declaring usings, namespace, and declaring classes. And those lines are executed. The compiler will take it and put it in a form to execute it.
Even async calls will work in top-level statements because the main method that runs these lines is an async one.
For not including the namespace in the statements we can use using before them.
In top-level statements functions can also be declared. But the functions can be used only in the local top statements. So for example, if there are classes under, those top functions can't be called in.

Because var fields can't be used for declaring fields at the class level. Now those fields can be instantiated only by calling new().

The new keyword can also be used to instantiate a class without specifying the name.

To avoid overriding the not equal operator (!=) when checking for null, we can verify an object that is not null, by using exactly those keywords "is not null".

When comparing two objects to avoid overriding the Equals method, the class can be changed to a record, that represents a class type with value semantics, compares equality by value. This works only to type fields.
A record can be seen as a collection of values.

There is a new future called initialization only available only to record, which provides the ability to assign a property only once in the object initialization.

The with keyword provides non-destructive mutation, that creates a copy of the variable. So values can be set as a part of the initialization.

Records offer the possibility to add a property at the declaration level, similar to the constructor.

And the inheritance looks very similar to the constructor, without using the base keyword.

In C# 10 there can be some of the following futures:

The namespaces can be declared without braces.

The global keyword can be used with using to declare a variable or a namespace in a single place. This will make those declarations available all over other files.

Nullable types can be used in if.

There can be semi-auto properties that have a backing field, that doesn't need to be declared.

The records can be also structs (record struct), similar to the current record for classes.

There can be required properties that uses the required keyword that requires the user to set it.

The IAddable interface can be used to "override" the plus sign to perform add operation with which type is needed.

Recipe for Modern Applications: .NET, Azure SQL, Functions, Geospatial, JSON - March 25 18:00 - 18:45 - Anna Hoffman

The presentation was about creating an application to be notified when a bus arrives.

The data are imported from the public transportation data. Azure was used for all the below "pieces".

For the database, Azure SQL Database was used because it has the multi-model capability and also native geospatial support. And another important point of using Azure SQL Database is the feature of using JSON because the conversion is done automatically (from non-relational to relational).

Azure Data Studio looks very similar to Jupiter used for Python. It is a notebook where both code (SQL, Powershell) and documentation can be written.

There are geofences created to be notified when the bus enters them.

Overall, this was my first Code camp conference and also my first conference online. It was a nice experience, but it is not compared with a real-life conference, where you can see the presenters and even ask them questions after the session.
But if the corona still stays among us, these conferences are a great way to refresh your mind with what's new in technology and in .NET.

Notes on Day 1 — The One with Dotnet @Codecamp Romania, 2021

Eduard Stefanescu — Fri, 26 Mar 2021 07:53:56 +0000

Originally published at https://eduardstefanescu.dev/2021/03/26/notes-on-day-1-the-one-with-dotnet-codecamp-romania-2021/

13:45 - 14:00

The first conference day started with Dino Esposito discussing that it matters more the soft skills and the pragmatic way to approach problems rather than the used technology, like .NET.
In a sports business, the money comes from the data, that is applied to the sportsmen and women. All the things that we are seeing on TV look so simple, but all of them are based on data. "Data is gold".

Data Science is only an umbrella because we need engineering to apply the science and make it available. This definition of Science fits Machine Learning and all those technologies related to it.

(Data) Engineering vs (Data) Science - March 24 14:00 - 14:45 - Dino Esposito

Data Science is a starting point, and Data Engineering is the final point.
Science demonstrates what can be done, and Engineering shows how that works.
AI is considered to be just software, but it can become intelligent.
Software that we write today is not as intelligent as ML one.
The Data Science Teams is working with the dataset.
Most of the time the algorithm is all right, the problem might be with the web service as a link in a chain that might be broken.
The role of Data Engineer override with DS and ML Developer. And that is because that guarantees raw data is captured and in the right way to be processed and become a product.
Data Scientist used techniques from math and stats to view through the raw data available. It can be compared with a sculptor, that takes out marble pieces to make a beautiful sculpture. It might have a view before processing (sculpting) and through the data. The DS should tell the company what can be learned from the data and what can be planned.
Data Scientist can be viewed as a Product Owner, but for data. Data Scientist should have advanced knowledge in abstract math.
The company has a team of DS that think can be a great asset with the risk of producing nothing real but coming with ideas.
In history the Data scientists were done by most of the big kingdom to support expeditions in unknown territories, in the hope of getting a financial return.
The DE is not expected to have a deep knowledge of math but should have deep knowledge of databases. For example, how to move big data, from Data Lake to Data Warehouse. Should also have skills of how to automate those processes. Should also know knowing how often the expected model should be re-trained to stay adherent to close real data.
Companies to improve applications need real-world workloads to be scalable enough.
A role of DS is not enough, the company also needs DE and infrastructure.
A role is a set of skills of an individual.
The professional is also about an individual but has the skills to cover a given role.
The ML Engineer should write good software, applying best practices, and being comfortable with web services technologies like API or gRPC. The ML engineer should also incorporate a trained model into a client application.
Two interesting ideas about how knowledge can be spread:
- T-shaped knowledge is a deep vertical in one area and basic knowledge of several other side areas.
- Y-shaped is a deep vertical in one area and good knowledge good enough in a small number of side areas.
ML.NET comes as a framework to be helpful to data engineers and ML engineers rather than data scientists. ML.NET can manage up to 1TB of data. Is a tool that helps to integrate ML solution inside of existing or new .NET application. ML.NET is not a Microsoft version of Python is a tool for Data Scientists and Data Engineers.

Single-tenant to multi-tenant, a real world example - March 24 15:00 - 15:45 - Iris Classon

Nice presentation slides, drawn by her.

Sneak peek:

Was a discussion about multiple clients that access a load balancer, which redirects them to a cluster that contains an app, and that app shares multiple databases (tenants) to each client.
The old version of this was by creating an app for each client, that involves too many resources.
The new architecture looks something like in the above picture.
The problem with this architecture is that it should be too many instances of the Web API and also the deployment takes half a week. The deployment for aproximetely 120 customers takes 2 to 3 hours.
To being fixing that problem, she started with the Web API by using multiple tenants. The tenant can be identified by the subdomain, the domain, or a path.
The later you do it, the easier it is to get it wrong.
On a previous company all that logic was on-premises and then to a local cloud provider. But now on the current company, the application became tenant agnostic that runs on the cloud and also has a load balancer.

The pros:

Cost saving for scaling.
Simplified and faster deploying process.
Logs should be treated differently because we're not going to have logs per customer.

The cons:

Clients are not isolated, so the connection should be encrypted.

Trailblazor: Building Dynamic Applications with Blazor - March 24 16:00 - 16:45 - Shaun Walker

Dynamic applications are also called plugin applications, modular applications, or dynamic applications.
The benefits are the extensibility of being loosely coupled, which can be developed in parallel.
Blazor provides a consistent set of technologies to build both backend and frontend.
A Razor Component has capabilities such as routing, parameters, binding, and life cycle events.
The web app in the Blazor Server and the communication with the DOM (Browser) is done with SignalR.
The newer model done in ASP.NET Core, is done by using Web Assembly, and all that code is run in the browser.
There is an open source app framework build on Blazor called Oqtane. Can be used to create modern web applications with less called. (boilerplates). "Rocket Fuel for Blazor"
The benefits and the features of Oqtane Framework:

At first look, the razor code looks like aspx code but doesn't have a .cs file. As far as I understood a partial class can be created to move the code from the razor page.
The Oqtane should be configured like a WordPress site before using it. The configuration is simple, and after that, the administrator is redirected to the admin page, where settings can be made.
Even the application looks more like WordPress because content can be added from within the website. This a high-level comparison because the website is using Web Assembly so it has much more capabilities than WordPress.
Also modules can be created in code, deployed to Oqtane, and then added to the website via admin panel. When creating a module from inside the app, a whole solution is created locally on the server machine, with Client, Server, Package all the projects need for the specific module.
Oqtane is WordPress on extraterrestrial steroids. At first look is so powerful, and a much better comparison it would be with Oracle Apex, but with total control.

Moving a 20 year old .NET on Windows blog to Linux, Containers and Azure - March 24 17:00 - 17:45 - Scott Hanselman

Scott start presenting his website. He started blogging in 2002 with .NET 2.0 and then upgraded to .NET 4.x in a Windows Server.
Because it was hosted on a Windows Server, he needed to login in with RDP for troubleshooting. At that time this Windows Server was hosted, but not a VM on a physical server.
One of the requirements when moving to another framework was to not break the URLs.
There is a .NET Portability Analyzer that helps us find code that can't be moved to a new .NET framework.
Dotnet try-convert can be used to try to convert a .NET framework project from an old version to a newer one.
Scott shows how to build the same application in Windows and Ubuntu (WSL) and .NET 5.
Also some scripts can deploy the blog to Docker containers and can be also hosted to Azure or any cloud provider.
Azure Front Doors is similar to Cloudflare, which can take different domains and map them to a different backend.
His /blog is a different Azure App, and this redirect can be done within the same site with Azure Front Doors. Also, the certificate can be owned but managed by Azure.
The breakdown of the virtual machines was done systematically to not break the website.
Also by using .NET the website can be moved to any cloud provider.

Architecture – The Stuff That's Hard To Change - March 24 18:00 - 18:45 - Dylan Beattie

Fred Brooks discussed computer architecture in 1962.
The stuff that is hard to change are those components that were built wrong and cost money to change them or a part of them.

The architect should look forward and see what's coming.
To understand software, we should not look at the code because it is time-consuming. We should look at the traffic pattern, such as HTTP requests, load balancing, how many requests supports.
We need to ask the right question to be turned into meaningful metrics. For example knowing who to protect, for multiple-factor authentication.
Before reinventing the wheel search for an existing library, for example from nuget.
Diagrams should be clear, showing exactly what each of the entries should look like. Add more details to the diagrams to be easily understood.
I recommend following Dylan Beattie on Twitter (https://twitter.com/dylanbeattie) and the conferences he is attending.

Notes on Sandro Mancuso — Software Craftsmanship @Talk

Eduard Stefanescu — Sun, 07 Mar 2021 11:49:42 +0000

Originally published at https://eduardstefanescu.dev/2020/05/05/notes-on-sandro-mancuso-software-craftsmanship-talk/.

Talk: https://www.youtube.com/watch?v=9OhXqBlCmrM

Highlights

The attitude of software craftsmanship should be: passion, career ownership, "perfect" practice and boy scout rule;
We should produce more to receive more, and not waiting to receive something from our company because we are owning our career;
When we are working on an organization don't excuse, like "No one does that, so I'm not going to do it also". Either you do it or you leave the company;
A good developer is not Java, C# or Ruby developer. A good developer is a developer. We use the tools that we find useful for our job;

Notes

In February 2001, 17 people meet in a ski resort in Utah to create an Agile Methodology. The people there were people like Uncle Bob, Martin Fowler;
In agile processes and tools became more important than technical practices and excellence;
In the beginning there, were more "shits" scrum masters than developers. Some of those scrum masters know nothing about software development;
Without agile processes there will be no good delivered software;
"Insanity: doing the same thing over and over again, and expecting different results" --- Albert Einstein;
When we are under pressure we tend to cut corners, by thinking that we deliver faster, even when the managers do not push us;
We think that we don't have, but we do. Is our fault that we think that we don't have, and by doing so, we are delivering low-quality products;
Agile is about shorting the feedback loop;
By reacting to that feedback is what gives us the agility;
Agility is reacting constantly to feedback;
We don't do agile, because it's not logical. We are agile;
The most important deliver is the software itself;
To have good software, we need to have a good process;
Businesses are hostages of their software;
The business will move as fast as we developers create or change software;
As the software grows and no attention paid to the quality of it, the thing is that will become much harder;
In agile we are splitting stories, but delivering all the user stories doesn't mean that the delivered software is it the required one or at the quality that we want;
Every bug found by the QA team, is something we developers haven't done; QA should contribute in defining user stories and read newspapers;
We don't want software that breaks, we want software that makes us happy to work with;
Software that makes us happy is not about beautiful code, but instead is easy to maintain, to change and to test;
For him, the software is an asset, a huge investment that we need to care about because costs a fortune;
It doesn't matter the contract type, the relationship shouldn't be employer and employee, it should be a partnership;
We are not keeping the heads down and doing what we are told as in a factory because we are creative people;
Every craftsman or professional that are working on a project, he or she should strive to make it a success;
Software craftsmanship in his opinion is professionalism in software development;
Feedback in software development is based on XP Practices;
We should not need the authorization to use practices that improve the quality of the product, like Unit Tests, we should just do it;
Managers are interested in value, we are adding value through practices like: TDD, Continuous Integration, Refactoring, Pair Programming, and Automated Tests;
When we are talking about business, we should not discuss practices, instead, we should discuss about the value;
On a new project, at the beginning we will be slower until we will be better and faster;
Quality depends on who is doing the job, not the time or money;
"Developers are not football players" and should not cost millions of euros to create quality software;
Quality cannot be measure and defined precisely because there are so many variables, it means different people, in different places and different points in time;
Code coverage is a dangerous metric and should never be used as a target or management tool because the percentage of tested code is not the same as the percentage of the executed code. For example, we can have 80% tested code from a 50% executed code;
"How it is done is as important as having it done" --- Eduardo Namur;

JWT Token Claims in ASP.NET Core

Eduard Stefanescu — Sun, 07 Mar 2021 11:48:56 +0000

Originally published at https://eduardstefanescu.dev/2020/05/02/jwt-token-claims-in-asp-dotnet-core/.

After the authentication was presented in the previous two articles using Symmetric and Asymmetric keys, then this article is about authentication, much more exactly about Claims and Roles. In the first part, there will be an introduction to the core concepts of the JWT Claims, and in the second part the actual implementation.

JWT Authentication with Symmetric Key: https://stefanescueduard.github.io/2020/04/11/jwt-authentication-with-symmetric-encryption-in-asp-dotnet-core/.\
JWT Authentication with Asymmetric Key: https://stefanescueduard.github.io/2020/04/25/jwt-authentication-with-asymmetric-encryption-in-asp-dotnet-core/.

Introduction

Claims in JWT Token are used to store key data (e.g. username, timezone, or roles) in the Token payload, besides the IssuedAt (i.e. iat), which is added by default.\
In .NET Core, Claims can be used without installing any additional package, it comes from the System.Security.Claims package. From this package, in this article, just the Claim and ClaimTypes will be used. You can find more about them here: https://docs.microsoft.com/en-us/dotnet/api/system.security.claims?view=netcore-3.1.\
For this article I chose to use JwtAuthentication.AsymmetricEncryption project from the previous article and to add some functionality to support Claims and Roles. So if you are reading the previous two articles, you'll see small changes in this one.

Additional changes

As I said there will be some minor changes, to support the Claims and Roles feature. These changes are not required in your type of scenario but are required for a better understanding of this article. So if your target is to find the actual implementation, you can skip the AuthenticationService class.

`AuthenticationService`

The AuthenticationService now will have an additional UserRepository from which the data about the User will be retrieved. And the TokenService will receive the User to generate the securityToken.



public string Authenticate(UserCredentials userCredentials)
{
    userService.ValidateCredentials(userCredentials);
    User user = userRepository.GetUser(userCredentials.Username);
    var tokenService = new TokenService(user);
    string securityToken = tokenService.GetToken();

    return securityToken;
}

Authenticate method was explained in the previous two articles and all the code can be found on my GitHub account, there will be a link to it at the end of this article.\
UserRepository contains a predefined list of users, and the GetUser method returns only the User with the given username, this logic was on the UserService.

`User`

User now contains the Roles property and the Claims method which will build the claims with the Username and Roles. For the sake of this article, we're supposing that the Roles will be all the time set, so we'll don't need to worry if this collection will be null.



public class User
{
    public string Username { get; set; }
    public string Password { get; set; }
    public IEnumerable<string> Roles { get; set; }

    public IEnumerable<Claim> Claims()
    {
        var claims = new List<Claim> { new Claim(ClaimTypes.Name, Username) };
        claims.AddRange(Roles.Select(role => new Claim(ClaimTypes.Role, role)));

        return claims;
    }
}

You may notice that there are some predefined ClaimTypes, created by a standard (i.e. http://docs.oasis-open.org/imi/ns/identity-200810), but there is just plain text. So the ClaimTypes, can be also customized as you wish.\
The Claims will be used on the TokenService to set the Subject, which in fact is the Token Payload.

`TokenService`

TokenService is receiving the User from the AuthenticationService and uses it to set the Subject (i.e. Payload) of the Token.\
Besides this change, there is only one change that has to be done, on the GetTokenDescriptor method, when the SecurityTokenDescriptor is created, the subject is initialized with a new ClaimsIdentity that gets the user claims.



private SecurityTokenDescriptor GetTokenDescriptor()
{
    var tokenDescriptor = new SecurityTokenDescriptor
    {
        Subject = new ClaimsIdentity(user.Claims()),
        ...
    };

    return tokenDescriptor;
}

`UserController`

Now that the Claims are set, the UserController will be the playground for the set claims and roles. In order to accept requests with the created Token, the Controller must have the same Scheme as the Token set on the AuthorizeAttribute.



[Route("identity/[controller]")]
[Authorize(AuthenticationSchemes = JwtBearerDefaults.AuthenticationScheme)]
public class UserController : ControllerBase
{
    ...
}

`GetClaims` method

Firstly the user claims will be getting by using the User from the base class of the controller (i.e. ControllerBase), which has the Claims getter. Because the Claim class has many properties, that can be found on the Microsoft website: https://docs.microsoft.com/en-us/dotnet/api/system.security.claims.claim?view=netcore-3.1, for this example just the Type and the Value associated with will be used.



{"lastUpload":"2020-06-03T07:43:38.634Z","extensionVersion":"v3.4.3"}

In the picture below, the claims of the john.doe user are get. We can see that besides the name and role claims, there are three more which are not added explicitly; but were added by default when the Token was created.

nbf or Not Before, is used to verify that token will be valid only after it was created and not in the past;
exp or Expiration Time, it's self-explanatory and was set because the LifeTimeValidator was specified when the Token was created;
iat or Issued At as previously mentioned, is the time when the Token was created;\ The time represents the seconds in the Unix epoch time.

All the claims can be found on this scientific paper, which I used as a reference for these articles: https://tools.ietf.org/html/rfc7519#section-4.1.

`GetName`

In the GetName method, the value of Name claim is get for the given Token, which represents the username. The User already has predefined methods, like FindFirstValue in order to expose its property easily.



[HttpGet("name")]
public IActionResult GetName()
{
    string name = User.FindFirstValue(ClaimTypes.Name);
    return Ok(name);
}

In the response, only the username is returned from the Claim.

`GetRoles`

And the last method is using the AuthorizedAttribute with the Roles property to give access only to the users that have the set role, in this case, Admin.



[HttpGet("roles")]
[Authorize(Roles = "Admin")]
public IActionResult GetRoles()
{
    IEnumerable<Claim> roleClaims = User.FindAll(ClaimTypes.Role);
    IEnumerable<string> roles = roleClaims.Select(r => r.Value);
    return Ok(roles);
}

Let's test with john.doe user, that only have the User role.

The response code is 403 Forbidden because the request didn't pass AuthorizeAttribute`.

Now, the jane.doe user will be logged in, and we'll try to get her roles with the generated token.

In the above picture, the response code is OK and its body contains the user roles, as expected because the role is the requested one.

The source code from this article can be found on my GitHub account: https://github.com/StefanescuEduard/JwtAuthentication.

Thanks for reading this article, if you find it interesting please share it with your colleagues and friends. Or if you find something that can be improved please let me know.

JWT Authentication with Asymmetric Encryption using certificates in ASP.NET Core

Eduard Stefanescu — Sun, 07 Mar 2021 11:45:33 +0000

Originally published at https://eduardstefanescu.dev/2020/04/25/jwt-authentication-with-asymmetric-encryption-in-asp-dotnet-core/.

In the previous article I wrote about JWT Authentication using a single security key, this being called Symmetric Encryption. The main disadvantage of using this encryption type is that anyone that has access to the key that the token was encrypted with, can also decrypt it. Instead, this article will cover the Asymmetric Encryption for JWT Token.
In the first part of this article, the Asymmetric Encryption concept will be explained, and in the second part, there will be the implementation of the JWT Token-based Authentication using the Asymmetric Encryption approach by creating an "Authentication" Provider in ASP.NET Core.

Introduction

The JWT Token concepts were explained in the previous article, so if you want to find more before continuing reading this article, check out the introduction of the previous one: https://stefanescueduard.github.io/2020/04/11/jwt-authentication-with-symmetric-encryption-in-asp-dotnet-core/#Introduction.
Asymmetric Encryption is based on two keys, a public key, and a private key. The public key is used to validate, in this case, the JWT Token. And the private key is used to sign the Token. Maybe the previous statement is a little bit fuzzy, but I hope that will make sense in a moment.

For using Asymmetric Encryption, two keys have to be generated, these two keys have to come from the same root. In this case for this article, there will be a certificate - the root - from which the private and the public key will be generated. These keys will be also certificates, so the first thing that has to be done is to generate the private certificate - key - and the second one to generate the public certificate - key - from the private certificate.

Generating the keys

To generate certificates I chose to use the OpenSSL toolkit. If you are on Windows, OpenSSL can be downloaded as an executable and installed where ever you want. I recommend being installed on the C:\ root.
OpenSSL download link: https://slproweb.com/products/Win32OpenSSL.html
The tool has to be used from the Terminal, so there are two choices:

Run the executable from where the tool was installed.
Add an environment variable to have access to it from everywhere as a CLI.

To add the tool as an environment variable the following entry has to be inserted into the User variables:

Variable name: OPENSSL_CONF Variable value: <PATH_TO_OPEN_SSL>\bin\cnf\openssl.cnf

After configuring OpenSSL, the private and public key have to be generated using the following commands:

For the private key: openssl genpkey -algorithm RSA -out private_key.pem -pkeyopt rsa_keygen_bits:2048
- genpkey specifying that we'll generate a private key;
- -algorithm RSA the algorithm used, in this case RSA;
- -out private_key.pem the output argument and path;
- -pkeyopt rsa_keygen_bits:2048 set the public key algorithm and the key size;
For the public key: openssl rsa -pubout -in private_key.pem -out public_key.pem
- rsa specifying that the command will process RSA keys;
- -pubout -in private_key.pem the private key and the path of it;
- -out public_key.pem the output argument and path;
Before starting into code, the generated PEM keys have to be converted into XML files. That was the easiest way to read them using the System.Security.Cryptography package.
To convert them into XML you can use this site: https://superdry.apphb.com/tools/online-rsa-key-converter, then copy the converted text into two files with the XML extension in the project folder.

The Setup is the same as in the previous article, so check it out here: https://stefanescueduard.github.io/2020/04/11/jwt-authentication-with-symmetric-encryption-in-asp-dotnet-core/#Setup. TL;DR you have to install the following package: Microsoft.AspNetCore.Authentication.JwtBearer.

`Startup`

As in the previous article, the Authentication service has to be added in the ConfigureServices method from the Startup class. For Authentication, an extension method called AddAsymmetricAuthentication will set up the service with the basic settings.
It may be a little bit confusing to switch between this and the previous article, but the only thing that is changed here compared to the previous article is the IssuerSigningKey property, which now receives the SigningKey. The previous article contains a comprehensive explanation of each property that it's used: https://stefanescueduard.github.io/2020/04/11/jwt-authentication-with-symmetric-encryption-in-asp-dotnet-core/#Startup.

The SigningIssuerCertificate is used to get the IssuerCertificate or the public key; I will return to this class in a moment. The code below contains only what is necessary to use the public key in the Authentication service.



public static IServiceCollection AddAsymmetricAuthentication(this IServiceCollection services)
{
    var issuerSigningCertificate = new SigningIssuerCertificate();
    RsaSecurityKey issuerSigningKey = issuerSigningCertificate.GetIssuerSigningKey();
    services.AddAuthentication(authOptions =>
        {
          ...
        })
        .AddJwtBearer(options =>
        {
            ...
            options.TokenValidationParameters = new TokenValidationParameters
            {
                ...
                IssuerSigningKey = issuerSigningKey,
                ...
            };
        });

    return services;
}

After the Authentication service was added, in the Configure method the Authorization and Authentication middleware needs to be added to the pipeline.



public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    ...
    app.UseAuthentication();
    app.UseAuthorization();
    ...
}

`SigningIssuerCertificate`

In this class, the RSA class is used to create a RsaSecurityKey with the public key generated before.



public RsaSecurityKey GetIssuerSigningKey()
{
    string publicXmlKey = File.ReadAllText("./public_key.xml");
    rsa.FromXmlString(publicXmlKey);

    return new RsaSecurityKey(rsa);
}

FromXmlString initializes the rsa object with parameters from the XML files.
If we dig down in this method - https://git.io/JvbVm - we can see that the RSAParameters are the same as they are in the XML file converted before.

The rsa is created on the constructor, this object must be disposed because there might be some resources that will run after the process ends.



public void Dispose()
{
    rsa?.Dispose();
}

`SigningAudience Certificate`

SigningAudienceCertificate is very similar to the SigningIssuerCertificate, the only differences are that, is using the private key to initialize the rsa object and is returning SigningCredentials constructed with the RsaSecurityKey and the SecurityAlgorithms. For this, the RsaSha256 algorithm is used because is the most recommended one. If you want to find what algorithm to use for each type of encryption, check out this article: https://auth0.com/blog/json-web-token-signing-algorithms-overview/.



public SigningCredentials GetAudienceSigningKey()
{
    string privateXmlKey = File.ReadAllText("./private_key.xml");
    rsa.FromXmlString(privateXmlKey);

    return new SigningCredentials(
        key: new RsaSecurityKey(rsa),
        algorithm: SecurityAlgorithms.RsaSha256);
}

`AuthenticationService`

This service is used by the AuthenticationController to authenticate the user. It is like a middleware because it's using the UserService to validate the received UserCredentials and the TokenService to generate the JWT Token if the credentials were valid.

The UserService and UserCredentials were created in the previous article so I will use them from there. The UserService is a more likely a mock service, that has an internal list of users and checks if the given credentials are on that list. And the UserCredentials contains two properties Username and Password.



public string Authenticate(UserCredentials userCredentials)
{
    userService.ValidateCredentials(userCredentials);
    string securityToken = tokenService.GetToken();

    return securityToken;
}

`TokenService`

TokenService initializes on the constructor the SigningAudienceCertificate class created before. With this object, the SigningCredentials for the TokenDescriptor will be created.



private readonly SigningAudienceCertificate signingAudienceCertificate;

public TokenService()
{
    signingAudienceCertificate = new SigningAudienceCertificate();
}

The GetToken method is used to generate the TokenDescriptor by using the GetTokenDescriptor method that will be explained in a moment; to create a SecurityToken from that descriptor and to get the token as a string from that object.



public string GetToken()
{
    SecurityTokenDescriptor tokenDescriptor = GetTokenDescriptor();
    var tokenHandler = new JwtSecurityTokenHandler();
    SecurityToken securityToken = tokenHandler.CreateToken(tokenDescriptor);
    string token = tokenHandler.WriteToken(securityToken);

    return token;
}

GetTokenDescriptor method creates a token with the minimum required properties: Expires and SigningCredentials. Also, the Expires property here is used because on the Authentication method the LifetimeValidator was set, but it doesn't need to be specified.
All SecurityTokenDescriptor properties can be found on the Microsoft website: https://docs.microsoft.com/en-us/dotnet/api/microsoft.identitymodel.tokens.securitytokendescriptor.
The GetAudienceSigningKey method created before is used to generate the Token SigningCredentials, to validate that the Token was signed with the same private key from which the public key was generated.



private SecurityTokenDescriptor GetTokenDescriptor()

{

    const int expiringDays = 7;

var tokenDescriptor = new SecurityTokenDescriptor
{
    Expires = DateTime.UtcNow.AddDays(expiringDays),
    SigningCredentials = signingAudienceCertificate.GetAudienceSigningKey()
};

return tokenDescriptor;



}

`AuthenticationController`

In the AuthenticationController an endpoint is created to authenticate the user with UserCredentials and get the JWT Token by using the AuthenticationService described earlier.



[HttpPost]

public IActionResult Authenticate([FromBody] UserCredentials userCredentials)

{

    try

    {

        string token = authenticationService.Authenticate(userCredentials);

        return Ok(token);

    }

    catch (InvalidCredentialsException)

    {

        return Unauthorized();

    }

}

`ValidationController`

And the ValidationController contains a plain endpoint that it's using the Authorize attribute to validate the Token. Note that the Authentication Scheme must be used on the Authorize attribute and for the Authentication service.



[Authorize(AuthenticationSchemes = JwtBearerDefaults.AuthenticationScheme)]

public IActionResult Validate()

{

    return Ok();

}

The result

Authentication

Firstly the Authentication happy flow will be tested, so the combination of the username and password will match and the endpoint should provide the generated Token.

And secondly let's test the unauthorized flow, where the provided credentials are wrong.

Validation

Before checking that the Token is valid using the ValidationController, Auth0 crafted https://jwt.io/ that decode the Token and check whether or not the Token is valid.

On the Verify Signature section, both keys must be entered to validate the signature of the certificate.
Now the ValidationController will be used to check whether the token is valid or not, but this will happen internally, on the Authorize attribute. Firstly, the happy flow.

And in the second test, the wrong token is validated.

The source code from this article can be found on my GitHub account: https://github.com/StefanescuEduard/JwtAuthentication.

Thanks for reading this article, if you find it interesting please share it with your colleagues and friends. Or if you find something that can be improved please let me know.

JWT Authentication with Symmetric Encryption in ASP.NET Core

Eduard Stefanescu — Sun, 07 Mar 2021 11:37:50 +0000

Originally published at https://eduardstefanescu.dev/2020/04/11/jwt-authentication-with-symmetric-encryption-in-asp-dotnet-core/.

JWT Authentication is becoming one of the most used authentication types in modern web applications or services. This article covers the JWT Authentication with a Symmetric Key in ASP.NET Core. In the first part, there will be a short introduction to what Symmetric Key represents and the second part contains the prerequisites for this project and the actual implementation of this authentication type.
This article is the first article from of series of two, the second one will contain the authentication with an Asymmetric Key using a certificate.

Introduction

JWT Token is a common way of creating access tokens that can contain several claims (e.g. Username, Roles). JWT Token means JSON (JavaScript Object Notation) Web Token. Every JWT Token has the following structure:

Header, containing the encryption algorithm;
Payload, containing custom Claims, plus at least two required claims:
- exp representing the expiration time when the Token will become unavailable;
- iat or Issued at Time, the time when the Token was created;\ The times are formatted using the Unix Timestamp format (e.g. 1582784721).
Signature, representing the encoded header, plus a dot, plus the encoded payload, plus a secret key. The concatenated result will be run through the encryption algorithm specified on the Header to validate the Token.

If you want to read more about JWT Token, this comprehensive paper covers all the concepts: https://tools.ietf.org/html/rfc7519.

Symmetric Key

The Symmetric Key is used both for signing and validation. For example, let's say John wants to share a secret with Jane, when the secret is told, John also tells Jane a password - the key - in order for the secret to being understood. In this way, John - the identity provider or the service - ensures that his secret is well kept by using the given password.

Setup

ASP.NET Core 3.1 will be used for this project. Microsoft also offers a great package that provides all that is needed to create a JWT Token-based authentication. The package is called Microsoft.AspNetCore.Authentication.JwtBearer, this is the only package that the project needs, and can be found here: https://www.nuget.org/packages/Microsoft.AspNetCore.Authentication.JwtBearer.

Creating a secret key

The signing and validation key will be a user secret key. ASP.NET provides the user secret key feature to store all the confidential data that doesn't have to be committed or shared outside the user or developer environment. For the production or testing environments, the keys need to be store in a cloud vault, like Microsoft Azure offers through Key Vault - https://azure.microsoft.com/en-us/services/key-vault/ -, but this will be a topic for another article.\
Firstly, the project needs to be initiated for using user secrets, by running the following command in the project folder:



dotnet user-secrets init

Then the user secret key is added, using the following command:



dotnet user-secrets set "AppSettings:EncryptionKey" "POWERFULENCRYPTIONKEY"

This command will add to the secrets.json file the AppSettings:EncryptionKey key with the value POWERFULENCRYPTIONKEY.\
If there are multiple values for the AppSettings then this key can become more readable by using a JSON format like:



"AppSettings": {
  "EncryptionKey": "POWERFULENCRYPTIONKEY",
  "Key2": "Value2" 
}

The POWERFULENCRYPTIONKEY will be encoded in an array of bytes and then this binary will be Base64 encoded, this is required for both signing and validation.

Startup

In the ConfigureServices method from the Startup class, the AppSettings section needs to be read. To read a type from the configuration file, a class must be created, so for the AppSettings section an equivalent class needs to exists, as is shown below. This class can be seen as a Data Transfer Object, which contains plain properties.



public class AppSettings
{
    public string EncryptionKey { get; set; }
}

After the section is read, the EncryptionKey needs to be converted into bytes.



public void ConfigureServices(IServiceCollection services)
{
    services.AddControllers();

    IConfigurationSection settingsSection = configuration.GetSection("AppSettings");
    AppSettings settings = settingsSection.Get<AppSettings>();
    byte[] signingKey = Encoding.UTF8.GetBytes(settings.EncryptionKey);

    services.AddAuthentication(signingKey);

    services.Configure<AppSettings>(settingsSection);
    services.AddTransient<AuthenticationService>();
    services.AddTransient<UserService>();
    services.AddTransient<TokenService>();
}

On line 9 the Authentication service is added into the App container, this service is responsible, for managing Authentication settings, like IssuerSigningKey or LifeTimeValidation.\
For this step, an extension method is created called AddAuthentication, which receives the service and the signingKey converted earlier.\
From line 11 to 14, the services are configured for the Dependency Injection, we will return to the implementation of these services in a moment.



public static IServiceCollection AddAuthentication(this IServiceCollection services,
    byte[] signingKey)
{
    services.AddAuthentication(authOptions =>
        {
            authOptions.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
            authOptions.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
        })
        .AddJwtBearer(jwtOptions =>
        {
            jwtOptions.SaveToken = true;
            jwtOptions.TokenValidationParameters = new TokenValidationParameters
            {
                ValidateAudience = false,
                ValidateIssuer = false,
                ValidateIssuerSigningKey = true,
                IssuerSigningKey = new SymmetricSecurityKey(signingKey),
                ValidateLifetime = true,
                LifetimeValidator = LifetimeValidator
            };
        });

    return services;
}

The authenticationOptions need to configure the Authenticate and Challenge Schemes, in order to verify that the endpoint(s) which receives a JWT Token will go through the validation step, as is described below starting from line 12. The same Schema will be seen on the endpoints that use the AuthorizeAttribute.\
Then the JwtBearer is added to the Authentication process, using the following properties:

SaveToken is self-explanatory. It's used to persist the Token into local storage. The token will be valid even if the service restarts, so its lifetime is different from the application;
ValidateAudience and ValidateIssuer must be used for the service to skip or to validate the Audience or the Issuer. The Audience refers to the server or the Identity Provider, in this case, our ASP.NET Service. And the Issuer refers to the client(s) that makes HTTP request(s). For the sake of this example, both are set false. Please note that even if you don't want to validate the Audience or/and the Issuer these values must be set;
ValidateIssuerSigningKey needs to be set to true, in order to validate the received Token;
For IssuerSigningKey will use the SymmetricSecurityKey, the same approach will be also used when the Token will be created.
LifeTimeValidator is important if the generated Token has set an expiration time.

All the JWT Bearer Options can be found on the Microsoft website: https://docs.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.authentication.jwtbearer.jwtbeareroptions.

The LifeTimeValidator handler is checking if the expiration date is greater than the current Date, as follows:



private static bool LifetimeValidator(DateTime? notBefore,
    DateTime? expires,
    SecurityToken securityToken,
    TokenValidationParameters validationParameters)
{
    return expires != null && expires > DateTime.Now;
}

After the services were configured, the Authentication and Authorization middleware must be added to the App pipeline in the Configure method.



public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    ...
    app.UseAuthentication();
    app.UseAuthorization();
    ...
}

`UserCredentials`

User's Credentials will be used as a Data Transfer Object, this class will be received on the authentication endpoint and sent to the AuthenticationService. It's a plain class that contains only the Username and the Password of the user.



public class UserCredentials
{
    public string Username { get; set; }
    public string Password { get; set; }
}

`AuthenticationService`

The AuthenticationService is used like a middleware that receives the UserCredentials from the Controller, validates them using the UserService and if the credentials are valid, it creates a Token using the TokenService. Both the User and Token services are injected into the constructor.



public string Authenticate(UserCredentials userCredentials)
{
    userService.ValidateCredentials(userCredentials);
    string securityToken = tokenService.GetToken();

    return securityToken;
}

`UserService`

For the sake of this example, the UserService contains a list of users created on the constructor. In a real-life scenario, this will be read from storage or from a service.



public class UserService
{
    private readonly IEnumerable<UserCredentials> users;

    public UserService()
    {
        users = new List<UserCredentials>
        {
            new UserCredentials
            {
                Username = "john.doe",
                Password = "john.password"
            }
        };
    }
...

This is more like a UserValidation service, but to better illustrate that it also reads the users, the UserService name will be kept.



...
    public void ValidateCredentials(UserCredentials userCredentials)
    {
        bool isValid =
            users.Any(u =>
                u.Username == userCredentials.Username &&
                u.Password == userCredentials.Password);

        if (!isValid)
        {
            throw new InvalidCredentialsException();
        }
    }
}

The ValidateCredentials method checks if the username and password pair exists, and if it doesn't it will throw the InvalidCredentialsException which will be caught on the Controller.

`TokenService`

TokenService is receiving on the constructor the AppSettings, which will be used on the GetTokenDescriptor method to set up the Token.



public class TokenService
{
    private readonly AppSettings appSettings;

    public TokenService(IOptions<AppSettings> options)
    {
        appSettings = options.Value;
    }
...

The public GetToken method is used to get the token description, to create the Token and write it into a string, that will be returned to the calling service, in this case to the AuthenticationService.



public string GetToken()
{
    SecurityTokenDescriptor tokenDescriptor = GetTokenDescriptor();
    var tokenHandler = new JwtSecurityTokenHandler();
    SecurityToken securityToken = tokenHandler.CreateToken(tokenDescriptor);
    string token = tokenHandler.WriteToken(securityToken);

    return token;
}

On the GetTokenDescriptor method, the token is constructed. In this method, the ExpirationTime and SigningCredentials are set. Because the Claims are not in the main focus of this article, I will create another one, in which I will explain how the Claims can be set on the Token and how they can be used.



private SecurityTokenDescriptor GetTokenDescriptor()
{
    const int expiringDays = 7;

    byte[] securityKey = Encoding.UTF8.GetBytes(appSettings.EncryptionKey);
    var symmetricSecurityKey = new SymmetricSecurityKey(securityKey);

    var tokenDescriptor = new SecurityTokenDescriptor
    {
        Expires = DateTime.UtcNow.AddDays(expiringDays),
        SigningCredentials = new SigningCredentials(symmetricSecurityKey, SecurityAlgorithms.HmacSha256Signature)
    };

    return tokenDescriptor;
}

All the Token Descriptors can be found on the Microsoft website: https://docs.microsoft.com/en-us/dotnet/api/system.identitymodel.tokens.securitytokendescriptor.

`AuthenticationController`

Now, all we have to do, is to create an AuthenticationController which receives the UserCredentials and uses the previously created AuthenticationService.\
On the constructor the AuthenticationService is injected, to be used on the Authentication endpoint.



[Route("identity/[controller]")]
public class AuthenticationController : ControllerBase
{
    private readonly AuthenticationService authenticationService;

    public AuthenticationController(AuthenticationService authenticationService)
    {
        this.authenticationService = authenticationService;
    }
...

The authentication endpoint accepts HTTP Post requests, receives the UserCredentials as previously mentioned, and uses the AuthenticationService to authenticate and create the Token.



...
    [HttpPost]
    public IActionResult Authenticate([FromBody] UserCredentials userCredentials)
    {
        try
        {
            string token = authenticationService.Authenticate(userCredentials);
            return Ok(token);
        }
        catch (InvalidCredentialsException)
        {
            return Unauthorized();
        }
    }
}

If the credentials are valid, then the endpoint will return an OK HTTP Status code and the generated token. Otherwise, if the InvalidCredentialsException is thrown, the Unauthorized HTTP Status code is returned.

`ValidationController`

The purpose of the ValidationController is to check that the signing process is working, in order to validate the Token.



Route("identity/[controller]")]
public class ValidationController : ControllerBase
{
    [Authorize(AuthenticationSchemes = JwtBearerDefaults.AuthenticationScheme)]
    public IActionResult Validate()
    {
        return Ok();
    }
}

You may notice that the Validate endpoint has the AuthorizeAttribute which has on its constructor the same AuthenticationSchemes as was set on the Authentication service.

The result

Firstly, the happy flow for the AuthenticationController is tested, so we'll provide the correct combination of the username and password, in order to receive the token.

Let's test with credentials that are not correct, the response should be Unauthorized.

And secondly, the generated token needs to be tested using the Validation controller. The first test will be with the generated token, to see that the validation is passed.

And the second test is when the wrong token is provided for validation.

The source code from this article can be found on my GitHub account: https://github.com/StefanescuEduard/JwtAuthentication.

Thanks for reading this article, if you find it interesting please share it with your colleagues and friends. Or if you find something that can be improved please let me know.

RabbitMQ Consumer Received Event with Docker in .NET

Eduard Stefanescu — Sun, 07 Mar 2021 11:30:02 +0000

Originally published at https://eduardstefanescu.dev/2020/04/04/rabbitmq-consumer-events-with-docker-in-dotnet/.

This article contains another approach to consuming messages. The first part will be a comparison between the several types of consuming messages and in the second part, each line of code will be explained.\
The entire environment setup with Docker can be found in the first article from the RabbitMQ series. This series, there are also explained some core principles about each RabbitMQ node. I highly recommend that, if you are at the beginning with RabbitMQ or with the AMQP standard, to start with these articles:

Introduction

The RabbitMQ Client provides a Received event that will be used to consume the messages coming from one or more Queues. In the Consumer article, the messages are consumed and acknowledged using the BasicGet and the BackAck methods in a while loop, waiting for the CancellationToken. The advantage of that method is that a message can be consumed when needed. So, care must be taken when using this method. It's not recommended to use it in an infinite while loop if the Received event exists, and it's a good replacement for that type of approach.\
The advantage of the Received event is obvious, that will no longer consume unnecessary resources, but the "disadvantage" is that the messages will be consumed whenever they are raised based on the routing key.\
But this depends on the different scenarios which way to choose. A useful tip that may help when you must choose between these two ways of consuming messages is:

BasicGet method can be used when there are more messages to get or it needs to be consumed at a certain time;
Received event can be used when the raised message needs to be consumed immediately;

There is also another approach to consume messages, by inheriting the DefaultBasicConsumer class. This gives the advantage of having a hierarchy of consumers, which may lead to different design patterns.

In the following part of this article, there will be only some chunks of code, which are required to consume the messages using the Received event. The connection setup is the same as in previous articles.

`Received` event

Before start establishing the connection, a CancellationToken is needed to wait for the user to stop the Console App execution.

To bind the Consumer to the Channel, a new EventingBasicConsumer instance is made by passing the Channel as a parameter.

IConnection connection = factory.CreateConnection();
IModel channel = connection.CreateModel();
var basicConsumer = new EventingBasicConsumer(channel);

An important note here is that there is no need to surround the IConnection and the IChannel into a using statement, the reason for this is that the Connection and the Channel need to exist as long as the app. If these two variables were disposed too early, then no message would be received.\
You may notice that in this RabbitMQ series, I used the Channel word instead of the official name Model, that's because it's easier to understand. For me, a Model is too generic, instead, a Channel makes me think of a communication channel, which in fact it really is.\
The official documentation for EventingBasicConsumer can be found here: https://www.rabbitmq.com/releases/rabbitmq-dotnet-client/v3.1.1/rabbitmq-dotnet-client-3.1.1-client-htmldoc/html/type-RabbitMQ.Client.Events.EventingBasicConsumer.html.

Subscribing to the event

Using the Consumer created earlier, we subscribe to the Received event the OnNewMessageReceived handler.

basicConsumer.Received += OnNewMessageReceived;

Handling the event

This event handler will display the received message and another message to inform the user that can stop consuming messages.

private static void OnNewMessageReceived(object sender, BasicDeliverEventArgs e)
{
    Console.WriteLine($"Message: {Encoding.UTF8.GetString(e.Body)}");
    Console.WriteLine("Press any key to stop consuming message.");
}

Consuming messages

To start consuming messages, the Consumer will be bind to the queue. In the following code, there is an iteration through the queues count entered previously. Then the user is asked to enter the Queue name that will be bound to the Consumer.\
The BasicConsume method takes three parameters:

the first one is the Queue name;
the second is used for auto acknowledgment, in this case, is set to true, but if it was set to false then the acknowledgment had to be done manually if this is wanted;
and the third one is the Consumer;

Waiting for `Cancellation`

The WaitHandle static class is a handy way to wait for the CancellationToken to be raised. Instead of the CancellationToken, the AutoResetEvent or other signaling events can be also used.

WaitHandle.WaitAny(new[] { cancellationToken.WaitHandle });

Disposing resources

After the user indicates that no longer wants to receive messages, or in a real-life scenario, when the application ends, all the created resources need to be disposed.

basicConsumer.Received -= OnNewMessageReceived;
channel.Close();
channel.Dispose();
connection.Close();
connection.Dispose();

Firstly the OnNewMessageReceived event handler needs to be unsubscribed from the Received to stop displaying messages after the program finishes its execution. It can be possible that reference to event handler can still exist after the resources are disposed and the program closes. So, I highly recommend that all the time when it's needed, unsubscribe the event handlers.\
After that, the Channel and the Connection are closed and disposed.

The result

Using the Producer, the direct Exchange and one Queue created in the previous articles, the topology will be created and the Consumer will be connected to it.\
In the picture below, the sent message by the Producer using a specific routing key bound to the Queue reached the event handler, and this displayed the message.

All the code for this Consumer and for the entire topology is available on my GitHub account: https://github.com/StefanescuEduard/RabbitMQ_POC

Thanks for reading this article, if you find it interesting please share it with your colleagues and friends. Or if you find something that can be improved please let me know.

RabbitMQ Headers Exchange with Docker in .NET

Eduard Stefanescu — Sun, 07 Mar 2021 10:06:05 +0000

Originally published at https://eduardstefanescu.dev/2020/03/28/rabbitmq-headers-exchange-with-docker-in-dotnet/

This article is about Headers Exchange, I chose to create an article just for this type of Exchange because it needs a little more attention compared to the other three types (i.e. fanout, direct, topic).\
In this article, I will use the setup environment with Docker from the first article, so if you want a good starting point, you can begin with the first article: https://stefanescueduard.github.io/2020/02/29/rabbitmq-producer-with-docker-in-dotnet/.

Introduction

Headers Exchange is routing the messages based on the bindings that are applied to the Producer and Queue.\
In order to produce a message, that message should be published with defined properties that are also bound to the Queue - this is why it's called Headers Exchange - and can also be seen as the routing key.\
Another mandatory property that must be bound to the Queue is x-match. This property specifies the matching criteria, as follows:

x-match=all means that all the header pairs must match;
x-match=any means that at least one header pairs must match;

A quick example, that will be also implemented using .NET Core:\
Let's say that a Windows Application produces two logging types, information and error, and the server process these log messages based on its types.\
So for each log type, will be a Queue that will have a property log-level equals to the type of logging that will receive. To send log information, the Producer must set to that message a property log-level=information so that the Exchange will forward the message to the correct Queue.

If this is still unclear, then a brief explanation for Headers Exchange is that the messages contain a header in order to be bound correctly.\
I hope now the whole typology is a little bit clearer, and why this type of Exchange is called Headers.

Now we can start implementing these concepts, the following part will contain code chunks that are required in order to use Headers Exchange, these chunks were applied to existing code from the previous four articles about RabbitMQ.

`Producer`

To bind the logging type to the Producer properties, a Dictionary of type string, object is used as the properties headers. In this case, the key will be log-level and the value will be the actual log level (i.e. information or error). For this scenario, the log level is entered by the user, but in a real-life scenario, there will be a logging system that will serve this scope.

Console.Write("Log level: ");
string logLevel = Console.ReadLine();

Console.Write("Message: ");
string message = Console.ReadLine();

var propertiesHeaders = new Dictionary<string, object> { { "log-level", logLevel } };

using (IConnection connection = factory.CreateConnection())
{
    using (IModel channel = connection.CreateModel())
    {
        IBasicProperties properties = channel.CreateBasicProperties();
        properties.Headers = propertiesHeaders;

        byte[] messageBytes = Encoding.UTF8.GetBytes(message);
        const string exchangeName = "test-exchange";

        channel.BasicPublish(exchangeName, string.Empty, properties, messageBytes);
        Console.WriteLine($"Published message: {message}");
    }
}

The propertiesHeaders are bound to the published message by firstly creating plain properties with an empty content header using the CreateBasicProperties method. The difference between this Producer and the one from the first article is on line 14, which sets the Headers property to the dictionary created earlier.

`Exchange`

This type of Exchange is very similar to the one created in the second article. The only thing that changes is the type, which will be set to headers when the Exchange is declared on line 7.

using (IConnection connection = factory.CreateConnection())
{
    using (IModel channel = connection.CreateModel())
    {
        const string exchangeName = "test-exchange";
        channel.ExchangeDelete(exchange: exchangeName);
        channel.ExchangeDeclare(exchange: exchangeName, type: "headers");
    }
}

We can see this result also on the RabbitMQ Management page:

`Queue`

To bound the Queue, the properties of the header must be set using a Dictionary of type string, string that will be passed as arguments to the QueueBind method.\
For this article, I chose to use the all value for the first x-match property, but this value can be also set to any because only the log-level header needs to match.\
And the second property is the log-level, the value of this property is given by the user, but in a real-life scenario, this property will be set by the listener service.

Console.Write($"Log level for Queue[{queueIndex}]: ");
var logLevel = Console.ReadLine();

using (IConnection connection = factory.CreateConnection())
{
    using (IModel channel = connection.CreateModel())
    {
        channel.QueueDelete(queue: queueName);

        channel.QueueDeclare(queue: queueName,
            durable: false,
            exclusive: false,
            autoDelete: false,
            arguments: null);

        channel.QueueBind(queue: queueName,
            exchange: "test-exchange",
            routingKey: string.Empty,
            arguments: new Dictionary<string, object>
                {{"x-match", "all"}, {"log-level", logLevel}});
    }
}

When a Queue is created the result can be also seen on the RabbitMQ Management page. In the picture below, there is an information-queue bound with log-level set to information using the code above.

The result

With all of this in place, we can start using this topology.

Firstly, we have to create a Headers Exchange:

The information and error queues have to be created and bound the log-level property to them:

The Consumer from the last article will be used, the one without events, but the one with events can be used as well. There is no need to create another Consumer because its responsibility is to listen to Queues that are subscribed to.

Now the messages can be produced. There will be two messages for the information and error log levels, and one that is not bound to any header.

In the picture above can be seen, that the first two messages which had the headers bound correctly were received by the consumer, but the final messages which don't have any headers were not received.

The entire code for this topology and the RabbitMQ series can be found on my GitHub account: https://github.com/StefanescuEduard/RabbitMQ_POC.

Thanks for reading this article, if you find it interesting please share it with your colleagues and friends. Or if you find something that can be improved please let me know.

RabbitMQ Consumer with Docker in .NET

Eduard Stefanescu — Sun, 07 Mar 2021 09:56:33 +0000

Originally published at https://eduardstefanescu.dev/2020/03/21/rabbitmq-consumer-with-docker-in-dotnet/.

This is the last article from the RabbitMQ series. In this series, I explained all the RabbitMQ nodes using .NET and Docker. There will be other two articles, the first one is dedicated just for the Headers Exchange, because this type of Exchange needs more attention, considering that the sent messages need to be binding to the Exchange using x-match property and to the Queue using defined properties. And in the second one, I will explain a safer way of consuming messages and closing the connection, because this series is more educational oriented and plain methods were used for a better understanding.

In this article the Consumer node of the RabbitMQ topology will be presented, in the first part the core concepts will be cover, and in the second part, each line of code will be explained.\
The first article from this series contains the environment setup with Docker and the core fundamentals of RabbitMQ. You can check the other three articles here:

Introduction

The RabbitMQ Consumer it's the node to which the Queues are connected. This will receive all the messages sent by the Producer and followed some path to be consumed. A real-life example for the Consumer it will be, a logging system, where the Producer is the app that sent the log message and the Consumer is the Console or the API that will process the received message.

Useful tips

Here are some tips that I found useful:

The lifetime of a Consumer is as long as the application lifetime;
It's not recommended to have a Consumer that consumes only one message, but it's totally fine to have a Consumer subscribed to a Queue as long as it sent multiple messages. That's because, for obvious reasons, it's not necessary to have this entire system send only one message;
A Consumer has a uniquely identifiable tag and a subscription ID, which is the connection link with the Queue;
The exclusivity to the Consumer can be made using the exclusive flag, which means that the Consumer will receive messages from only one Queue;
And some Consumers can have a higher priority to the same messages over other Consumers;

All the Consumers's properties can be read on the RabbitMQ website: https://www.rabbitmq.com/consumers.html.

Creating the `Consumer`

First of all, we need to know how many queues are listening to this consumer, so a message is prompt to enter the number of queues. After that, a connection to the RabbitMQ Server is made using a URI and specifying the ConnectionTimeout to its maximum value. This value is used just for this article purposes, also all the ConnectionFactory properties with few examples can be found here: https://www.rabbitmq.com/releases/rabbitmq-dotnet-client/v3.2.4/rabbitmq-dotnet-client-3.2.4-client-htmldoc/html/type-RabbitMQ.Client.ConnectionFactory.html.\
You can check the first article where is another approach of creating the ConnectionFactory using the properties Hostname, UserName and Password.

private static IConnection connection;
private static IModel channel;

public static void Main()
{
    Console.Write("Listening queues to this consumer: ");
    var listeningQueuesCount = int.Parse(Console.ReadLine());

    var factory = new ConnectionFactory
    {
        Uri = new Uri("amqp://guest:guest@localhost"),
        ContinuationTimeout = TimeSpan.MaxValue
    };
    connection = factory.CreateConnection();
    channel = connection.CreateModel();
...

You may notice that the IConnection and IModel fields are static, that's because this is a Console App, and these two fields are used inside of each thread that is listening to a Queue. But these fields will be closed and disposed before the application finishes its execution.

Listening to the `Queue(s)`

Before start listening to the Queue(s), a CancellationTokenSource is created in order to be passed on each execution thread that will display a message, that's because the thread will have the same lifetime as the application, and it's also a safety check to cancel the Consumer subscription once the application ends.\
According to the number of Queues entered, this Consumer is listening to, the Queue name is asked in order to create the connection between the Consumer and the Queue.\
Then for each Queue, a thread is created, and start listening to it.

...
var cancellationTokenSource = new CancellationTokenSource();
CancellationToken cancellationToken = cancellationTokenSource.Token;

for (var queueIndex = 0; queueIndex < listeningQueuesCount; queueIndex++)
{
    Console.Write($"Queue[{queueIndex}] name: ");
    var queueName = Console.ReadLine();

    var thread = new Thread(() => DisplayQueueMessage(queueName, cancellationToken));
    thread.Start();
}
...

Displaying the received message

The DisplayQueueMessage has the following parameters:

The queueName which will listen to;
And the cancellationToken which represents the listener thread lifetime;

private static void DisplayQueueMessage(string queueName, CancellationToken cancellationToken)
{
    while (!cancellationToken.IsCancellationRequested)
    {
        BasicGetResult result = channel.BasicGet(queueName, false);
        if (result != null)
        {
            Console.WriteLine($"Message: {Encoding.UTF8.GetString(result.Body)}");
            channel.BasicAck(result.DeliveryTag, false);
            Console.WriteLine("Press any key to stop consuming messages.");
        }
    }
}

`DisplayQueueMessage` method explanation

As is described earlier, the listener will exist until the cancellationToken is not requested.\
On line 5 the message is retrieved from the Queue and is checked if it's null. If it's not null, the message body which is an array of bytes will be decoded using the same encoding format as it was used to encode the message.\
After displaying the retrieved message, the result is acknowledged in order to be deleted from the Queue and to display the next message.\
This is not the nicest way to listen to the messages and can cause performance issues, that's why I will create another article about listening events, that will be raised only when a message is published and redirected to a specific Queue.

Ending the connection

After the thread was created for each Queue, a message is prompt in order to display how many Queues are listening to the Consumer.

...
    Console.WriteLine(
        $"Consumer created successfully and listening to {listeningQueuesCount} queue(s).");
    Console.ReadKey();

    cancellationTokenSource.Cancel();

    WaitHandle.WaitAny(new[] { cancellationToken.WaitHandle });

    channel.Close();
    channel.Dispose();
    connection.Close();
    connection.Dispose();
}

Then the cancellationTokenSource is canceled, in order to stop the listening threads, after that the connection and channel are closed and disposed.
The WaitHandle is used to end the connection and the channel safely after the cancellation is signaled.

You can find the solution, with all four nodes on my Github account: https://github.com/StefanescuEduard/RabbitMQ_POC.

Topology result

By following the http://tryrabbitmq.com/ topology described in the previous articles, firstly the Exchange is created:

Then two Queues are created:

The Consumer is connected to them:

The last step is to publish the messages and checking the Consumer that is displaying them.

Producing messages for both routing-keys:
Checking Consumer to see the sent messages:

Thanks for reading this article, if you find it interesting please share it with your colleagues and friends. Or if you find something that can be improved please let me know.

RabbitMQ Queue with Docker in .NET

Eduard Stefanescu — Sun, 07 Mar 2021 09:52:47 +0000

Originally published at https://eduardstefanescu.dev/2020/03/14/rabbitmq-queue-with-docker-in-dotnet/.

This is the third article from a series of four about RabbitMQ Queue. The first part contains a brief introduction into the Queue concepts and in the second part, each line of the code is explained. You can check the first article where the RabbitMQ core concepts are presented and also the environment setup with Docker and the Producer are explained step by step.

Introduction

The RabbitMQ Queue is positioned in the Message Broker section with the Exchange, and can be seen as buffer storage, that receives messages through a stream based on the binding key from the Exchange which also receives the messages from one or many Producers. They are acting like a Queue Data Structure, that can be enqueued and dequeued, using the FIFO rule.\
Some tips about the Queues, that I find useful are:

A Queue name can't start the amq name, because is restricted by the Broker for internal usages.
If the Queue name is not specified a random one will be assigned to it.
Queues with the same name can be created on the same channel, by only the last one will be kept.

All the RabbitMQ Queue properties can be on their site: https://www.rabbitmq.com/queues.html.

Creating the `Queue`

To start creating a Queue firstly the connection to the RabbitMQ server should be built using the ConnectionFactory; is the same setup as in the previous article about RabbitMQ Exchange using a URI. But in the first article where the Producer is created, the connection was created using explicit properties of ConnectionFactory (i.e. Hostname, UserName and Password).

Connection setup

As you can see in the below chunk code, all these properties are embedded into one Uri instance.

var factory = new ConnectionFactory
{
    Uri = new Uri("amqp://guest:guest@localhost"),
    ContinuationTimeout = TimeSpan.MaxValue
};

ConnectionTimeout property was set to its maximum value because I didn't want the connection to expire, but this is just for this article purposes. If you are interested to find all the ConnectionFactory properties, they are well documented here with one example: https://www.rabbitmq.com/releases/rabbitmq-dotnet-client/v3.2.4/rabbitmq-dotnet-client-3.2.4-client-htmldoc/html/type-RabbitMQ.Client.ConnectionFactory.html. This is the documentation for version 3.2.4 when you read this article the RabbitMQ Client for .NET may be updated, so it's possible that some properties may be changed, deprecated or removed.

Developer input

You may wonder why the user or the developer input is involved in this, is because this series of articles about RabbitMQ is more educational rather than a solution-oriented approach. So I wanted to replicate one to one the http://tryrabbitmq.com/ concept of learning the basic principles of RabbitMQ using .NET.\
Thus, after the connection to the RabbitMQ Server was built, the user is asked to enter the number of Queues that he wants to create and to provide for each Queue a name and the routing key.

for (var queueIndex = 0; queueIndex < queuesCount; queueIndex++)
{
    Console.Write($"Queue[{queueIndex}] name: ");
    var queueName = Console.ReadLine();

    Console.Write($"Routing key for Queue[{queueIndex}]: ");
    var routingKey = Console.ReadLine();
...

Connection establishment

When the required properties are entered, for each Queue a Connection and a communication Channel will be created. After that, the Queue is declared, and the bound to the Exchange that has the same name for the entire solution (i.e. test-exchange). If the creation and the binding were ended successfully, then a message is prompted informing the user that the Queue was created.

...
    using (IConnection connection = factory.CreateConnection())
    {
        using (channel = connection.CreateModel())
        {
            channel.QueueDeclare(queue: queueName,
                durable: false,
                exclusive: false,
                autoDelete: false,
                arguments: null);

            channel.QueueBind(queue: queueName,
                exchange: "test-exchange",
                routingKey: routingKey);
        }
    }

    Console.WriteLine(value: $"Queue {queueName} created.");
}

`QueueDeclare` parameters

Let's dig a little bit deep into the parameters of the QueueDeclare:

queue it's self-evident that it refers to the Queue name;
durable represents the lifetime of the Queue in the Broker, if it's set to false the Queue will end when the Broker does too;
autoDelete is used to specify the lifetime of the Queue based on its subscriptions. The Queue will be deleted if the last Consumer subscribed to it, unsubscribes;
arguments are used to sent information about the Queue (e.g. length limit) to the Broker;

QueueBind's parameters are self-explanatory, the first one refers to the queueName, the second to the exchangeName and the last one to the routingKey.

The result

After the Queues are created, a message is prompted to the user with how many Queues were created.

The created Queues can also be seen on the RabbitMQ Management page.

Now, all we have to do is to create the Consumer, and the entire topology will be ready to be used. The Consumer will be created in the next article, this being the last one from this series.

Thanks for reading this article, if you find it interesting please share it with your colleagues and friends. Or if you find something that can be improved please let me know.

DEV Community: Eduard Stefanescu

ASP.NET Core Swagger Documentation with Bearer Authentication

Introduction

Adding the Security Definition

Adding the Security Requirement

The result

Authenticating

Authorization

Requesting an authorized resource

References

ASP.NET Core Swagger Documentation

Introduction

Prerequisites

Writing XML comments

Describing parameters

Adding Swagger Service Generator

Adding Swagger Middleware

The result

References

Notes on Day 2 - The One with Dotnet @Codecamp Romania, 2021

Notes on Day 1 — The One with Dotnet @Codecamp Romania, 2021

13:45 - 14:00

(Data) Engineering vs (Data) Science - March 24 14:00 - 14:45 - Dino Esposito

Single-tenant to multi-tenant, a real world example - March 24 15:00 - 15:45 - Iris Classon

Trailblazor: Building Dynamic Applications with Blazor - March 24 16:00 - 16:45 - Shaun Walker

Moving a 20 year old .NET on Windows blog to Linux, Containers and Azure - March 24 17:00 - 17:45 - Scott Hanselman

Architecture – The Stuff That's Hard To Change - March 24 18:00 - 18:45 - Dylan Beattie

Notes on Sandro Mancuso — Software Craftsmanship @Talk

Highlights

Notes

JWT Token Claims in ASP.NET Core

Introduction

Additional changes

AuthenticationService

User

TokenService

UserController

GetClaims method

GetName

GetRoles

JWT Authentication with Asymmetric Encryption using certificates in ASP.NET Core

Introduction

Generating the keys

Startup

SigningIssuerCertificate

SigningAudience Certificate

AuthenticationService

TokenService

AuthenticationController

ValidationController

The result

Authentication

Validation

JWT Authentication with Symmetric Encryption in ASP.NET Core

Introduction

Symmetric Key

Setup

Creating a secret key

Startup

UserCredentials

AuthenticationService

UserService

TokenService

AuthenticationController

ValidationController

The result

RabbitMQ Consumer Received Event with Docker in .NET

Introduction

Received event

Subscribing to the event

Handling the event

Consuming messages

Waiting for Cancellation

Disposing resources

The result

RabbitMQ Headers Exchange with Docker in .NET

Introduction

Producer

Exchange

Queue

`AuthenticationService`

`User`

`TokenService`

`UserController`

`GetClaims` method

`GetName`

`GetRoles`

`Startup`

`SigningIssuerCertificate`

`SigningAudience Certificate`

`AuthenticationService`

`TokenService`

`AuthenticationController`

`ValidationController`

`UserCredentials`

`AuthenticationService`

`UserService`

`TokenService`

`AuthenticationController`

`ValidationController`

`Received` event

Waiting for `Cancellation`

`Producer`

`Exchange`

`Queue`

Creating the `Consumer`

Listening to the `Queue(s)`

`DisplayQueueMessage` method explanation

Creating the `Queue`

`QueueDeclare` parameters