We’ll go over some strategies in this post to figure out why your ASP.NET web applications are using a lot of CPU power.

There are numerous reasons why w3wp.exe, your IIS worker process, might be consuming a lot of CPU power. We’ll go over some of the most common causes and how to fix issues with IIS performance.

In order to troubleshoot the IIS worker process, you should first see which web requests are currently executing with IIS and see if that helps you identify the problem.

How to See Active Internet Requests in IIS

Identifying the web requests that are presently being executed ought to be among your initial priorities. This could assist you in determining which particular URL is the source of the issue.

It’s possible that you will identify one of the URLs that is notorious for taking a very long time or causing high CPU problems.

On the other hand, this might also display a number of pending web requests rather than taking you straight to the source.

Via the IIS User Interface

Viewing the active worker processes is possible through the IIS management console. You can see which IIS application pool is using a lot of CPU time as well as the web requests that are presently active.

You can view the IIS worker processes that are currently active by choosing “Worker Processes” from the main IIS menu.

A worker process’s executing requests can all be seen by double-clicking on it.

A sample from one of our servers is provided here. As you can see, every request is presently executing a different HTTP module and is situated in a different section of the ASP.NET pipeline.

Via Command Line

The currently active web requests is just one of the many uses for the appcmd.exe utility.

C:\Windows\System32\inetsrv>appcmd list requests
REQUEST "f20000048000021c" (url:GET /nopcommerce, time:6312 msec, client:localhost, stage:BeginRequest, module:IIS Web Core)

Understanding The Results & Things to Look For

Using the command line or IIS user interface, you can see which web requests are active at any given time. It returns the same data in either case.

• URL: the complete URL that was being executed.
• Time: the total amount of time, in milliseconds, the web request has been executing.
• Client: the address of the user that initiated the request.
• Stage: the stage of the IIS pipeline that the request is currently in.
• Module: the ASP.NET module that is currently executing.

When reviewing the requests, there are a few things you should be aware of.

• Does each request point to the same URL? It’s possible that the issue originated from that URL.
• Do a lot of requests originate from the same customer? Maybe a particular user is overloading your web server with requests.
• Do all of the requests remain in the same module or stage? Requests hanging at that particular IIS pipeline stage might be the cause of the issue.

6 Typical Reasons and Solutions for IIS Worker Process High CPU

There are numerous reasons why the CPU usage of the IIS Worker Process, w3wp.exe, may be high. I’ll be discussing six prevalent causes in this post:

 1. High Error Rates Within Your ASP.NET Web Application

It’s possible that your application has application errors and you are unaware of them. Your users may receive an error message of some kind when there are certain errors. There could be more mistakes made without anyone noticing.

Make sure to check any application performance management or error monitoring tools you use for high error rates.

You can check Windows Event Viewer, IIS Logs, and other places for application error rates and actual errors.

Windows Performance Counters for Error Rates

I would advise looking over two particular performance counters for high error rates. By adding the counters to the chart view and launching Performance Monitor in Windows, you can verify these.

• .NET CLR Exceptions -> # of Exceps Thrown / sec: Examine this to determine whether your application is throwing a lot of exceptions. Your application may contain numerous hidden errors that could seriously impair performance.Though some exceptions cannot be avoided, they are still undesirable.
• W3SVC_W3WP -> % 500 HTTP Response Sent: A 500 status code indicates an internal server error for any requests. Ensure that this percentage is extremely low. It ought to be between 0% and 1%.

2. Growing Web Traffic Resulting in High CPU IIS Worker Process

An increase in web traffic is one of the easiest explanations for the high CPU usage of w3wp.exe. However, it can be challenging to determine whether traffic has increased if you don’t have a baseline for your typical volume of traffic.

Make sure to check your application monitoring tool to see if the traffic levels have changed, if you are using one.

You could try determining whether traffic levels have changed using your IIS log files if you have no other way to know.

To query them, use Log Parser Lizard or VisualLogParser.

To view the current traffic rates in real time, there are additional Windows performance counters for Requests / Sec and Requests Current.

Possible Reasons for Higher Web Traffic

If traffic is increasing, consider whether it should be. Consider the following when considering elevated traffic levels:

• Client or user: Is there a notable increase in traffic coming from a particular user, client, or source? It’s possible that something isn’t accessing your website properly. Perhaps you should block a particular IP address.
• Bots: It might be a bot, much like a particular user generating a lot of traffic. Examine the user agents in your IIS logs that are being used to visit your website.
• Oprah effect: Has anyone mentioned your products, including Oprah? Have you recently gone viral? It’s great to receive a lot of attention, but you might have to increase your capacity to manage it.

You might need to scale out (add more servers) or scale up (get a bigger server) if your website is seeing a lot more traffic.

But traffic might not be the issue if your website receives a small number of requests every second.

Ten to thirty requests are made per second by many ASP.NET applications. On the other hand, I have also observed light web requests making more than 100 requests per second on busy apps.

There is a wide range in both the amount of traffic and CPU usage between different web apps. Everything depends on your particular application.

How to Spot Pricey Online Requests

Garbage collection is used by Microsoft.NET to control memory allocation and release.

The allocation and cleanup of application memory may result in a significant amount of garbage collection activity, depending on the functionality of your application. Garbage collection issues arise, for instance, when numerous large string variables are used on a large object heap.

Use this Windows Performance Counter to see whether garbage collection is interfering with your application.

.NET CLR Memory -> % Time in GC: This counter shows the percentage of time that is spent on garbage collection by your application. Should this figure significantly rise above 5–10%, you should look into memory usage in more detail.

Garbage collection also has two modes. You may need to enable server mode, which is not the default.

5. The ASP.NET Pipeline is blocking and hanging requests.

I would advise checking to see if all of the requests appear to be hanging on a single HTTP module if you are experiencing performance issues.

Both managed.NET code and native code can be used in HTTP modules. These could be common.NET modules like SessionStateModule or FormsAuthentication. A lot of apps also make use of proprietary or third-party HTTP modules.

Resolution

The following actions can be taken to fix the Server Error in ‘/’ Application error:

Examine the error message. Usually, the error message will include some details about what went wrong.

Investigate and explore the stack trace. Stack trace aids in identifying the error and its location.

Enable detailed error messages: By default, ASP.NET is configured to display generic error messages. You can enable detailed error messages by modifying the web.config file. Find the <system.web> section in the file and set the customErrors mode to “Off” like this: This will display detailed error messages that can help you identify the problem

<configuration>
  <system.web>
    <customErrors mode="Off" />
  </system.web>

Check your code for any logical or syntactic mistakes that might be the source of the issue.

Look through the web server’s error logs. Server logs typically contain more details to address Server Error in ‘/’ Application error. A lot of information about the error’s location and description can be found in error logs. They will be simpler to fix.

Rebuild and redeploy your application: Rebuild and redeploy your application to the web server after making any modifications.

In the event that your application makes use of a database, confirm that the database is reachable and that the connection string is accurate.

You can fix the Server Error in ‘/’ Application error in your ASP.NET MVC application by following the above steps.

Understanding the Error 405

Understanding the general meaning of the “405 Method Not Allowed” error is essential before delving into the details of the ASP.NET Core scenario. The error is an HTTP response status code that says that although the target resource for the specified URI does support the request method, the web server has acknowledged it.

Common Reasons for ASP.NET Core on IIS Error 405

• WebDAV Module: The WebDAV module is usually to blame when hosting ASP.NET Core applications on IIS. Using both PUT and DELETE requests, this module is intended for online authoring. Applications that depend on these techniques may be affected if it is not configured properly.
• Missing or Incorrect Verb Handlers: Verb handlers are used by IIS to handle requests. You’ll see a 405 error if these handlers aren’t set up properly for PUT or DELETE.

Solution

If your application does not require WebDAV, you can resolve many issues by simply disabling the WebDAV module. Add the following code to your web.config file:

<system.webServer>
    <modules runAllManagedModulesForAllRequests="false">
        <remove name="WebDAVModule"/>
    </modules>
    <handlers>
        <remove name="WebDAV" />
    </handlers>
</system.webServer>

Additional Tips

• Enable Detailed Error Messages: Be sure your IIS server is set up to display comprehensive error messages in order to gain a better understanding of the underlying cause. This will give additional background information and might even identify the offending module or handler.
• Logging: Include logging in your application for ASP.NET Core. Comprehensive logs that can provide insights into potential problems can be captured by programs like Serilog or the integrated ILogger.
• Check Route Configurations: Make sure the methods you’re attempting to invoke are supported by your ASP.NET Core routing configurations.

Conclusion

With the correct knowledge of its causes and the appropriate resources at your disposal, the “405 Method Not Allowed” error in an ASP.NET Core application hosted on IIS can be overcome. Never forget that every application is different, so before making any changes to infrastructure or configurations, make sure you test everything thoroughly.

When I was looking at some code, I noticed that the logs were always there, but when I looked closer, I realized that they were frequently irrelevant because they contained little to no significant information. Particularly when there is a problem in the production environment, we often let details that can make a big difference escape due to lack of time, distraction, or ignorance.

In this article, we’ll go over some crucial issues relating to logs and how to use them efficiently while adhering to best practices and making sure they’re pertinent for upcoming data analysis.

1. Log Levels and .NET Logging

The logging severity levels are defined by the C# Enum named LogLevel in the.NET context. The Assembly contains extension methods that provide log level indication. Microsoft.Extensions.Logging.Abstractions.

The table of log levels in.NET Core is shown below.

These are the log levels, and you should use them in the appropriate situations. For each level, there are some real-world examples below.

Usage Examples for Each Level

public class LogService
{
    private readonly ILogger<LogService> _logger;

    public LogService(ILogger<LogService> logger)
    {
        _logger = logger;
    }

    public void ProccessLog()
    {
        var user = new User("John Smith", "smith@mail.com", "Kulas Light", null, null);

        //Trace
        _logger.LogTrace("Processing request from the user: {Name} - {ProccessLog}", user.Name, nameof(ProccessLog));


        //Debug
        var zipcodeDefault = "92998-3874";
        if (user.Zipcode == zipcodeDefault)
            _logger.LogDebug("The zip code is default for the user: {Name} - {ProccessLog}", user.Name, nameof(ProccessLog));


        //Information
        _logger.LogInformation("Starting execution... - {ProccessLog}", nameof(ProccessLog));


        //Warning
        if (string.IsNullOrEmpty(user.Zipcode))
            _logger.LogWarning("The zip code is null or empty for the user: {Name} - {ProccessLog}", user.Name, nameof(ProccessLog));


        //Error
        try
        {
            var zipcodeBase = "92998-3874";
            var result = false;

            if (user.Zipcode == zipcodeBase)
                result = true;
        }
        catch (Exception ex)
        {
            _logger.LogError(ex.Message, "Error while processing request from the user: {Name} the zipcode is null or empty. - {ProccessLog}", user.Name, nameof(ProccessLog));
        }


        //Critical
        try
        {
            var userPhone = user.Phone;
        }
        catch (Exception ex)
        {
            _logger.LogCritical(ex.Message, "The phone number is null or empty for the user: {Name}. Please contact immediately the support team! - {ProccessLog}", user.Name, nameof(ProccessLog));
            throw;
        }


        //None
        //Not used for writing log messages
    }
}

2. Logging Frameworks or Libraries

The functions in Microsoft Logging Assembly can be used on any system, no matter how big or small, and they satisfy the fundamental requirements for logging. However, some situations call for more customizable logs and detailed logs. The development community is aware of and accepts libraries as being helpful in these situations.

Here are some usage examples for Serilog, one of the more well-known libraries.

Serilog

The log library that has been downloaded most frequently from the NuGet website is Serilog. Serilog NuGet is where you can find it.

Serilog offers diagnostic logging for files, consoles, and a variety of other locations, just like other libraries. It is simple to configure and has a wide range of features for contemporary applications.

Below, a real-world application of its use will be shown along with some of Serilog’s numerous customization options.

Practical Example

1. Create a new console app with .NET 6.

You can do this through Visual Studio 2022 or via the console with the following command:

public record Offer(int Id, int ProductId, string Description, decimal Value, decimal Quantity);

using Serilog;
using Serilog.Templates;

ExecuteLogs();

void ExecuteLogs()
{
    LogToConsole();
    LogToFile();
}

void LogToConsole()
{
    var offer = FillOffer();

    Log.Logger = new LoggerConfiguration()
     .Enrich.WithProperty("offerId", offer.Id)
     .Enrich.WithProperty("productId", offer.ProductId)
     .Enrich.WithProperty("quantity", offer.Quantity)
     .WriteTo.Console(new ExpressionTemplate("{ {@t, @mt, @l: if @l = 'Information' then undefined() else @l, @x, ..@p} }\n"))
     .CreateLogger();

    Log.Information("Information about the Offer");
}

void LogToFile()
{
    var offer = FillOffer();

    Log.Logger = new LoggerConfiguration()
     .Enrich.WithProperty("offerId", offer.Id)
     .Enrich.WithProperty("productId", offer.ProductId)
     .Enrich.WithProperty("quantity", offer.Quantity)
     .WriteTo.File(new ExpressionTemplate(
         "{ {@t, @mt, @l: if @l = 'Information' then undefined() else @l, @x, ..@p} }\n"),
            "Logs\\log.txt",
                 rollingInterval: RollingInterval.Day)
     .CreateLogger();

    Log.Information("Information about the Offer");
}

Offer FillOffer() =>
        new Offer(5488, 100808, "Book", 109, 3);

And in the folder: “\bin\Debug\net6.0\Logs” is the created file. Inside it will be the same data that was displayed in the console.

In this example we created two methods:

• “LogToConsole()” – It creates an object called “Offer,” then uses a new instance of “LoggerConfiguration” and adds the properties values to logging with the method “Enrich.WithProperty.” Then the method “WriteTo.Console” displays the data logging in the console, and makes the configuration of the template through the class “ExpressionTemplate.”
• “LogToFile()” – It does the same as the previous method, but uses the “WriteTo.File” method to create a “Logs” folder if it doesn’t exist, and inside it a text file that will store the log data. The “rollingInterval” rule determines the interval in which a new file will be created—in this example, one day—that is, the logs will be written to the same file until the day ends, and then a new file will be created.

Serilog was only briefly used in this demonstration, but it has a lot of useful features. Explore them at your leisure.

3. Best Practices and Recommendations

Structured Logs

When an application uses the Microsoft Logging Assembly or more sophisticated filtering to look for logs, the creation of structured logs is advised. The log recording mechanism needs to receive the string containing the placeholders and their values separately, so it is necessary.

Here’s an illustration of a structured log:

_logger.LogWarning( "The zip code is null or empty for the user: {Name}", user.Name;

String interpolation is a viable option, but you should make sure the registration service is set up to still have access to the message template and property values after the replacement.

An illustration of a structured log using string interpolation can be found below:

_logger.LogWarning( $"The zip code is null or empty for the user: {user.Name}";

Enable Only Appropriate Logs in Production

You should take into account the actual requirements for using each of the log levels before publishing something in the production environment. For instance, excessively detailed logs may cause the server to become overloaded or the system to operate slowly.

So, before publishing anything, it’s a good idea to review all the logs and keep only the ones that are pertinent and won’t cause any sort of overhead. In a production setting, trace and debug logs must be disabled.

Using a Third-Party Logging Library

Always ask the client you’re working with if they use a third-party library and what it is before beginning a new project because you don’t want to waste your time on something that won’t be put into production because it uses private property.

Logging Sensitive Information

Never include private or delicate data in production logs, such as user-related information like passwords or credit card numbers, or any data pertaining to something that cannot be made public. Additionally to being accessible to anyone with access to logged data, this information typically lacks any encryption, making it vulnerable to disclosure in the event that a hacker attack is made against the system.

Writing Relevant Log Messages

The presence of a log message at a crucial point in the code does not guarantee that the system is ready for a thorough analysis, as its use would be unnecessary if the message didn’t make much sense in that situation.

Therefore, when writing log messages, consider what would be the most crucial data for a later analysis of the execution. For instance, always include the message produced by the “Catch” method in messages inside exception blocks.

Utilizing the name of the method used when writing the log is another suggestion that can be seen in the example below. In the example below, we are using the command “nameof(ProccessLog)” to record the name of the method that is responsible for execution.

public void ProccessLog()
{
        try
        {
        //execution...
        }
        catch (Exception ex)
        {
 //The exception message "ex.Message" is being used in the log

            _logger.LogError(ex.Message, "Error while processing request from the user: {Name} the zipcode is null or empty. - {ProccessLog}", user.Name, nameof(ProccessLog));
        }
}

Conclusion

We discussed some helpful writing techniques for effective logs in C# and.NET in this article. There are no hard-and-fast guidelines for writing logs; it all depends on the environment in which you are developing. Nevertheless, if you follow these suggestions, your code will undoubtedly get much better.

Consequently, what does a 401 Hypertext Transfer Protocol (HTTP) response code mean?

This error may be brought on by a browser issue, but in a few uncommon circumstances, it might also be a server-side issue.

The good news is that 401 error codes are frequently simple to resolve. In fact, if you can locate the error’s cause, you might be able to resolve the issue on your own.

Learn the reasons why 401 errors occur as well as how to fix and avoid them by reading on.

What is a 401 error?

This error message may appear when you try to access a website using an invalid URL, a username or password that isn’t correct, or an out-of-date browser cache.

Most of the time, repairing client-side errors can quickly fix the problem. In other instances, the problem might be server-side, where the web server denies a client’s attempts to access a requested resource even though those attempts are legitimate.

This could be the result of willful modifications a user made to the server or an unintentional error during the authentication process.

When you run into this issue, an error message will appear in your browser. The 401 error appears under various titles on various platforms. Examples of what you might see are as follows:

• 401 authorization required.
• 401 unauthorized error.
• Error 401 unauthorized.
• HTTP error 401 – unauthorized.
• HTTP 401.
• Access denied.

Here, the error code itself—not the text variations around it—is what matters most. No matter what your browser shows you, the error code lets you know what the issue is. It’s also essential to finding a solution.

Typical reasons for 401 errors on ASP.NET websites

Let’s take a closer look at the possible causes of the 401 error code on your ASP.NET website before discussing possible fixes.

1. Incorrect URLs

Typos happen to everyone occasionally. Incorrectly entering a URL (Uniform Resource Locator) can result in issues ranging from 401 errors to misdirection.

How about if the URL is accurate? You might be trying to access an old page that has been moved or deleted.

In either scenario, the client tries to access the resource you want via an illegal or invalid path, and the server may reject your request.

2. Expired cache and cookies

Cookies “remember” your device and browser by “remembering” the HTTP cookies that your browser uses to store browser data in your memory. A quick browsing experience depends on cookies and the browser cache.

Today’s cookies also save your level of authentication. As a result, you won’t need to log in each time you access a website or social media platform. Browser cookies make sure the server sends you information based on your authorization level while keeping your online session active.

You might get a 401 Unauthorized error due to improper authentication if your cookies expire or if your cache is corrupted or cleared.

3. Firewall and plugin configurations

Instances of trying to access specific pages may result in 401 errors if you’ve recently installed a firewall or new plugin on your ASP.NET website.

For instance, even if you have administrator access, some security tools may completely take over your website and limit access to particular pages.

Any login attempts might be interpreted as malicious activity by the tools because it runs diagnostics on your website to improve it. This might result in a 401 error page appearing on your website.

4. Protected URLs

At the server level, access to particular URLs may be strictly controlled or managed. These restricted resources are only accessible to authorized personnel. In this situation, accessing the URL from an unauthorized web browser might result in a 401 error.

Troubleshooting 401 errors

A 401 error is frequently a client-side rather than a server-side problem, as we have already discussed. As a result, fixing it is frequently simple. Here are some options you could try:

1. Verify the URL

Verifying that the URL being used is valid or correct is one of the simplest solutions for a 401 error. Servers reject attempts to access a website from invalid or incorrect URLs in order to secure it.

Be sure to spell check the URL first. Verify that your target URL contains the proper extension, hyphens, and special characters. You should now be able to access the website without any issues if everything looks good.

Check to see if the page address has changed since your last access if you are still receiving a 401 error. It could have been relocated or removed. Find the page you want to access by going back to the homepage. This is a common way to discover the correct link.

2. Check your login credentials

You should also double-check your login information. This error can appear on a page when you try to access a website with an incorrect username or password. Make sure your authentication credentials are up to date and that you are using the username and password appropriately.

You can try to reset or recover the password if you’ve forgotten it.

3. Clear and reload the browser cache and cookies

The majority of contemporary browsers, as was mentioned above, save your authentication status in cookies and the website’s cache. In this manner, you can always continue where you left off.

Since most page files are temporarily stored in your device’s memory to maintain the status of your logins, the cache also aids in accelerating browsing.

A 401 error is frequently generated when trying to access a web app with expired cookies.

Clearing all cookies from the problematic website and refreshing the page are simple fixes for this. You can also reload the page and clear your browsing history. This might entail starting a fresh session.

You can also delete all cache files and make room for new files and logins by clearing the cache. Often, doing so resolves 401 unauthorized access errors.

Depending on your browser, there are different ways to clear cookies.

4. Check for DNS changes

Changes to your domain name server (DNS) can result in 401 errors, although they are less common than other issues. Your device typically has DNS records to aid in matching URLs to IP addresses.

You might need to flush your DNS cache if it contains outdated or invalid URLs and IP addresses.

Using the command line, you can force your device to refresh and authenticate the URLs as well as clear the DNS cache.

Run the ipconfig/flushdns command from the Windows command prompt. Windows will indicate that the DNS cache has been flushed by displaying a message.

Run the Mac’s sudo killall -HUP mDNSResponder command.

5. Disable passwords on pages

It may be possible to fix this error code by disabling password protection on some of your website’s pages.

6. Check the WWW-Authenticate header response

It could be a more serious server-side issue if none of these troubleshooting techniques worked.

Check the WWW-Authenticate header on your website as the next step. Access to administrators is necessary for this.

A WWW-Authenticate header field with at least one challenge is sent to the target resource when a server generates a 401 response. A browser must frequently pass this header’s fixed authentication process in order to access the desired page.

You can find the issue and resolve it by comprehending the response and the needed authentication strategy.

To access the WWW-Authenticate header:

1. Open the problematic page in your browser. If you’re using Google Chrome, right-click the page and select inspect. Click Shift + Control + C to open the browser console on Firefox.
2. Select the entry with the 401 error message under the network tab.
3. Click the headers tab. Under the WWW-Authenticate entry in the response headers section, find the server’s authentication method that allows access to the webpage.

Once you’ve accessed this page, you can identify the error and learn how to fix the authentication issue.

7. Contact your host

If you’ve tried everything but it hasn’t worked, you can ask your hosting company for assistance. The technical support staff of your host can investigate your website and assist you in troubleshooting 401 and other HTTP errors.

Conclusion

Although a 401 HTTP response code can be inconvenient, once you comprehend how it functions, you can fix the problem on your own.

You might be using an incorrect URL or login information; you can fix those problems from your browser. You might also need to log back into your website after clearing the cache, cookies, and history from your browser. Try the more involved steps on this list if these don’t resolve the issue.

Looking for reliable ASP.NET hosting partner? Check out these best ASP.NET hosting provider that help your website work faster and secure!

Configuring Localization in ASP.NET Core

The RequestLocalizationMiddleware middleware must be configured in order to configure localization in ASP.NET Core, which uses middleware to configure the majority of its cross-cutting features. Based on the data sent by the client, this middleware enables the automatic setting of the culture for HTTP requests.

Create a new ASP.NET Core MVC Web Application called AspNetCoreLocalizationDemo in Visual Studio 2019 by clicking the “New” button. Open the Startup.cs file and call the AddLocalization method to configure the localization middleware. The localization services are added to the services container by the AddLocalization method. The relative path under the application root where the resource files are located is specified by the ResourcePath property.

services.AddLocalization(options =>
{
    options.ResourcesPath = "Resources";
});

Additionally, the AddViewLocalization method, which we will use later in this tutorial, adds support for localized view files.

services.AddControllersWithViews()
    .AddViewLocalization();

Note that the AddDataAnnotationsLocalization method in ASP.NET Core also adds support for localized DataAnnotations.

Next, we must decide which cultures our application will support and which one will serve as the default culture. Let’s configure these three cultures as follows since I want to support the French, German, and English languages in this tutorial:

services.Configure<RequestLocalizationOptions>(options =>
{
    options.DefaultRequestCulture = new RequestCulture("en-US");
 
    var cultures = new CultureInfo[]
    {
        new CultureInfo("en-US"),
        new CultureInfo("de-DE"),
        new CultureInfo("fr-FR")
    };
 
    options.SupportedCultures = cultures;
    options.SupportedUICultures = cultures;
});

Following is the complete code of the ConfigureServices method.

public void ConfigureServices(IServiceCollection services)
{
    services.AddLocalization(options =>
    {
        options.ResourcesPath = "Resources";
    });
 
    services.AddControllersWithViews()
        .AddViewLocalization();
 
    services.Configure<RequestLocalizationOptions>(options =>
    {
        options.DefaultRequestCulture = new RequestCulture("en-US");
 
        var cultures = new CultureInfo[]
        {
            new CultureInfo("en-US"),
            new CultureInfo("de-DE"),
            new CultureInfo("fr-FR")
        };
 
        options.SupportedCultures = cultures;
        options.SupportedUICultures = cultures;
    });
}

The localization middleware must be enabled using the UseRequestLocalization method as the last configuration step.

app.UseRequestLocalization();

The RequestLocalizationOptions object we configured above is initialized by the UseRequestLocalization method. RequestCultureProvider is a concept in the RequestLocalizationOptions that decides the culture information in each request. We will cover these providers in greater detail later in this tutorial. The RequestLocalizationOptions class configures the QueryStringRequestCultureProvider, CookieRequestCultureProvider, and AcceptLanguageHeaderRequestCultureProviders as default providers. The list of RequestCultureProvider is enumerated when requests arrive at the server, and the first provider that can successfully identify the request culture is used. The DefaultRequestCulture property setting will be used in the event that none of the providers are able to identify the request culture.

options.DefaultRequestCulture = new RequestCulture("en-US");

The foundational localization settings for our application are now set up. The location and naming guidelines for the resource files must be chosen next.

Resource Files Naming Conventions and Location

We can separate the localizable resources, such as strings, icons, images, etc., from the source code by using a resource (.resx) file. We typically include information about the culture in the file name when creating resource files for various languages and cultures. For instance, the file name for a resource file to store resources in English would be MyResourceFile.en.resx. The file name will be MyResourceFile.en-US.resx if you want to make a separate resource file for US English. You can right-click on the folder where you want to create the resource file and select Add > New Item from the menu in Visual Studio to create a new resource file.

The full type name of the class is used by ASP.NET Core localization to find the resource files in the project. For instance, the resource file name would be as follows if we were to create French language resources for the HomeController of our AspNetCoreLocalizationDemo application.

AspNetCoreLocalizationDemo.Controllers.HomeController.fr-FR.resx

Another strategy is to save the resource file next to the HomeController class with the name HomeController.fr-FR.resx. The English, French, and German resource files that were created alongside the HomeController class are displayed in the following screenshot.

Please be aware that the ResourcesPath property has been set as follows in the Startup.cs file’s ConfigureServices method:

options.ResourcesPath = "Resources";

It implies that we can now create the Resources folder and place all resource files in it in the project root folder. The resource files can also be organized using nested folders with the same naming patterns. For instance, we could make a Controllers folder inside the Resources folder and move the three HomeController-related resource files there.

Depending on how you want to organize your resource files, you can either use the dot naming convention or copy the file path. If you want to mimic the path, your resource file will be located at Resources/Controllers/HomeController.en-US.resx, whereas if you want to use the dot naming convention, you will name your file as Resources/Controllers.HomeController.en-US.resx.

Let’s add some string resources to the three resource files by opening them all. The two English language string resources added to the HomeController.en-US.resx resource file are shown in the following screenshot.

The following screenshot shows the two French language string resources added in HomeController.fr-FR.resx resource file.

The following screenshot shows the two English language string resources added in HomeController.de-DE.resx resource file.

Introducing .NET Core Localizer Services

Localized services are a new concept introduced by.NET Core to increase developer productivity. These services can give you access to the resources saved in resource files and can be injected using dependency injection. These are the three localizer services:

1. IStringLocalizer or IStringLocalizer<T>
2. IHtmlLocalizer or IHtmlLocalizer<T>
3. IViewLocalizer

Using IStringLocalizer Service

A service that offers localized strings is represented by IStringLocalizer. As shown in the code snippet below, let’s inject the IStringLocalizerT> into the application’s HomeController.

HomeController.cs

public class HomeController : Controller
{
    private readonly IStringLocalizer<HomeController> _stringLocalizer;
 
    public HomeController(IStringLocalizer<HomeController> stringLocalizer)
    {
        _stringLocalizer = stringLocalizer;
    }
 
    public IActionResult Index()
    {
        ViewData["PageTitle"] = _stringLocalizer["page.title"].Value;
        ViewData["PageDesc"] = _stringLocalizer["page.description"].Value;
 
        return View();
    } 
}

When the localizer is ready, you can use its indexer to retrieve the localized strings from the resource file that correspond to the current cultural context. Using the keys page.title and page.description, we are retrieving localized strings in the aforementioned example and storing them in a ViewData object. In our razor view, we can then access this ViewData object and display the localized strings as displayed in the example below.

Index.cshtml

<div class="text-center">
    <h1 class="display-4">
        @ViewData["PageTitle"]
    </h1>
    <p>
        @ViewData["PageDesc"]
    </p>
</div>

If you run the application, the localized strings in English will appear on the page.

By directly injecting the IStringLocalizerT> into your razor views, as shown in the following code snippet, you can avoid having to pass strings from controllers to views using the ViewData object and cut down on some of the code from the above example.

Index.cshtml

@using AspNetCoreLocalizationDemo.Controllers
@using Microsoft.Extensions.Localization
 
@inject IStringLocalizer<HomeController> Localizer
 
<div class="text-center">
    <h1 class="display-4">
        @Localizer["page.title"]
    </h1>
    <p>
        @Localizer["page.description"]
    </p>
</div>

Using IHtmlLocalizer Service

Let’s introduce the HTML bold tag to your string to add some HTML content, as seen in the screenshot below.

You will notice that the browse does not display the formatted string if you run the application right away. This is due to the IStringLocalizer’s inability to encode the HTML that is present in the strings. Utilize IHtmlLocalizer, which will HTML-encode the resource string’s HTML characters but not the resource string itself.

The injection and use of IHtmlLocalizer are very similar to those of IStringLocalizer. The following shows how IHtmlLocalizer is used in the razor view.

Index.cshtml

@using AspNetCoreLocalizationDemo.Controllers
@using Microsoft.AspNetCore.Mvc.Localization
@using Microsoft.Extensions.Localization
 
@inject IStringLocalizer<HomeController> Localizer
@inject IHtmlLocalizer<HomeController> HtmlLocalizer
 
<div class="text-center">
    <h1 class="display-4">
        @Localizer["page.title"]
    </h1>
    <p>
        @HtmlLocalizer["page.description"]
    </p>
</div>

Restart the application, and the word “home page” should appear bold this time.

Using IViewLocalizer Service

A view receives localized strings from the IViewLocalizer service. The naming convention and location of the resource files become even more crucial when we use the IViewLocalizer service. This is so that the resource file can be located using the view file name rather than the default implementation of IViewLocalizer. This also implies that IViewLocalizer cannot use the global shared resource files.

Create a resource file called Index.en-US.resx at the ResourcesViewsHome folder with the name Index.razor since our view file’s name is Index.razor, as shown in the following screenshot.

For demonstration purposes, let’s add a different string in the Index.en-US.resx file.

To use IViewLocalizer, inject it in the Index.cshtml file as shown in the code snippet below.

Index.cshtml

@using AspNetCoreLocalizationDemo.Controllers
@using Microsoft.AspNetCore.Mvc.Localization
@using Microsoft.Extensions.Localization
 
@inject IStringLocalizer<HomeController> Localizer
@inject IHtmlLocalizer<HomeController> HtmlLocalizer
@inject IViewLocalizer ViewLocalizer
 
<div class="text-center">
    <h1 class="display-4">
        @Localizer["page.title"]
    </h1>
    <p>
        @HtmlLocalizer["page.description"]
    </p>
    <p>
        @ViewLocalizer["view.breadcrumb.text"]
    </p>
</div>

When you rerun the application, you should see the words “Home – Index” displayed on the page thanks to the IViewLocalizer service.

You can add more languages and set any language as your default language if you’re using the Chrome browser by going to Settings. For instance, I added the German language to the screenshot below and instructed the Chrome browser to display everything in German.

Run your application right away to see the translated strings from the German language resource file displayed on the page.

Overview of Default Request Culture Providers

There are some request culture providers included right out of the box when we configure and use the request localization in.NET Core. In our application, we have the option to either use these default providers or define our own unique request culture provider. The list of default request culture providers is provided below.

1. AcceptLanguageHeaderRequestCultureProvider
2. QueryStringRequestCultureProvider
3. CookieRequestCultureProvider

AcceptLanguageHeaderRequestCultureProvider

Web browsers automatically send the client culture along with each request using the Accept-Header, which is typically set to the user’s native language. The tools in the Chrome browser make it simple to see this header and its value. For instance, because I added the German language in the earlier section, my browser is currently displaying both en-US and de-DE.

QueryStringRequestCultureProvider

To override the culture, you can pass a query string to this provider. Because the query string’s culture value can be changed, developers can quickly test or debug various cultures. Culture and ui-culture parameters can be passed to the query string provider. One of the two culture or ui-culture values may be passed in place of the other, and the query string provider will set both values using that value. By including fr-FR in the query string, let’s test this provider in our application. You’ll notice that the page’s contents are converted to French strings right away.

Let’s change the value to de-DE and the page contents will update accordingly.

CookieRequestCultureProvider

To establish the culture, most production apps typically use cookies. The cookie with the name is used by the CookieRequestCultureProvider.AspNetCore.Culture by default, and you can use the tools in your browser to see how the cookie value is formatted. c=%LANGCODE%|uic=%LANGCODE%, where c stands for Culture and uic for UICulture, is the cookie format.

Switching Language in ASP.NET Core Applications

Now that we are aware of the standard methods for changing the ASP.NET Core application culture, such as Accept-Header, the query string, and cookies, let’s build a sample demo that will give the application’s end user the option to switch to a different language at runtime using one of the standard methods mentioned above. To display supported cultures in a dropdown at the top of the page, we must first obtain the list of supported cultures. The following code snippet should be added to the top of the _Layout.cshtml file after opening it.

_Layout.cshtml

@using Microsoft.AspNetCore.Builder
@using Microsoft.AspNetCore.Localization
@using Microsoft.Extensions.Options
 
@inject IOptions<RequestLocalizationOptions> LocOptions
 
@{
    string returnUrl = ViewContext.HttpContext.Request.Path;
 
    var requestCulture = Context.Features.Get<IRequestCultureFeature>();
    var cultureItems = LocOptions.Value.SupportedUICultures
        .Select(c => new SelectListItem { Value = c.Name, Text = c.DisplayName })
        .ToList();
}

Access to the collection of feature interfaces for the current request is made possible by the HttpContext’s Features property. We are particularly interested in the IRequestCultureFeature, which stands for the feature that conveys details about the culture of the active request.

var requestCulture = Context.Features.Get<IRequestCultureFeature>();

We are using the RequestLocalizationOptions object to retrieve the complete list of supported cultures that we configured in the Startup.cs file at the beginning of this post. In order to bind the SelectListItem with the HTML select control, we are also creating a SelectListItem from the list of SupportedUICultures.

var cultureItems = LocOptions.Value.SupportedUICultures
        .Select(c => new SelectListItem { Value = c.Name, Text = c.DisplayName })
        .ToList();

The asp-items property will be used to link the HTML select dropdown with the cultures in the form that will be added to the top navigation bar. To ensure that the current culture is pre-selected automatically on page refresh, the current culture name is also bound with the asp-for property. Additionally, I automated the submission of the form to the ChangeLanguage action method, which will perform all the magic for us, using the onchange event.

<ul class="navbar-nav flex-grow-1">
    <li class="nav-item">
        <a class="nav-link text-dark" asp-area="" asp-controller="Home" asp-action="Index">Home</a>
    </li>
 
    <li class="nav-item">
        <form asp-action="ChangeLanguage" asp-controller="Home" method="post">
 
            <input type="hidden" id="returnUrl" name="returnUrl" value="@returnUrl" />
 
            <select id="culture"
                name="culture"
                class="form-control"
                onchange="this.form.submit();"
                asp-items="cultureItems"
                asp-for="@requestCulture.RequestCulture.UICulture.Name">
            </select>
 
        </form>
    </li>
</ul>

The primary function of the HomeController class’s ChangeLanguage action method is to create a cookie with the currently selected culture and add it to the HTTP response cookies collection. It takes the culture and returnUrl as parameters.

[HttpPost]
public IActionResult ChangeLanguage(string culture, string returnUrl)
{
    Response.Cookies.Append(
        CookieRequestCultureProvider.DefaultCookieName,
        CookieRequestCultureProvider.MakeCookieValue(new RequestCulture(culture)),
            new CookieOptions
            {
                Expires = DateTimeOffset.UtcNow.AddDays(7)
            }
    );
 
    return LocalRedirect(returnUrl);
}

You only need that one line of code to implement language switching. The page contents will be automatically translated to French when you launch the application and choose French from the dropdown.

Now try to select the German language from the dropdown and the page contents will update accordingly.

At this point, if you check the cookies in the browser developer tools, you will see that the culture is currently set to German.

Summary

Many web developers find localization to be a frightening subject, but you will agree with me that ASP.NET Core has made localization incredibly easy to implement. The configuration of multiple languages, the creation of localized string resources, and the use of the default request culture providers were all covered in this post. Additionally, we have mastered the art of dynamic language switching. I sincerely hope this post was helpful to you. Please leave your feedback in the section below if you have any suggestions or comments. Don’t forget to spread the word about this tutorial to your friends and neighbors.

ASP.NET Core Basic Logging

As I mentioned before, the default logging framework that comes with Asp.net core is already set up when you start a web application builder. You don’t need to do anything because the default configuration adds console, debug, event source, and event log as described in the documentation.

Using a logging provider (use case: Serilog)

Let’s discuss about providers before getting into the meat of this piece. Since we’ll discuss both serilog and the standard ASP.net core logging system. Other logging providers that will improve your logging can be used with ASP.net core. You should make use of the robust features offered by these companies. We will utilize serilog as our supplier in this article.

Adding Serilog to your project

Serilog configuration is simple. Add the “Serilog.AspNetCore” nugget package to your project. Serilog must be configured after the nugget package has been included. Use this code fragment in your program.cs (Dotnet 6+) to add console logging, make serilog the default provider, and load configurations from our appsettings file.

Log.Logger = new LoggerConfiguration()
       .WriteTo.Console()
       .ReadFrom.Configuration(builder.Configuration)
       .CreateLogger();

builder.Host.UseSerilog();

Following this, we can expand the appsettings.json file’s configuration choices. For instance, you could use the following to modify the log level in serilog:

 
   "Serilog": {
    "MinimumLevel": "Debug",
}

You might use the following to limit this log level to a certain logging context or namespace. Keep in mind that this is highly configurable. I’ll include links to places where you may learn more about these settings options at the end of this article.

   "Serilog": {
    "MinimumLevel": {
      "Override": {
        "Default": "Debug",
        "Microsoft.AspNetCore": "Information"
      }
    }
}

1. To correctly delimit your logs, use scopes.

A logging scope is defined. I’ll use Microsoft’s explanation. “A series of logical operations can be grouped into a scope. The same data can be attached to each log that is produced as part of a set using this grouping.

Here, we’ll add scopes that cover whole HTTP requests as well as a user-id or client-id scope, allowing us to identify which user or client of our API is executing which action at any given time. This eliminates the need to repeatedly type the user id or client id in each log for the appropriate logs and clearly delimits the logs, even in the inner level logs of the framework. It also results in cleaner code. Here’s how we go about it:

NB: Scopes are called in using statements because some resources need to be freed once the scope is done.

• We must intercept http requests at the beginning and determine whether they are authentic. If so, we define the scope using the user’s ID or the API client’s ID. If not, the request flow is simply continued. We’ll need a middleware for this.

public class CurrentCallerScopeLoggingMiddleware
{
    private readonly RequestDelegate _next;
    private readonly ILogger<CurrentCallerScopeLoggingMiddleware> _logger;

    public CurrentCallerScopeLoggingMiddleware(RequestDelegate next, 
        ILogger<CurrentCallerScopeLoggingMiddleware> logger)
    {
        _next = next;
        _logger = logger;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        if (context.User.Identity is { IsAuthenticated: true })
        {
            //TODO: It might be a good idea to add both user id and client id at the same time.
            //If the caller is authenticated and he is a client like an API client this value will not be null.
            var clientId = context.User?.Claims?.FirstOrDefault(claim => claim.Type == "client_id")?.Value;

            if (context.User?.HasClaim(c => c.Type == ClaimTypes.NameIdentifier) ?? false)
            {
                var userId = context.User.Claims.FirstOrDefault(c => c.Type == ClaimTypes.NameIdentifier)?.Value;
                //Let the current user be taken as the request scope.
                using (_logger.BeginScope("User Id: {UserId}", userId))
                {
                    await _next(context);
                }
            }
            else if (!string.IsNullOrEmpty(clientId))
            {
                //Let the current user be taken as the request scope.
                using (_logger.BeginScope("Client Id: {ClientId}", clientId))
                {
                    await _next(context);
                }
            }
        }
        else
        {
            await _next(context);
        }
    }
}

• Our middleware must be included to the project. Note that if it is introduced before the middleware for authentication, authentication will not take place until it is called. And that’s not what we want.

        app.UseAuthentication();
        app.UseMiddleware<CurrentCallerScopeLoggingMiddleware>();
        app.UseAuthorization();     

Your logs will be properly defined after doing this, which will make diagnosis easier.

Here is a fantastic post I made about CQRS Command Validation with Mediatr in Asp.net Core in case you utilize CQRS. This post, in my opinion, will be very helpful for all developers, but especially for those that incorporate validation logic into their Command and Query business logic.

2. Make use of structured logging features: Logging in JSON Format

The second ASP.NET core structured logging mechanism is presented here. Let’s define structured logging first. This is the process of logging application events in a well-organized and consistent manner, facilitating reading, searching, and interpreting the logs. Compared to simply logging strings in an output, this is superior. In light of this, structuring our logs is the most effective technique to log effectively. What could be more ideal than JSON?

Configuring JSON format for your logs in ASP.net core

It is simple to configure the output format of your log entries with ASP.net core. You may accomplish this by using the “FormatterName” and “FormatterOptions” parameters found in the appsettings.json file. Here’s an illustration:

"Console": {
      "FormatterName": "json",
      "FormatterOptions": {
        "SingleLine": true,
        "IncludeScopes": true,
        "UseUtcTimestamp": true,
        "TimestampFormat": "HH:mm:ss",
        "JsonWriterOptions": {
          "Indented": true
        }
      }
    }

In the aforementioned example, I define that each console log shall be indented, contain scopes, and be in json format. Your logs will then show up in the console with the json format when you provide this.

Setting up Serilog’s JSON format for your logs

Naturally, serilog enables you to give your logs a specified structure. We’ll create a json format for our console logs in our example. Keep in mind the code above that configures Serilog? Simply make a small modification to it:

.WriteTo.Console(formatter: new JsonFormatter())

The output template can then be modified to either log solely json logs or to include more information in the log output. Here’s how to add the JSON message to logs, followed by a newline and any potential exceptions:

   "Serilog": {
    "MinimumLevel": ...
    ...
    "WriteTo": [
        {
          "Name": "Console",
          "Args": {
            "theme": ...,
            "outputTemplate": "{Message:lj}{NewLine}{Exception}"
          }
        }
    }

3. How to appropriately use logging parameters and destructure them

It is crucial to pass parameters when logging, and doing so is extremely simple. The parameter name only has to be enclosed in curly brackets and added to the logging procedure. You don’t need to preface your strings with a “$” sign. The mechanism for logging already takes care of that. The code below, for instance, logs the user’s age.

        _logger.LogInformation("User's age: {UserAge}", user.Age);

If structured logging with Json was enabled when this option was supplied, the output would be clearly documented, making it simple to query the logs using the user’s age parameter I passed. The possible output is shown in part below:

"MessageTemplate":"User's age: {UserAge}","Properties":{"UserAge":20,"S…

What about logging while passing complicated objects as parameters? Since it only uses complicated objects’ “ToString()” methods to convert them to strings, ASP.net core demonstrates its limitations in this situation. JSON objects won’t be present in your logs. Destructuring is the process of converting these parameters to json objects, which is supported by logging providers like Serilog.

Use “@” to destructure a complex parameter in serilog to json, and “$” to merely display the parameter’s type or signification. Here’s an illustration.

_logger.LogInformation("Silly info: {@Info}", new Info
{
    AccountId = 32,
    Description = "kfdoa"
});

The aforementioned code will generate a log entry in json format with the Info parameter. When structured logging is turned on, it will appear as follows:

"MessageTemplate":"Silly info: {@Info}","Properties":{"Info":{"_typeTag":"Info","AccountId":32,"Description":"kfdoa","Id":0,"Label":".....

Now, if I destroy using the $ sign, as displayed below:

_logger.LogInformation("Silly info: {$Info}", new Info
{
    AccountId = 32,
    Description = "kfdoa"
});

I get the following output:

"MessageTemplate":"Silly info: {$Info}","Properties":{"Info":"DemoApp.Api.Info","SourceContext":"…

With the help of this free, serilog-compatible open-source software, https://github.com/destructurama/attributed, you can customize how your parameters are destructured completely. It enables you to cover confidential data with “***” in the event that it is a password, for example, or to hide sensitive data when destroying objects.

You can add custom configurations to your appsettings.json file to configure destructuring. This is an illustration of the configurations I included. I’ve included links at the conclusion of this article that you may use to learn more about this feature.

"Serilog": {
    "Using": ..,
    "MinimumLevel": ...
    "Enrich": ...,
    "WriteTo": ...,
    "Destructure": [
      {
        "Name": "ToMaximumDepth",
        "Args": { "maximumDestructuringDepth": 4 }
      },
      {
        "Name": "ToMaximumStringLength",
        "Args": { "maximumStringLength": 100 }
      },
      {
        "Name": "ToMaximumCollectionCount",
        "Args": { "maximumCollectionCount": 10 }
      }
    ],
    "Properties": {
      "Application": "YouScribe.Affiliates.Api"
    }
  },

4. Don’t forget to choose the appropriate log level and select the logging category.

The structured logging method in ASP.net core that is easiest to use is this one. You only need to inject an ILogger or ILoggerT> in your class, where “T” denotes the category of logs and class type. This is covered in the documents I cited before. Once T is defined, a string containing the name of the class it belongs to will appear in every report. Here’s an illustration:

public class DemoController : BaseController
{
    public DemoController(IMediator mediator, ILogger<DemoController> logger)
    {
    }
}

 For example, if I log the following:

_logger.LogInformation("Silly info logged");

The output will contain the category and will be:

MyApi.DemoController: Information: Silly info logged

This is quite beneficial while conducting diagnostics. When an error happens, you want to know where your logs are coming from.

It is simple to specify the log level. The documentation does an excellent job of outlining how to do that here (https://learn.microsoft.com/en-us/aspnet/core/fundamentals/logging/?view=aspnetcore-7.0#configure-logging). However, what log level should you pick? The various log levels and their definitions are listed below.

• Trace: The smallest log level, used to record the most information possible. It is jam-packed with knowledge about how the system works. Write logs at this level if you wish to include a lot of specific details about how your product works internally. Additionally, due to the excessive amount of information it contains, this log level in the configurations should NEVER be activated by default in production. When attempting to resolve intricate problems that have arisen in your software, you should turn it on.
• Debug: The following level is the bottommost one. It is used to log debug information and also contains a lot of information, as the name suggests. This ought to only be used in test settings. To determine when something went wrong, you might activate it during manufacturing, but be sure to rewind to a higher level.
• Information: This is used to transmit data about how the software is utilized.
• Warning: This is utilized when your software exhibits unexpected behavior but not in a way that your system will fail. For instance, when the user’s search results are not returned.
• Error: When a system failure occurs, use this log level. failures that are unique to a particular user or usage circumstance. These errors shouldn’t prevent your machine from functioning properly.
• Critical: Use this log level if a system malfunctions. errors that are specific to a given user or usage situation. Your machine shouldn’t be rendered incapable of performing as intended by these faults.

Conclusion

What do you think of these 4 ASP.NET Core structured logging techniques? These are, in my opinion, the key ideas you need to understand before adding logging functionality to your ASP.NET Core application. With these, you can log expertly and cut down on your time spent on troubleshooting and diagnostics. I hope this is useful to you as you pursue software development.

In this article, we’ll go through how to enable ASP.NET Core to support experimental HTTP methods. We’ll also go through some reasons why you might not want to. Let’s get going.

The HTTP Query Method: What is it?

We should discuss HTTP Query and why others would want to utilize it in their API implementations before moving on to the C# implementation.

Queries are often delivered via the GET or POST method when developers create HTTP APIs. The URL path and the query parameters are included in GET requests. While complicated queries can be transmitted using the GET method, this approach is constrained by the HTTP standard. A URL may only contain a certain amount of data, and items in the query string must be URL encoded. The POST method, which permits more complicated query syntax in the request body, is frequently used by developers when they approach the boundaries of utilizing the GET method. Nevertheless, utilizing POST has disadvantages as well because these calls do not adhere to the same caching restrictions as GET requests and as a result, place greater strain on the host server.

With regard to caching and idempotency semantics, the QUERY method combines the advantages of the GET method with the flexibility for developers to publish a body akin to a publish request. Developers may now send any message to the server, even those using sophisticated query languages like GraphQL, SQL, LINQ, and others, thanks to the inclusion of the body.

A New HTTP Method Should Be Added To Simple API Endpoints

Fortunately, HTTP method detection in ASP.NET Core may be customized. As a result, you don’t need a lot of plumbing code to add any HTTP method. Let’s start by giving a Minimal API endpoint the QUERY function.

You may utilize the MapMethods method on IEndpointConventionBuilder when working with Minimal APIs. Any string value that ASP.NET Core could perceive as an HTTP method can be sent into the method. You may also create a MapQuery extension method to match the existing methods of MapGet, MapPost, etc. for user convenience.

public static class HttpQueryExtensions
{
    public static IEndpointConventionBuilder MapQuery(
        this IEndpointRouteBuilder endpoints,
        string pattern,
        Func<Query, IResult> requestDelegate)
    {
        return endpoints.MapMethods(pattern, new[] { "QUERY" }, requestDelegate);
    }

    public static IEndpointConventionBuilder MapQuery(
        this IEndpointRouteBuilder endpoints,
        string pattern,
        RequestDelegate requestDelegate)
    {
        return endpoints.MapMethods(pattern, new[] { "QUERY" }, requestDelegate);
    }
}

A <FuncQuery,IResult> is present in our extension function, as you would have seen. The purpose of the Query type is to model-bind our request’s body to a string. Examining this class, you may choose to implement the reading of the body in any manner you choose, perhaps including serializing it into a strongly-typed entity. However, doing so is absolutely optional.

public class Query
{
    public string? Text { get; set; }

    public static async ValueTask<Query> BindAsync(
        HttpContext context,
        ParameterInfo parameter)
    {
        string? text = null;
        var request = context.Request;

        if (!request.Body.CanSeek)
        {
            // We only do this if the stream isn't *already* seekable,
            // as EnableBuffering will create a new stream instance
            // each time it's called
            request.EnableBuffering();
        }

        if (request.Body.CanRead)
        {
            request.Body.Position = 0;
            var reader = new StreamReader(request.Body, Encoding.UTF8);
            text = await reader.ReadToEndAsync().ConfigureAwait(false);
            request.Body.Position = 0;
        }

        return new Query { Text = text };
    }

    public static implicit operator string(Query query) // implicit digit to byte conversion operator
    {
        return query.Text ?? string.Empty; // implicit conversion
    }
}

Let’s finally put our objective into practice. I’ll turn the request’s body into a LINQ expression in this illustration. This shouldn’t be done in production since an expression is C# code and might create security flaws. This sample is being used as a demo.

app.MapQuery("/people", query =>
{
    try
    {
        // database
        var people = Enumerable.Range(1, 100)
            .Select(i => new Person { Index = i, Name = $"Minion #{i}" });

        // let's use the Query
        var parameter = Expression.Parameter(typeof(IEnumerable<Person>), nameof(people));
        var expression = DynamicExpressionParser.ParseLambda(new[] { parameter }, null, query.Text);
        var compiled = expression.Compile();

        // execute query
        var result = compiled.DynamicInvoke(people);

        return Results.Ok(new
        {
            query,
            source = "endpoint",
            results = result
        });
    }
    catch (Exception e)
    {
        return Results.BadRequest(e);
    }
})
.WithName("endpoint");

Later on, we’ll call this endpoint, but for now, let’s also give ASP.NET Core MVC QUERY support.

Enhance ASP.NET Core MVC With A New HTTP Method

It is considerably simpler to integrate experimental HTTP methods into ASP.NET Core MVC. Only a class inherited from HttpMethodAttribute must be implemented.

public class HttpQueryAttribute : HttpMethodAttribute
{
    private static readonly IEnumerable<string> SupportedMethods = new[] { "QUERY" };

    /// <summary>
    /// Creates a new <see cref="Microsoft.AspNetCore.Mvc.HttpGetAttribute"/>.
    /// </summary>
    public HttpQueryAttribute()
        : base(SupportedMethods)
    {
    }

    /// <summary>
    /// Creates a new <see cref="Microsoft.AspNetCore.Mvc.HttpGetAttribute"/> with the given route template.
    /// </summary>
    /// <param name="template">The route template. May not be null.</param>
    public HttpQueryAttribute([StringSyntax("Route")] string template)
        : base(SupportedMethods, template)
    {
        if (template == null)
        {
            throw new ArgumentNullException(nameof(template));
        }
    }
}

Once it has been implemented, all that is left to do is add the new attribute to your ASP.NET Core MVC method. Let’s have a look at an action that can now process QUERY queries as the final implementation.

[Route("api/people")]
public class PeopleController : Controller
{
    [HttpQuery, Route("", Name = "controller")]
    public async Task<IActionResult> Index()
    {
        try
        {
            var body = await new StreamReader(Request.Body).ReadToEndAsync();
            var query = new Query { Text = body };

            // database
            var people = Enumerable.Range(1, 100)
                .Select(i => new Person { Index = i, Name = $"Minion #{i}" });

            // let's use the Query
            var parameter = Expression.Parameter(typeof(IEnumerable<Person>), nameof(people));
            var expression = DynamicExpressionParser.ParseLambda(new[] { parameter }, null, query.Text);
            var compiled = expression.Compile();

            // execute query
            var result = compiled.DynamicInvoke(people);

            return Ok(new
            {
                query,
                source = "controller",
                results = result
            });
        }
        catch (Exception e)
        {
            return BadRequest(e);
        }
    }
}

Because ASP.NET Core MVC’s model binding can be too complex in this instance, I’ve avoided using it. Please be considerate and email me a link to your implementation if you decide to try to build it yourself. Before fully implementing the QUERY method, you might wish to take into account your query approach.

Great! Now that a Query call from a client can be responded to, we have a Minimal API endpoint and an ASP.NET Core MVC action. Let’s look at the call method for these endpoints.

Calling our QUERY Endpoints and Actions

The following is the first restriction you’ll probably encounter while using experimental HTTP methods: The majority of the tooling you use is unaware of the method’s existence. Unfortunately, you can’t use tools like Postman, Swagger, and similar tools because of the experimental nature. Your ally is the code. Fortunately, using the HttpClient class to call the APIs is rather simple.

Despite the fact that the request might be made by any C# code housed in any code base, I’ll utilize another GET endpoint to access our Query API.

app.MapGet("/", async (HttpContext ctx, LinkGenerator generator, string? q, string? e) =>
{
    var client = new HttpClient();
    var endpoint = e switch {
        "endpoint" => "endpoint",
        "controller" => "controller",
        _ => "endpoint"
    };

    var request = new HttpRequestMessage(
        new HttpMethod("QUERY"),
        generator.GetUriByName(ctx, endpoint)
    );

    //language=C#
    q ??= "people.OrderByDescending(p => p.Index).Take(10)";

    request.Content = new StringContent(q, Encoding.UTF8, "text/plain");

    var response = client.Send(request);
    var result = await response.Content.ReadAsStringAsync();

    return Results.Content(result, "application/json");
});

The use of the HttpMethod class is the main lesson to be learned from the code above. Any string value can be entered, and in our case, we want to set the method to QUERY. Additionally, a LINQ expression will be sent to filter our dataset. The remaining code is normal for a HttpClient application.

When our GET endpoint is called, our Query endpoints are also called, and our results are then obtained.

Effects of Experimentation

While considering and trying out experimental HTTP methods in your APIs can be interesting, you should first weigh the downsides.

1. Because it’s experimental, the specification could change after you put it into practice.
2. You’ll probably have to code all interactions because your preferred tools won’t likely support your experimental techniques.
3. Typical ASP.NET Core libraries won’t function as intended. For instance, Swashbuckle (The OpenAPI library) will not materialize your endpoint schema in ASP.NET Core.
4. I am unaware of any infrastructure-related advantages of caching, load balancers, etc. Even worse, you could cause problems with your infrastructure.

Conclusion

As long as you know what to implement, ASP.NET Core allows you to add any method. This was an enjoyable experiment that, if nothing else, clarified certain endpoint resolution methods.

Thank you for reading. Happy coding!

Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header
is present on the requested resource. Origin 'http://localhost:4200' is therefore not allowed access. 
The response had HTTP status code 405.

How to Fix Error No ‘Access-Control-Allow-Origin’

1. Allow Method “Options”

A preflight request is one that the browser sends to see if the CORS settings have been correctly implemented.

Therefore, if your endpoint supports POST, PUT, or DELETE operations and the browser sends a “application/json” request, the browser sends two requests: the “OPTIONS” request first, then a POST, PUT, or DELETE request.

You must therefore enable OPTIONS: in your application’s CORS settings.

app.UseCors(builder =>
{
  builder
     .WithOrigins("http://localhost:4200", "https://localhost:4200")
     .SetIsOriginAllowedToAllowWildcardSubdomains()
     .AllowAnyHeader()
     .AllowCredentials()
     .WithMethods("GET", "PUT", "POST", "DELETE", "OPTIONS")
     .SetPreflightMaxAge(TimeSpan.FromSeconds(3600));
}
);

2. Cors is Defined Twice in Your Code

Check that you have defined CORS twice.

First add CORS to the WebApplicationBuilder Services:

var builder = WebApplication.CreateBuilder();
...
...
builder.Services.AddCors();

Then when defining the app:

var app = builder.Build();
app.UseCors(builder =>
      {
        builder
              .WithOrigins("http://localhost:4200", "https://localhost:4200")
              .SetIsOriginAllowedToAllowWildcardSubdomains()
              .AllowAnyHeader()
              .AllowCredentials()
              .WithMethods("GET", "PUT", "POST", "DELETE", "OPTIONS")
              .SetPreflightMaxAge(TimeSpan.FromSeconds(3600));
 
      }
);

var app = builder.Build();
 
// The first thing in the chain of calls is to define the CORS
app.UseCors(builder =>
      {
        builder
              .WithOrigins("http://localhost:4200", "https://localhost:4200")
              .SetIsOriginAllowedToAllowWildcardSubdomains()
              .AllowAnyHeader()
              .AllowCredentials()
              .WithMethods("GET", "PUT", "POST", "DELETE", "OPTIONS")
              .SetPreflightMaxAge(TimeSpan.FromSeconds(3600));
 
      }
);
 
...
...
 
// After that, I can do mapping, routing, redirection etc...
app.MapControllers();
app.UseRouting();
app.UseHttpsRedirection();
 
if (app.Environment.IsProduction())
{
  app.UseTokenAuthentication();
}
 
app.Run();

The distinction between authentication and authorization in API design will be discussed in this post, along with some best practices for implementing secure user authentication.

Authentication vs Authorization

Verifying a user’s or system’s identity through authentication usually entails asking for credentials like a username and password. The initial line of defense against unauthorized access to an API is authentication.

On the other hand, authorization is the process of deciding what operations a user or system is permitted to carry out within an API. Authorization is based on the user’s identity as determined by authentication and the permissions linked to that identity.

A Guide to Secure User Authentication

Use Strong Password Policies

Make it necessary for users to create secure passwords that mix upper- and lowercase letters, numbers, and special characters. Enforce password expiration rules as well to guarantee that passwords are changed frequently.

Consider factors like password complexity, expiration, and history when implementing strong password policies in your API. When using.NET or another well-known programming language, the following best practices should be kept in mind when implementing strong password policies:

1. Password complexity: Demand that users create secure, challenging passwords. This can be done by mandating that passwords have a minimum of 8 characters and be composed of a combination of capital and lowercase letters, numbers, and special characters. You can use.NET libraries like PasswordValidator to enforce these policies.
2. Password Expiration: Demand that users change their passwords frequently, preferably every 90 days. Setting password expiration policies in your API will help you accomplish this. To set password expiration policies, you can use libraries like Identity Framework from the.NET Framework.
3. Password History: By keeping track of users’ previous passwords, you can stop them from using the same password repeatedly. Use.NET libraries like PasswordHistory to enforce password history policies.
4. Account Lockout: By putting account lockout policies in place, you can stop brute-force attacks on user accounts. To implement account lockout policies, you can use.NET libraries like LockoutPolicy.

Here is some sample.NET Core code that shows how to use the PasswordValidator library to enforce password complexity policies:

services.Configure<IdentityOptions>(options =>
{
    // Password settings
    options.Password.RequiredLength = 8;
    options.Password.RequireLowercase = true;
    options.Password.RequireUppercase = true;
    options.Password.RequireDigit = true;
    options.Password.RequireNonAlphanumeric = true;

    // Lockout settings
    options.Lockout.DefaultLockoutTimeSpan = TimeSpan.FromMinutes(15);
    options.Lockout.MaxFailedAccessAttempts = 5;

    // User settings
    options.User.RequireUniqueEmail = true;
});

1. Password Settings: You can define password guidelines for users using these options. As an illustration, we stipulate that passwords must contain a combination of lowercase and uppercase letters, numbers, and special characters, and that they must be at least 8 characters long.
2. Lockout Options: Using these settings, you can set account lockout rules to guard against brute-force attacks on user accounts. In this example, we’re limiting the number of failed login attempts to 5, and setting the lockout time to 15 minutes.
3. User Settings: You can configure user-specific settings with these options, such as requiring distinctive email addresses. In this case, creating an account requires users to enter their individual email addresses.

By setting these configurations in the services.Configure<IdentityOptions>(options => method call, you can ensure that your API has strong password policies, is protected against brute force attacks, and enforces unique email addresses for user accounts. These configurations are an important step in securing your API against unauthorized access and other security threats

Implement Multi-Factor Authentication

By requiring users to provide additional authentication factors, such as a code sent to their mobile device in addition to their password, multi-factor authentication (MFA) adds an extra layer of security.

Multi-factor authentication (MFA) implementation is a crucial step in protecting your API from unauthorized access. By requiring users to provide additional authentication factors in addition to their password, MFA adds an extra layer of security. We’ll go over some best practices in this section for integrating MFA into your API using.NET or any other well-liked programming language.

MFA options include hardware tokens, authenticator apps, and SMS codes, among others. Here are a few typical procedures for integrating MFA into your API:

1. Choose an MFA Approach: Pick an MFA approach that is suitable for your API and users. Although SMS codes are a popular MFA technique, hardware tokens and authenticator apps can offer more security.
2. Integrate MFA with User Accounts: Integrate multi-factor authentication (MFA) with user accounts to make users submit additional authentication factors in addition to their passwords. Libraries like the.NET Identity Framework can be used for this.
3. Store MFA Credentials Securely: In order to stop attackers from accessing user credentials even if they have access to the database, securely store MFA credentials using encryption and hashing methods.

Here is some sample.NET Core code that illustrates how to use the Identity Framework to implement MFA:

services.AddIdentity<ApplicationUser, IdentityRole>(options =>
{
    // Configure MFA options
    options.SignIn.RequireConfirmedEmail = true;
    options.User.RequireUniqueEmail = true;
})
.AddDefaultTokenProviders()
.AddTokenProvider<EmailTokenProvider<ApplicationUser>>(TokenOptions.DefaultEmailProvider);

services.Configure<DataProtectionTokenProviderOptions>(options =>
    options.TokenLifespan = TimeSpan.FromHours(3));

services.Configure<EmailTokenProviderOptions>(options =>
    options.TokenLifespan = TimeSpan.FromDays(1));

services.AddScoped<IUserClaimsPrincipalFactory<ApplicationUser>, AppClaimsPrincipalFactory>();

services.AddScoped<EmailTokenProvider<ApplicationUser>>();

In this code, we set up the Identity Framework so that verified email addresses are needed for MFA and separate email addresses are needed for user accounts. Additionally, we are setting the token lifespan and configuring token providers for email and data protection. We are also introducing a service that will produce email tokens for MFA.

To add an additional layer of security and guard against unauthorized access, you can quickly implement MFA in your API by following these best practices and utilizing the libraries and frameworks provided by your programming language.

Use Secure Communication Protocols

Use secure protocols like TLS 1.2 or higher and HTTPS to encrypt all communications between the API and the client.

An important step in protecting your API from attackers who might try to intercept or tamper with data in transit is the use of secure communication protocols. All communications between the API and the client are encrypted and secure thanks to secure communication protocols like HTTPS. We’ll go over the best practices for integrating secure communication protocols into your API using .NET or any other well-liked programming language in this section.

The following are some typical procedures for integrating secure communication protocols in your API:

1. Use HTTPS: Use HTTPS to encrypt all communications between the API and the client. This can be done by obtaining an SSL/TLS certificate and configuring your web server to use HTTPS. In .NET, you can use the UseHttpsRedirection method to enforce HTTPS.
2. Use Secure Protocols: Use secure protocols such as TLS 1.2 or higher. TLS (Transport Layer Security) is a protocol used to encrypt data in transit and protect against eavesdropping and tampering. In .NET, you can configure the TLS protocol using the UseHttps method.
3. Use Strong Cipher Suites: Use strong cipher suites to encrypt communications between the API and the client. Cipher suites are combinations of cryptographic algorithms that are used to encrypt data in transit. In .NET, you can configure cipher suites using the UseCipherSuites method.

The following.NET Core sample code illustrates how to implement secure communication protocols:

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

    services.AddHttpsRedirection(options =>
    {
        options.HttpsPort = 443;
    });

    services.AddMvc();

    services.AddHttpsRedirection(options =>
    {
        options.RedirectStatusCode = StatusCodes.Status307TemporaryRedirect;
        options.HttpsPort = 443;
    });

    services.Configure<MvcOptions>(options =>
    {
        options.Filters.Add(new RequireHttpsAttribute());
    });
}

In order to enforce secure communication protocols, we have added HTTPS redirection to this code. Additionally, we are including a filter that uses the RequireHttpsAttribute() method to require HTTPS in all requests.

You can quickly implement secure communication protocols in your API and guard against unauthorized access and data breaches by adhering to these best practices and utilizing libraries and frameworks provided by your programming language.

Top 3 Best Secure ASP.NET Hosting

Implement Rate Limiting

To stop automated attacks on the API, such as brute force attacks, use rate limiting.

In order to protect your API from attacks that could lead to server overload, denial of service, or other security problems, rate limiting must be put into place. By using rate limiting, you can restrict how many requests a user can make to your API in a given amount of time. The best practices for implementing rate limiting in your API using.NET or any other well-liked programming language are covered in this section.

Following are some typical procedures for implementing rate limiting in your API:

1. Set Up Your Rate Limiting Plan: Select a rate limiting technique that works for both your API and your users. Limits can be set based on IP addresses, user agents, or user accounts, among other common tactics.
2. Apply Rate Limiting Middleware: Apply rate limiting middleware to make sure your rate limiting strategy is being followed. .NET libraries like AspNetCoreRateLimit can be used for this.
3. Set Rate Limits: Using the middleware library you selected, set rate limits for your API. The AddRateLimit method in AspNetCoreRateLimit can be used to accomplish this.

Here is some sample.NET Core code that shows how to use the AspNetCoreRateLimit middleware to implement rate limiting:

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

    services.AddMemoryCache();

    services.Configure<IpRateLimitOptions>(options =>
    {
        options.GeneralRules = new List<RateLimitRule>
        {
            new RateLimitRule
            {
                Endpoint = "*",
                Limit = 100,
                Period = "1m"
            }
        };
    });

    services.AddSingleton<IRateLimitConfiguration, MemoryCacheRateLimitConfiguration>();

    services.AddHttpContextAccessor();
    services.AddMvc();
}

The IpRateLimitOptions class, which enables us to set restrictions based on IP addresses, is being used in this code to configure rate limits. Additionally, we’re imposing a cap of 100 requests per minute across all endpoints. In order to handle rate limiting, we are also adding the MemoryCacheRateLimitConfiguration service.

You can easily implement rate limiting in your API and safeguard against unauthorized access and server overload by adhering to these best practices and utilizing the libraries and frameworks provided by your programming language.

Keep Password Securely

The first step in protecting your API from unauthorized access and data breaches is to store passwords securely. To stop attackers from accessing user passwords even if they gain access to the database, passwords should never be stored in plain text and should always be hashed and salted. In this section, we’ll go over the best practices for using.NET or any other well-liked programming language to store passwords safely in your API.

Here are some typical procedures for safely storing passwords in your API:

1. Use a Secure Password Hashing Algorithm: To hash user passwords, use a secure password hashing algorithm like bcrypt or Argon2. Since these algorithms are slow and computationally expensive, it is challenging for attackers to decipher hashed passwords using them.
2. Use Salt: Use a salt to add an extra layer of security when hashing passwords. To make it more challenging for attackers to break passwords using pre-generated hash tables, a salt is a random string that is added to the password before hashing.
3. Use encryption: Encrypt sensitive data, like API keys and passwords, before storing it in your database. Libraries like the.NET Identity Framework can be used for this.

Here is some sample.NET Core code that shows how to use the Identity Framework to store passwords securely:

services.AddIdentity<ApplicationUser, IdentityRole>(options =>
{
    // Configure password hashing
    options.Password.RequireDigit = true;
    options.Password.RequiredLength = 8;
    options.Password.RequireUppercase = true;
    options.Password.RequireNonAlphanumeric = true;
    options.Password.RequiredUniqueChars = 6;
    options.Password.RequireLowercase = true;

    // Configure password hashing algorithm
    options.Password.HashAlgorithm = PasswordHasherCompatibilityMode.IdentityV3;
})
.AddEntityFrameworkStores<ApplicationDbContext>();

In this code, we set up the Identity Framework to work with the secure Identity V3 password hashing algorithm, which was created for ASP.NET Core Identity. Additionally, we are setting up the password policy to demand a combination of uppercase and lowercase letters, numbers, and special characters, as well as a minimum of 8 characters. Furthermore, Entity Framework is being used to store the hashed passwords in the database.

You can easily store passwords securely in your API and guard against unauthorized access and data breaches by adhering to these best practices and utilizing libraries and frameworks provided by your programming language.

Keep an eye out for suspicious activity

Check the API for suspicious activity, such as failed login attempts or unusually high traffic, using tools like log analysis and anomaly detection.

An essential step in protecting your API from attackers who might try to exploit security holes in your system is monitoring for suspicious activity. Failed login attempts, brute force attacks, and other malicious behavior that might point to an attempt at a breach are examples of suspicious activity. In this section, we’ll go over the best methods for using.NET or any other well-liked programming language to keep an eye out for suspicious activity in your API.

Here are a few typical actions to take when looking for suspicious activity in your API:

1. Use Logging: Use logging to track and record all activity in your API. This can be done using libraries like Serilog in .NET.
2. Use Monitoring Tools: Use monitoring tools to detect and alert you to suspicious activity in your API. This can be done using tools like Application Insights in .NET.
3. Set Up Alerts: Set up alerts to notify you of suspicious activity in your API.

Here is some sample.NET Core code that shows how to use Serilog to keep an eye out for suspicious activity:

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
    // Add Serilog
    loggerFactory.AddSerilog();

    app.UseHttpsRedirection();

    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }
    else
    {
        app.UseExceptionHandler("/Error");
    }

    app.UseStaticFiles();

    app.UseRouting();

    app.UseAuthorization();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapRazorPages();
        endpoints.MapControllers();
    });
}

We are integrating Serilog into our API in this code to track all activity. Additionally, we are configuring HTTPS redirection and error handling. We also use Razor Pages and Controllers to process requests.

You can easily monitor for suspicious activity in your API and defend against unauthorized access and data breaches by adhering to these best practices and using libraries and frameworks provided by your programming language.

Conclusion

In conclusion, the design of secure APIs must include both authentication and authorization. You can help ensure that your API is safeguarded against unauthorized access and other security threats by adhering to best practices for implementing secure user authentication. You can contribute to creating an API that users and developers can rely on by following these steps.