A web page should load in no more than 2 seconds, according to Google. Google, however, aims for 0.8 seconds or less. Therefore, even if a business has the best products in the world, its overall reach — whether it comes from paid or organic traffic — will be limited if it’s coupled with a poor web experience for users.

A reputable authority in the ASP.NET community and a premium ASP.NET hosting provider, ASPHostPortal. The team at the company is passionate about informing customers about the importance of web performance as it provides highly effective yet user-friendly tools and services.

We had a conversation with Dean, VP Marketing, to gain a deeper understanding of how ASPHostPortal can improve site performance and thereby increase the potential profits of its partners. Dean explains how ASPHostPortal wants to stop its customers’ high bounce rates and unrealized profits.

ASPHostPortal responds to the demand for more ASP.NET Users

The COVID-19 pandemic has altered many aspects of life in the world, including how we communicate and conduct business. Dean claims that ASPHostPortal saw a seemingly overnight change in the digital market.

Many of our customers, who had never done so before, were rushing to create some kind of ASP.NET and ecommerce component, according to Dean. “Restaurants had not made as much progress as retailers in their transition from brick-and-mortar to digital.

Many restaurants did not have curbside pickup or delivery options, and then they all appeared at once.

The team at ASPHostPortal faced an uphill battle with the rapid increase in businesses closing down (or at least supplementing) their physical locations. The business unveiled a platform for managing and billing for agency clients as well as a new hosting service for online shops. Together, these product launches bolster ASPHostPortal’s dominance in the ASP.NET hosting market and give users the ability to reduce the milliseconds that matter most in online business.

40% Faster ASP.NET Sites and 22% More Sales Thanks to New Platform

Websites like Ecommerce, a hugely popular WordPress plugin for online stores, are catered to by the new ASP.NET hosting service from ASPHostPortal. Dean claims that the platform uses compute-optimized infrastructure, a variety of ASP.NET-specific add-ons, and optimizations to deliver online storefronts up to 40% faster.

According to Dean, “the platform offloads a lot of dynamic ASP.NET requests, making your site faster — up to 20% faster in our performance tests and possibly more depending on how the site is configured.” “For customers who have switched to that particular service, we’ve seen up to an 20% increase in sales.”

The value of ASPHostPortal goes beyond performance to include security, another important aspect of successful online store operations. Consider ASP.NET updates as an example. Although the well-known scripting language is frequently used in the creation of dynamic websites, managing its necessary software updates can be difficult for non-developers, i.e., the majority of online store owners. Dean stated that at the time of this interview, 18% of all ASP.NET sites were using unpatched or unsafe versions of ASP.NET.

Dean stated, “There is a security patch available, and all of our customers are using patched versions. “We provide our customers with the means to perform (the maintenance) on their own. We support them when they don’t, though.

Summary: Use ASPHostPortal to increase ASP.NET site performance and revenue.

ASPHostPortal has been promoting its clients’ high-speed ASP.NET sites with higher realized profits for more than ten years. ASPHostPortal constantly pushes the limits of what is possible as a recognized leader in the ASP.NET innovation space. The company’s dedication to promoting growth for its customers is reaffirmed by the most recent launches of eCommerce products.

A faster website will result in fewer bounces, according to Dean. Numerous studies have demonstrated the advantages of that performance. Conversion rates and your capacity to launch products more quickly are everything.

ASPHostPortal doesn’t have a bargain-basement price; instead, the hosting company is totally committed to the long-term value it offers to clients who are able to see it.

Once a page has been cached in the browser (or proxy), the server cannot make the cached copy be utilized in place of the updated version. Pages that are likely to change cannot, therefore, be cached at the client for very long. There is nothing we can do to change this.

We should have greater control at the server, but sadly, the built-in response caching prevents cache invalidation. Additionally, it employs the same cache duration for asking the browser to cache the page and for server-side caching. Some apps cannot use the built-in response caching due to these limitations.

We are going to investigate developing a unique response caching system. We’ll presum the following conditions:

• Allow server and client cache durations to be different
• Allow an arbitrary page to be removed from the cache at will
• Allow multiple cached pages to be removed based on a common criterion (tags)

The fundamental prerequisite is the capacity for endless caching at the server and the ability for application code to invalidate current cache entries when content changes.

Additionally, we’ll prioritize efficiency and quickness over adaptability. IMemoryCache will be used to implement the cache for a single web server. It is simple to go from using IMemoryCache to IDistributedCache in web farm scenarios, however because of this interface’s less features, the third criteria (tagged) cannot be met without a redesign.

Implementation

We will implement our caching as middleware that runs before MVC and can short-circuit the entire request pipeline if a cached page is found in order to enable it to be as quick as feasible.

We have the following flow for a page that is not in the cache:

1. Fail to retrieve page from the cache
2. Execute inner middleware (the MVC pipeline) redirecting the response to a buffer
3. Cache the page (if conditions are met)
4. Render page

The sequence is substantially shorter for a page that has already been cached:

1. Retrieve page from cache
2. Render page

The quickest way to return cached material is using middleware, but it is more challenging to allow specific page cache setup. The middleware might be utilized independently if all pages were cached using the same criteria, but for the majority of real-world sites, we require the ability to control which pages are cached and for how long. Although middleware configuration might be used, using attributes on controller actions is considerably simpler.

Controlling server caching

We’ll use a very basic action filter attribute to let us manage how specific pages are cached:

public class CacheAttribute : ActionFilterAttribute
{
    public int? ClientDuration { get; set; }
    public int? ServerDuration { get; set; }
    public string Tags { get; set; }

    public override void OnActionExecuting(ActionExecutingContext context)
    {
        // validation omitted

        if (ClientDuration.HasValue)
        {
            context.HttpContext.Items[Constants.ClientDuration] = ClientDuration.Value;
        }

        if (ServerDuration.HasValue)
        {
            context.HttpContext.Items[Constants.ServerDuration] = ServerDuration.Value;
        }

        if (!string.IsNullOrWhiteSpace(Tags))
        {
            context.HttpContext.Items[Constants.Tags] = Tags;
        }

        base.OnActionExecuting(context);
    }
}

The filter’s simple implementation only adds the attribute values to the collection of HttpContext Items. To communicate between the operation and the middleware for caching, we are using the collection.

The middleware

The primary Invoke method of the middleware is quite readable:

public async Task Invoke(HttpContext context)
{
    var key = BuildCacheKey(context);

    if (_cache.TryGet(key, out CachedPage page))
    {
        await WriteResponse(context, page);

        return;
    }

    ApplyClientHeaders(context);

    if (IsNotServerCachable(context))
    {
        await _next.Invoke(context);

        return;
    }            

    page = await CaptureResponse(context);

    if (page != null)
    {
        var serverCacheDuration = GetCacheDuration(context, Constants.ServerDuration);

        if (serverCacheDuration.HasValue)
        {
            var tags = GetCacheTags(context, Constants.Tags);

            _cache.Set(key, page, serverCacheDuration.Value, tags);
        }
    }            
}

Your requirements will determine how you construct the cache key, however it may only require the use of context.Request.Path.

The request is finished if the page can be retrieved from the cache and written to the response.

private async Task WriteResponse(HttpContext context, CachedPage page)
{
    foreach (var header in page.Headers)
    {
        context.Response.Headers.Add(header);
    }

    await context.Response.Body.WriteAsync(page.Content, 0, page.Content.Length);
}

If a cached page cannot be located, additional effort must be done. In order to determine if we may cache the request, we first set any necessary client caching headers. If another method is used, we call the following middleware component and stop processing the request because we only wish to cache GET methods.

Capturing the request output from internal middleware components is the next step. In the part after this, we go over how this is accomplished. If we’ve set up server side caching (using the action filter mentioned above), the last step is to save the page to the cache.

Capturing the response

You must replace the response body stream’s default with a MemoryStream in order to capture the page response:

private async Task<CachedPage> CaptureResponse(HttpContext context)
{
    var responseStream = context.Response.Body;

    using (var buffer = new MemoryStream())
    {
        try
        {
            context.Response.Body = buffer;

            await _next.Invoke(context);
        }
        finally
        {
            context.Response.Body = responseStream;
        }

        if (buffer.Length == 0) return null;

        var bytes = buffer.ToArray(); // you could gzip here

        responseStream.Write(bytes, 0, bytes.Length);

        if (context.Response.StatusCode != 200) return null;

        return BuildCachedPage(context, bytes);
    }
}

We return null and make no attempt to cache the response if nothing has been written to it or if the status code is not 200. If not, a CachedPage instance is returned:

internal class CachedPage
{
    public byte[] Content { get; private set; }
    public List<KeyValuePair<string, StringValues>> Headers { get; private set; }

    public CachedPage(byte[] content)
    {
        Content = content;
        Headers = new List<KeyValuePair<string, StringValues>>();
    }
}

The content of the cached page is combined with a subset of the response headers, some of which should be removed (for example, the date header).

Controlling client caching

We choose the straightforward method when it comes to providing caching headers to the browser:

public void ApplyClientHeaders(HttpContext context)
{
    context.Response.OnStarting(() =>
    {
        var clientCacheDuration = GetCacheDuration(context, Constants.ClientDuration);

        if (clientCacheDuration.HasValue && context.Response.StatusCode == 200)
        {
            if (clientCacheDuration == TimeSpan.Zero)
            {
                context.Response.GetTypedHeaders().CacheControl = new CacheControlHeaderValue
                {
                    NoCache = true,
                    NoStore = true,
                    MustRevalidate = true
                };
                context.Response.Headers["Expires"] = "0";
            }
            else
            {
                context.Response.GetTypedHeaders().CacheControl = new CacheControlHeaderValue
                {
                    Public = true,
                    MaxAge = clientCacheDuration
                };
            }
        }

        return Task.CompletedTask;
    });            
}

Keep in mind that our action filter determines the ClientDuration value. There are three possibilities:

• Unset – do not send headers
• Zero – set various headers instructing downstream clients not to cache the response
• Other – set the cache headers to the provided value

The cache

We haven’t yet talked about the actual cache, which is one thing. The _cache references in the code above really correspond to a wrapper class that contains the IMemoryCache implementation that is built-in.

public class CacheClient : ICacheClient
{
    private readonly IMemoryCache _cache;
    
    public CacheClient(IMemoryCache cache)
    {
        _cache = cache ?? throw new ArgumentNullException(nameof(cache));
    }

    internal bool TryGet<T>(string key, out T entry)
    {
        return _cache.TryGetValue(Constants.CacheKeyPrefix + key, out entry);
    }

    internal void Set(string key, object entry, TimeSpan expiry, params string[] tags)
    {
        var options = new MemoryCacheEntryOptions
        {
            AbsoluteExpirationRelativeToNow = expiry
        };

        var allTokenSource = _cache.GetOrCreate(Constants.CacheTagPrefix + Constants.AllTag, 
            allTagEntry => new CancellationTokenSource());

        options.AddExpirationToken(new CancellationChangeToken(allTokenSource.Token));

        foreach (var tag in tags)
        {
            var tokenSource = _cache.GetOrCreate(Constants.CacheTagPrefix + tag, tagEntry =>
            {
                tagEntry.AddExpirationToken(new CancellationChangeToken(allTokenSource.Token));

                return new CancellationTokenSource();
            });

            options.AddExpirationToken(new CancellationChangeToken(tokenSource.Token));
        }

        _cache.Set(Constants.CacheKeyPrefix + key, entry, options);
    }

Expiration tokens are used by the Set function to enable bulk removal of cache entries.

The concept is that we store a CancellationTokenSource for every entry in the cache and additional CancellationTokenSources for each tag we define. If you have never used CancellationTokenSource before, this may be a little difficult to understand. When setting the cache entry, we produce a token by using these CancellationTokenSources. In the following part, we’ll look at using the CancellationTokenSources to invalidate cache items in bulk.

Cache invalidation AKA cache busting

This unique kind of response caching was implemented primarily to meet the need for the ability to delete cache items before they naturally expire. The following methods are exposed by our CacheClient class for this:

public void Remove(string key)
{
    _cache.Remove(Constants.CacheKeyPrefix + key);
}

public void RemoveByTag(string tag)
{
    if (_cache.TryGetValue(Constants.CacheTagPrefix + tag, out CancellationTokenSource tokenSource))
    {
        tokenSource.Cancel();

        _cache.Remove(Constants.CacheTagPrefix + tag);
    }            
}

public void RemoveAll()
{
    RemoveByTag(Constants.AllTag);
}

As you can see, deleting a single cache entry just requires that you know the key. You could want to allow action, controller, and route values to be given instead to make it more user-friendly.

The RemoveAll and RemoveByTag methods invoke the Cancel() function, which expires all tokens issued by the source, after retrieving the CancellationTokenSource from the cache. These cache entries are eliminated as a result.

Limitations

This is a very simple illustration of response caching and is devoid of many features found in native response caching middleware. The lack of the option to alter caching depending on headers, cookies, etc. is perhaps the most noticeable missing. It would not be extremely challenging to incorporate VaryBy. In reality, all we’re altering is how the cache key is generated and adding support for CacheAttribute setting.

Additionally, we are using IMemoryCache rather than IDistributedCache, which is more scalable. As was already said, modifying the usage is simple but will reduce functionality. Since IDistributedCache does not allow expiration tokens, the method described here cannot be used to remove pages in bulk. Naturally, nothing prevents you from coming up with a different approach, but unsophisticated implementations will almost surely have a negative impact on performance.

Summary

The creation of simple response caching middleware that enables manual invalidation of items both individually and in bulk using tags was covered in this post. To store pages (or other action results like JSON) in an in-memory cache, we combined an action filter with a middleware component. Then, we made a number of methods available on our CacheClient class to enable the deletion of cache entries.

The example code should not be used in place of the built-in response caching, which offers far more capability, although it might be helpful in some circumstances.

IIS, on the other hand, is a web server that utilizes the Windows OS and the ASP.NET framework. IIS’s function in this situation is to host ASP.NET Core-built apps.

In this article, we’ll look at how to integrate ASP.NET Core with IIS. Let’s examine the procedures for deploying ASP.NET Core to IIS without further ado.

How to Setup an ASP.NET Core Application for IIS

When starting a new ASP.NET Core project, you will immediately discover that it is a console application. The following code is also present in your project’s Program.cs file, which is similar to a console application:

public class Program
{
    public static void Main(string[] args)
    {
        var host = new WebHostBuilder()
            .UseKestrel()
            .UseContentRoot(Directory.GetCurrentDirectory())
            .UseIISIntegration()
            .UseStartup()
            .Build();

        host.Run();
    }
}

What is the WebHostBuilder?

A WebHost object—essentially the application and web server—is necessary for all ASP.NET Core applications. To configure and create the WebHost in this instance, a WebHostBuilder is utilized. Usually, the setup code for WebHostBuilder contains the statements UseKestrel() and UseIISIntegration().

Why do these?

• UseKestrel() – Registers Kestrel as the server that will host your application by registering the IServer interface. Other solutions, such as the Windows-only WebListener, may become available in the future.
• UseIISIntegration() – Provides information to ASP.NET about how IIS will act as a reverse proxy in front of Kestrel, including the port it should listen on, forward headers, and other parameters.

If you are planning to deploy your application to IIS, UseIISIntegration() is required

What is AspNetCoreModule?

You may have noticed that ASP.NET Core projects create a web.config file. This is only used when deploying your application to IIS and registers the AspNetCoreModule as an HTTP handler.

Default web.config for ASP.NET Core:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <system.webServer>
        <handlers>
            <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified"/>
        </handlers>
        <aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="false"/>
     </system.webServer>
</configuration>

All incoming traffic to IIS is handled by AspNetCoreModule, which then serves as a reverse proxy that knows how to send traffic to your ASP.NET Core application. Its source code is accessible on GitHub. Additionally, AspNetCoreModule is in charge of launching your process and making sure that your web application is up and running.

Install .NET Core Windows Server Hosting Bundle

Installing the.NET Core hosting bundle for IIS, which includes the ASP.NET Core module for IIS and the.NET Core runtime, is necessary before you publish your application.

To make sure all the modifications are taken up by IIS after installation, you might need to do a “net stop was /y” and “net start w3svc” command.

Download: Windows Server Hosting for.NET Core – Select “Windows Server Hosting” without a doubt.

4 Steps to Deploy ASP.NET Core to IIS

Before you deploy, you need to make sure that WebHostBuilder is configured properly for Kestrel and IIS. Your web.config file should also exist and look similar to our example above.

1. Publish to a File Folder

2. Copy Files to Preferred IIS Location

Copy your publish output now to the location where you want the files to reside. You might want to zip up the files and transfer them to the server if you are deploying to a distant host. You can replicate them locally if you are deploying to a local development box.

I’m moving the files to C:\inetpub\wwwroot\AspNetCore46 for our example.

There is no bin folder with ASP.NET Core, and it might copy over a huge number of various.NET DLLs, as you will notice. If you are aiming for the entire.NET Framework, your application might also be an EXE file. Over 100 DLLs were produced by this tiny sample project.

3. Create Application in IIS

Creating your application in IIS is listed as a single “Step,” but you will actually do several different tasks. First, build a new IIS Application Pool with “No Managed Code” for the.NET CLR. IIS isn’t actually running any.NET code; it just functions as a reverse proxy.

The second option is to create your application under an already-existing or brand-new IIS Site. In any case, you must select your new IIS Application Pool and direct it to the location where you copied the ASP.NET publish output files.

4. Load Your Application

At this point, your application should load just fine. If it does not, check the output logging from it. Within your web.config file you define how IIS starts up your ASP.NET Core process. Enable output logging by setting stdoutLogEnabled=true. You may also want to change the log output location as configured in stdoutLogFile. Check out the example web.config before to see where they are set.

Where Can I Find Reliable and Cheap ASP.NET Core Hosting?

The following is my recommendation for ASP.NET Core web hosting:

1. ASPHostPortal: this is my first recommendation to host ASP.NET core website. It is a very reliable platform with a fast server and great customer support. It is a reliable ASP.NET Core hosting service for websites that do not require any special functionality or features.

2. HostForLIFE.eu: HostForLIFE is one of the best ASP.NET core web hosting in Europe. They support all ASP.NET version, start from Classic ASP, ASP.NET 1/2.0/3.5/4.0/4.5 and latest ASP.NET Core version. It is easy to deploy ASP.NET core website to their server.

3. UKWindowsHostASP.NET: One of the most reputable and affordable ASP.Net Core hosting companies in the world is UKWindowsHostASP.NET. It provides cloud hosting, VPS hosting, dedicated servers, and a wide range of adaptable alternatives for your company needs.

4. WindowsASPNETHosting.in: The finest host for developers and new businesses is WindowsASPNETHosting.in. For your web application or other project, WindowsASPNETHosting.in provides an ASP.NET, ASP,.Net Core, and SQL platform that you can easily extend with additional functionality.

5. DiscountService.biz: DiscountService committed to provide best, cheap, and reliable ASP.NET Core hosting services. They can offer you the quickest and safest platform to host your ASP.NET websites.

Conclusion

I hope above article can help you to publish your ASP.NET Core website easily to IIS. Instead of that, I also give some recommendation for ASP.NET core hosting in case you want to publish your ASP.NET core website online. Hope this helps and stay tune with other interesting tutorial and tips. Thank you for reading.

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();

You may not be aware, though, that ASP.NET user authentication may be added to console applications.

Thankfully, the hidden magic is mostly gone with.NET Core. All the components needed for authentication are available to you, and you are free to reuse them as necessary.

Making two projects—a console application and a web application—is the simplest method to do this. Make sure ASP.NET authentication is turned on in the web application before you begin.

All that is left to do is transfer some settings from the web application to our console application.

We must first include a few NuGet packages in our console application. References will be required for:

• Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore
• Microsoft.AspNetCore.Identity.EntityFrameworkCore
• Microsoft.AspNetCore.Identity.UI

You must first construct your NuGet packages before creating the ApplicationUser class and the Entity Framework database context.

public class ApplicationDbContext : IdentityDbContext<ApplicationUser>
{
    public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options)
        : base(options)
    {

    }

    public DbSet<ApplicationUser> ApplicationUsers { get; set; } 
}

public class ApplicationUser: IdentityUser
{

}

After getting your Entity Framework stuff set up, all that is really left to configure is your .NET Core DI.

public class Configurator
{
    public static void ConfigureServices(IServiceCollection services, IConfiguration configuration)
    {
        services.AddDbContext<ApplicationDbContext>(options =>
            options.UseSqlite(
                configuration.GetConnectionString("DefaultConnection")));

        services.AddIdentity<ApplicationUser, IdentityRole>()
            .AddEntityFrameworkStores<ApplicationDbContext>()
            .AddDefaultTokenProviders();

        services.AddLogging();

        services.AddScoped(
            typeof(IAuthentication),
            typeof(Authentication));
    }
}

Now that everything has been set up, we can use our console application to access ASP.NET Identity data just as we would in a web application. A example authentication service with numerous typical user-related features is shown below.

public class Authentication : IAuthentication
    {
        readonly UserManager<ApplicationUser> _userManager;

        public Authentication(UserManager<ApplicationUser> userManager)
        {
            _userManager = userManager;
        }
        
        public async Task<User> CreateUser(string email, string password)
        {
            var applicationUser = new ApplicationUser()
            {
                Email = email,
                UserName = email,
            };

            
            var result = await _userManager.CreateAsync(applicationUser, password);
            if (!result.Succeeded)
            {
                return null;
            }
            
            var loaded = await _userManager.FindByNameAsync(email);
            return DTOMapper.Map<User>(loaded);
        }
        
        public async Task<User> UpdatePassword(string email, string oldPassword, string newPassword)
        {
            var loaded1 = await _userManager.FindByNameAsync(email);
            if (loaded1 == null)
            {
                return null;
            }
            
            var result = await _userManager.ChangePasswordAsync(loaded1, oldPassword, newPassword);
            if (!result.Succeeded)
            {
                return null;
            }
            
            var loaded2 = await _userManager.FindByNameAsync(email);
            return DTOMapper.Map<User>(loaded2);
        }
        
        public async Task<bool> CheckPassword(string email, string password)
        {
            var loaded1 = await _userManager.FindByNameAsync(email);
            if (loaded1 == null)
            {
                return false;
            }
            
            return await _userManager.CheckPasswordAsync(loaded1, password);
        }
    }

Perhaps the main reasons could be that you need to initialize some code at the global asax at application start up. To fire up some global application logic. To warm up some pages. Or have an in memory timer in the ASP.NET application memory that routinely runs a schedule. What have you.

And you need to keep the website alive and always running, preventing the application or website from shutting down, or to turn cold because of idling or application pool recycling.

IIS keep website alive – Solution:

Since the availability of IIS Application Initialization feature, keeping ASP.NET website and app pool always running is not a complicated task.

You need these IIS prerequisites to keep your ASP.NET website always running:

1. Application Initialization Feature
2. Website or Application Preload Enabled
3. Application Pool Start Mode: AlwaysRunning

So here goes…

Application Initialization Feature

Having this feature installed, gives you the ability to make IIS automatically probe your website or web application (like a visitor hitting your page) to keep it active and warm. It can also let you serve a static page (splash page) when your website is starting up.

The Application Initialization Feature can be installed as part of IIS features.

Website or Application Preload Enabled

With Preload Enabled option set to true, IIS will simulate a request to ping your website or application as soon as a worker process (w3wp.exe) for your website or application is started. This will warm up your website or application. This dummy request hit will however not be logged in the IIS Log.

Application Pool Start Mode: AlwaysRunning

Making Start Mode option AlwaysRunning will make IIS spawn a new worker process (w3wp.exe) for your website or application whenever IIS is started. Or when your application pool idle time-out and shut down occurs. Or when your application pool is recycled.

With these main ingredients mentioned in place, your website is set to keep running and warm even without real visitors hitting.

Other considerations to keep your website or application run properly while always running

1. Application Pool Idle Time-out
2. Application Pool Recycling

While achieving a constantly warm and running website or application, it does not mean that there is nothing to worry. These two options, the Idle Time-out and Recycling may cause you problems if you do not understand how it works.

In consideration, you can set the Idle Time-out to 0 to disable time-out. This may sound like a logical idea to not end your application pool process since you want it always running. But if your website or application has memory leak issues, you will be in for a surprise when your memory max out due to this.

In consideration, you can disable all recycling options here. This may also sound like you have finally found a total solution to a completely uninterruptible website or application. But memory leak is also a beast here. If your website or application memory is not well programmed or managed.

Hence for memory leak control, it might actually be a good idea to use these features to regularly recycle the application pool to release memory resources. However again, your codes must properly anticipate and handle these recycling interruptions. To reinitialize upon start up or save state during shut down at recycling time.

With all these information, you should be able to maintain a properly managed always running website or application that suits your needs.

Happy coding!

Benefits for Freelance Web Developers

1. Great and High Intuitive UI

This is my favorite part about HostForLIFE.eu. I can create a variety of domains in my account for a variety of needs for my clients. I can separate users to access the dashboard, from low end client with minimal needs and high end client with more complex needs. It’s not complex, but it’s also not for a beginner who knows nothing about control panel unless he’s willing to put the time in to understand.

2. Manage Multiple App Installs In Control Panel

Each server you control can have a multiple different applications such as WordPress, Umbraco, Dotnetnuke, Custom PHP and nopCommerce. The benefit here is that each install is also isolated to itself for an added security layer, and you still have root access to all your applications.

3. Website Migration Tools for Easier Website Transfers

HostForLIFE.eu hosting makes it pretty easy to move a ASP.NET website from one hosting provider to another. The tool they provide for migration makes it awesome to move the large website files without having to slave away manually doing the work. You also don’t need to have the SFTP login credentials for the source site. This makes moving clients away from bad developers a little easier without the confrontation. 

4. Run High Quality Website Without The Complexity

One of the things I love about HostForLIFE.eu is that it allows me to manage my ASP.NET websites without the need to be a server expert. Pricing is predictable and affordable.

5. Simple Helpdesk System

I really am super in love with how simple they have made the UI of this website. They have super minimal menu items and support is always a floating tab in eyesight for easy access.

The new trend with bad hosting companies has been to make the trail to find support so complex that you want to give up even trying to create a ticket. It’s hard to contact support team. It actually feels like an insult because when I pay a company, I expect them to make it easy for me to contact if I need assistance. I’m paying for a service, therefore, I want to be served respectfully.

Notable Highlights of HostForLIFE.eu

1. Simplicity and Choice

One of the main highlights of HostForLIFE.eu that makes it among the best ASP.NET hosting options is that it offers users with the most simplicity as well as the most choices. With HostForLIFE.eu, businesses can get support for up to unlimited applications, get support for all ASP.NET and PHP apps and get an innovative cover panel.

2. Worry Free Experience

Using HostForLIFE.eu provides businesses with the best web hosting experience by offering one that is worry free. Users will get 24/7 support, managed security, automated backups and 24/7 monitoring in real time.

2. Scaled Performance

HostForLIFE.eu also offers performance that scales as well. With this option, businesses will be able to get optimized stacks and built in CDN. They will also have access to auto healing services and ASP.NET Core ready servers as well.

HostForLIFE.eu Also Have Managed Dedicated Server

This managed hosting option assists many businesses unleash the full potential of their websites at all times.

With HostForLIFE.eu, businesses will be able to get a website that will go live within minutes. This cloud hosting platform eliminates all of the complexities of establishing a website. As a result, you can get your website operating live within a matter of a few minutes. Other hosting options usually require a day or two to go live.

With HostForLIFE.eu, businesses can also get their sites managed in the most professional manner. When using this option, both web designers and businesses can built and manage a website and apps with more collaboration and efficiency.

By using HostForLIFE.eu, businesses and web designers can use an option that will provide the fastest performance along with guaranteed security and scalability for any website they built and host.

Don’t Worry with HostForLIFE.eu! You are in the RIGHT Hand!

Whenever you construct and run a website, there is a possibility of something going wrong. As a result, businesses and web designers will often need to resolve these problems immediately. While web designers can spend time resolving any problems with a site, HostForLIFE.eu helps eliminate this hassle.

Since HostForLIFE.eu offers support 24 hours a day 7 days a week and 365 days a year, both businesses and web developers will be able to get any problem solved quickly and easily. With features such as the Advanced Support option, users will be able to improve the level of support they get. As a result, businesses and web developers will be able to have the tools they need to maintain a quality website.

Best Hosting for ASP.NET

Another highlight of HostForLIFE.eu and a reason to use this as your hosting option is that it will allow you to guarantee success for any website that uses ASP.NET. Many businesses and web developers often use ASP.NET in order to make and run websites. With HostForLIFE.eu, you can get the most trusted hosting for your ASP.NET and also PHP website.

If you’re not enough with their shared hosting, you can always upgrade to their VPS/dedicated hosting option. The managed hosting features include many things to help manage a website. These include advanced cashes with Breeze and CDN to provide your website with the fastest possible performance. All of these features create a more efficient web hosting experience for users.

Features of HostForLIFE.eu

HostForLIFE.eu offers both businesses and web developers a number of features that make it the preferred choice for a ASP.NET hosting platform. These features make HostForLIFE.eu stand out from other ASP.NET hosting platforms that are currently available.

1. 24/7/365 Support

Users get all of the help they need using the platform. They can access any assistance at any time throughout the day. With a team of highly trained experts, businesses and web deveopers will be sure to keep their websites working at their best.

2. 30 Minute or Less Response Time

HostForLIFE.eu offers Advanced Support which provides users with with a priority response time of 30 minutes or less.

3. Server Customization and Configuration

Users can have ASP.ET and other PHP custom packages deployed by using HostForLIFE.eu. The platform can also cache configurations and make changes with the configuration of any server as well.

4. Application Level Issues

Features such as theme troubleshooting, plug ins, and investigation of server errors can help businesses manage their databases and email add ons. These features help optimize the overall performance of a website.

High Speed Performance

HostForLIFE.eu ensures that businesses and web developers have ASP.NET websites that always come with high speed performance. Users will get a website with access to dedicated resources. This platform also offers SSD based hosting which is 3 times faster than other hosting platforms.

With other features such as built in caches, ASP.NET Core ready servers, CDN and Auto healing managed cloud servers, users will ensure that their website will always work at its best using the latest technology.

Managed Hosting and Security

When it comes to hosting a website and running it, security is one of the primary concerns of both businesses and web developers. With HostForLIFE.eu, you will never have to worry about any information being compromised. That is because HostForLIFE.eu uses the most updated managed security features that are currently available.

Some of the features you get with HostForLIFE.eu include dedicated firewalls, 1 click free SSL installation, IP whitelisting, security patching, two factor authentication, IaaS providers and block storage. These ensure that your website will be protected from any hackers or software that can ruin your website.

Comprehensive Management of Your Website

Another one of the best things about HostForLIFE.eu is that it provides users with the most possible flexibility. You will get the most comprehensive management of your server. By using HostForLIFE.eu, users will get features such as vertical scaling of technology resources, database support, multiple versions of ASP.NET, global availability and support for all apps associated with PHP.

Smooth Team Collaboration

With smooth workflow and team collaboration, users will be able to achieve all of their goals. Some of the features included are integration of Git, WebDeploy and FTP and cloning of applications and servers. Users will also get one account for multiple teams, management of projects, staging areas for URLs and the ability to add more team members at any time. HostForLIFE.eu also allows users to transfer servers and use a migratory plug in to migrate WordPress from an old hosting site and put it into a new one for free.

Full Control

As a web developers or a business owner, it is important to have autonomy on how you want your website to be run and managed. With HostForLIFE.eu, you can take advantage of an easy to use UI that enables you to control any application or server with ease.

You can take advantage of options such as 1 click backup and restore, a 1 click stop app, app settings using UI and a supervised Queue manager. Users can also change the application Webroot as well.

Great Integration

A user can use one account to integrate multiple programs and add on features. This platform offers HostForLIFE.eu Bot Channels, API and application migration add on features. HostForLIFE.eu also includes SMTP add ons, email add ons using Business Email and application upgrade add ons as well. The one account feature also includes HostForLIFE.eu support add ons that users can take advantage of too.

Stay Updated with Latest Technologies

HostForLIFE.eu always allows users to keep track of their technology and stay updated on it as the same time. This platform offers 24/7 real time monitoring to ensure that your site and server are working properly. It also offers new relic integration which allows users to get insight on app performance in order to troubleshoot and identify issues with your site.

Lastly, HostForLIFE.eu Bot Notifications provide users with AI based assistance that provide information to help you optimize your servers and applications.

Conclusion

If you want to give your full attention to business growth without getting into server-related hassles, then HostForLIFE.eu hosting is the ideal choice.

It is the best hosting for ASP.NETthat lets you get a stress-free hosting experience and tweak your site’s performance.

I would blindly recommend HostForLIFE.eu Hosting for ASP.NET users because of its flexibility, reliability, and support facility.

This post will show how to take one of the oldest tracing methods, System.Diagnostics.Trace, and adapt your newer .NET applications (.NET 5+) to take advantage of the messages some of your older dependencies may be emitting.

What Is System.Diagnostics.Trace?

In the early days of systems development, you typically had very simple architectures with few running processes. Traces allow for publishing specific messages during the execution of your application that you can scan over later to glean information about a running process at a particular time. Developers will put their messages into four general categories:

• Critical: Serious failure that likely causes immediate loss of information or user functionality.
• Error:: An unexpected failure in a particular sub-system that may result in a loss of user functionality, but it is otherwise recoverable.
• Warning: An unexpected situation, but standard processing can continue.
• Information: Messages that may be helpful when diagnosing a system, but otherwise are there for developers to learn more at their convenience.

You can find traces in many .NET Dependencies, but messages are usually are not surfaced until you register a Listener. A listener redirects messages to a destination, whether a log file, the event log in Windows, the console output, or a third-party repository.

If you’re reading this post, you’re likely wondering: “How do I get my traces to show up through my ILogger configuration?” As your ILogger setup likely also has the configuration for logging targets like files, event logs, and third-party services. Nobody likes doing things twice, especially developers like you.

Well, let’s see how.

Passing Trace Messages To ILogger

Our goal is to pass Trace messages directly to an ILogger implementation, piggy-backing off our application’s configuration. Most importantly, the approach would allow us to see into older dependencies that may still be utilizing System.Diagnostics.Trace calls.

Our first step in the process is to write a Listener, which we’ll call LoggerTraceListener.

public class LoggerTraceListener : TraceListener
{
    private readonly ILoggerFactory _loggerFactory;
    private readonly ILogger _defaultLogger;
    private readonly ConcurrentDictionary<string, ILogger> _loggers = new();
    private readonly StringBuilder _builder = new();

    public LoggerTraceListener(ILoggerFactory loggerFactory)
    {
        _loggerFactory = loggerFactory;
        _defaultLogger = loggerFactory.CreateLogger(nameof(LoggerTraceListener));
    }

    public override void TraceEvent(TraceEventCache? eventCache, string source, TraceEventType eventType, int id, string? message)
    {
        var logger = _loggers.GetOrAdd(
            source,
            static (s, factory) => factory.CreateLogger(s),
            _loggerFactory);
        
        logger.Log(MapLevel(eventType), message);
    }

    public override void TraceEvent(TraceEventCache? eventCache, string source, TraceEventType eventType, int id, string? format,
        params object?[]? args)
    {
        var logger = _loggers.GetOrAdd(
            source,
            static (s, factory) => factory.CreateLogger(s),
            _loggerFactory);
        
        logger.Log(MapLevel(eventType), format, args ?? Array.Empty<object>());
    }

    public override void Write(string? message)
    {
        _builder.Append(message);
    }

    public override void WriteLine(string? message)
    {
        _builder.AppendLine(message);
        _defaultLogger.LogInformation(_builder.ToString());
        _builder.Clear();
    }

    private LogLevel MapLevel(TraceEventType eventType) => eventType switch
    {
        TraceEventType.Verbose => LogLevel.Debug,
        TraceEventType.Information => LogLevel.Information,
        TraceEventType.Critical => LogLevel.Critical,
        TraceEventType.Error => LogLevel.Error,
        TraceEventType.Warning => LogLevel.Warning,
        _ => LogLevel.Trace
    };
}

Note that the LoggerTraceListener takes a dependency on an ILoggerFactory, which will help us preserve the source of our messages when we log with our ILogger implementation.

Now, let’s make use of our newly created listener. Next, assuming you’re working in an ASP.NET Core application, we need to register our listener with the System.Diagnostics.Trace.Listeners collection.

using System.Diagnostics;

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

// get logger factory and add listener
var factory = app.Services.GetRequiredService<ILoggerFactory>();
Trace.Listeners.Add(new LoggerTraceListener(factory));

Great! Now we can start getting traces in the output of our running application, assuming we have the console logger enabled. Finally, Let’s add some trace calls to an endpoint to see it all in action.

app.MapGet("/", async () =>
{
    Trace.TraceInformation("Cool Beans!");
    Trace.TraceWarning("Fudge!");
    Trace.TraceError("F#$@!");
    
    return "Hello World!";
});

Let’s take a look at the run output.

Neat! Now we can see our traces alongside all of our logging calls. But wait, there’s more! Since we are using the ILogger interface, we can also use the configuration options to limit what trace output gets passed to our logger. For example, in the appSettings.json, we can choose the level of information we want to log.

Note: Lumberjack is the assembly from which we emit our traces.

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning",
      "Lumberjack" : "Warning"
    }
  },
  "AllowedHosts": "*"
}

Let’s make sure it work.

Great!

Conclusion

As modern software development improves its techniques around tracing and observability, there will be a significant legacy codebase still heavily using System.Diagnostics.Trace. This post shows a method in which we can continue building modern applications with the latest and greatest tech while still taking advantage of the messages emitted by previous developers. I hope you found this post helpful, and thanks again for reading.

Do you ask the user for credentials again? That’s not really a good option.

This blog post is about using refresh tokens to solve this problem. Specifically in ASP.NET Core Web Apis with JWT tokens.

First, is this really a big deal? Why don’t we just set a long expiration date in the access tokens? For example, a month or even a year?

Because if we do that and someone manages to get hold of that token they can use it for a month, or a year. Even if you change your password.

That’s because a server will trust a token if it’s signature is valid, and the only way to invalidate it is to change the key that was used to sign it, and that has the consequence of invalidating everyone else’s tokens.

Not really an option then. That leads us to the idea of using refresh tokens.

How does a refresh token work then?

Imagine that when you get an access token you also get another one-time-use token: the refresh token. The app stores the refresh token and leaves it alone.

Every time your app sends a request to the server it sends the access token in it (Authorization: Bearer TokenGoesHere) so that the server knows who you are. There will come a time where the token will expire and the server will let you know of this somehow.

When this happens your app sends the expired token and the refresh token and gets back a new token and refresh token. Rinse, repeat.

If something fishy happens the refresh token can be revoked which means that when the app tries to use it to get a new access token, that request will be rejected and the user will have to enter credentials to be able to log in again.

To make this last point clear, imagine that the app stores the location (e.g. Dublin, Ireland) of the request when a refresh token is created. If user can access this information, and if there’s some login from a place that the user doesn’t recognize, the user can revoke the refresh token so that when the access token expires whoever is using it won’t be able to continue to use the app. This is why it’s probably a good idea to have the access tokens be short lived (i.e be valid for a couple of minutes).

To use refresh tokens we need to be able to do:

• Create access tokens (we will use JWT here)
• Generate, save, retrieve and revoke refresh tokens (server-side)
• Exchange an expired JWT token and refresh token for a new JWT token and refresh token (i.e. refresh a JWT token)
• Use ASP.NET authentication middleware to authenticate a user with JWT tokens
• Have a way to signal that the access token expired to the app (optional)
• When the token expires have the client transparently acquire a new token

If you need information on these topics individually, continue on.

Create JWT Access Tokens

First you need to add the System.IdentityModel.Tokens.Jwt package:

$ dotnet add package System.IdentityModel.Tokens.Jwt

To create a new JWT token:

private string GenerateToken(IEnumerable<Claim> claims)
{
    var key = new SymmetricSecurityKey(Encoding.UTF8.GetBytes("the server key used to sign the JWT token is here, use more than 16 chars"));

    var jwt = new JwtSecurityToken(issuer: "Blinkingcaret",
        audience: "Everyone",
        claims: claims, //the user's claims, for example new Claim[] { new Claim(ClaimTypes.Name, "The username"), //... 
        notBefore: DateTime.UtcNow,
        expires: DateTime.UtcNow.AddMinutes(5),
        signingCredentials: new SigningCredentials(key, SecurityAlgorithms.HmacSha256)
    );    

    return new JwtSecurityTokenHandler().WriteToken(jwt); //the method is called WriteToken but returns a string
}

Here we are creating a new jwt token with an expiration date of 5 minutes signed using HmacSha256.

Generate, save, retrieve and revoke refresh tokens

The refresh tokens must be unique and it shouldn’t be possible (or it must be very hard) to guess them.

It might seem that a simple GUID satisfies this criteria. Unfortunately the process of generating GUIDs is not random. That means that given a few guids you can easily guess the next one.

Thankfully, there’s a secure random number generator in ASP.NET Core that we can use to generate a string that is unique and even given a few of them it’s very hard to predict how the next one will be:

using System.Security.Cryptography;

//...

public string GenerateRefreshToken()
{
    var randomNumber = new byte[32];
    using (var rng = RandomNumberGenerator.Create()){
        rng.GetBytes(randomNumber);
        return Convert.ToBase64String(randomNumber);
    }
}

Here we are generating a 32 byte long random number and converting it to base64 so that we can use it as a string. There are no guidelines regarding the length other than it should lead to an unique and hard to guess token. I picked 32 but even 16 should be ok.

We will need to generate refresh tokens when we first generate a JWT token and when we “refresh” an expired token.

Every time we generate a new refresh token we should save in a way that it’s linked to the user for which the access token was issued.

The simplest version of this is just to have an extra column for the refresh token in the user’s table. This has the consequence of only allowing the user to be logged-in in one location (there’s only 1 refresh token valid per user at a time).

Alternatively, you can maintain several refresh tokens per user and save the geographical location, time, etc from the request that originated them so that you can provide the user with activity reports.

Also, it is probably a good idea to make the refresh tokens expire, for example after a few days (you’d have to save an expiration date together with the refresh token).

One thing you must not forget to do is to remove a refresh token when it is used in a refresh operation so that it cannot be used more than once.

Exchange an expired JWT and refresh token for a new JWT token and refresh token (i.e. refresh a JWT token)

To get a new access token from an expired one we need to be able to access the claims inside the token even though the token is expired.

When you use the ASP.NET Core authentication middleware for authenticating the user using JWT it will return a 401 response to an expired token.

We need to create a controller action that allows anonymous users and that takes the JWT and refresh tokens.

In that controller action we need to manually validate the expired access token (there’s an option to ignore the token lifetime) and extract all the information about the user contained in it.

We can then use the user information to retrieve the stored refresh token. We can then compare the stored refresh token with the one that was sent in the request.

If all is good we create new JWT and refresh tokens, save the new refresh token, discard the old and send the new JWT and refresh tokens to the client.

Here’s how you can retrieve the user information in the form of a ClaimsPrincipal from the expired JWT token:

private ClaimsPrincipal GetPrincipalFromExpiredToken(string token)
{
    var tokenValidationParameters = new TokenValidationParameters
    {
        ValidateAudience = false, //you might want to validate the audience and issuer depending on your use case
        ValidateIssuer = false,
        ValidateIssuerSigningKey = true,
        IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes("the server key used to sign the JWT token is here, use more than 16 chars")),
        ValidateLifetime = false //here we are saying that we don't care about the token's expiration date
    };

    var tokenHandler = new JwtSecurityTokenHandler();
    SecurityToken securityToken;
    var principal = tokenHandler.ValidateToken(token, tokenValidationParameters, out securityToken);
    var jwtSecurityToken = securityToken as JwtSecurityToken;
    if (jwtSecurityToken == null || !jwtSecurityToken.Header.Alg.Equals(SecurityAlgorithms.HmacSha256, StringComparison.InvariantCultureIgnoreCase))
        throw new SecurityTokenException("Invalid token");

    return principal;
}

The noteworthy parts in the above snippet are that we are using ValidateLifeTime = false in the TokenValidationParameters so that the expired token is considered valid. Also, we are checking that the algorithm used to sign the token is the one we expect (HmacSha256 in this example).

The reason for this is that in theory someone could create a JWT token and set the signing algorithm to “none”. The JWT token would be valid (even if unsigned). This way using a valid refresh token it would be possible to exchange a fake token for a real JWT token.

Now we just need the controller action (it should be a POST since it has side effects and also the tokens are too long for query string parameters):

[HttpPost]
public IActionResult Refresh(string token, string refreshToken)
{                   
    var principal = GetPrincipalFromExpiredToken(token);
    var username = principal.Identity.Name;
    var savedRefreshToken = GetRefreshToken(username); //retrieve the refresh token from a data store
    if (savedRefreshToken != refreshToken)
        throw new SecurityTokenException("Invalid refresh token");

    var newJwtToken = GenerateToken(principal.Claims);
    var newRefreshToken = GenerateRefreshToken();
    DeleteRefreshToken(username, refreshToken);
    SaveRefreshToken(username, newRefreshToken);

    return new ObjectResult(new {
        token = newJwtToken,
        refreshToken = newRefreshToken
    });
}

There are a few assumptions in the snippet above. There’s the retrieving, saving and deleting that I’ve omitted, and also there’s the assumption that there’s only one refresh token per user which is the simplest scenario.

Use the ASP.NET Core authentication middleware to authenticate a user using a JWT token

We need to configure ASP.NET Core’s middleware pipeline so that if a request comes in with a valid Authorization: Bearer JWT_TOKEN header the user is “signed in”.

After version 2.0 of ASP.NET Core we add a single authentication middleware to the pipeline and we configure it in Startup.cs‘ ConfigureServices:

public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc();
    //...

    services.AddAuthentication(options =>
    {
        options.DefaultAuthenticateScheme = "bearer";
        options.DefaultChallengeScheme = "bearer";
    }).AddJwtBearer("bearer", options =>
    {
        options.TokenValidationParameters = new TokenValidationParameters
        {
            ValidateAudience = false,
            ValidateIssuer = false,
            ValidateIssuerSigningKey = true,
            IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes("the server key used to sign the JWT token is here, use more than 16 chars")),
            ValidateLifetime = true,
            ClockSkew = TimeSpan.Zero //the default for this setting is 5 minutes
        };
        options.Events = new JwtBearerEvents
        {
            OnAuthenticationFailed = context =>
            {
                if (context.Exception.GetType() == typeof(SecurityTokenExpiredException))
                {
                    context.Response.Headers.Add("Token-Expired", "true");
                }
                return Task.CompletedTask;
            }
        };
    });
}

Of note in the snippet above is the handling of the OnAuthenticationFailed event. It will add a Token-Expired header to the response when a request comes in with an expired token. The client can use this information to decide to use the refresh token. However, we can just have the client try to use the refresh token when it gets a 401 response. We’ll rely on the Token-Expired header being in the response for the rest of this blog post.

Now we just need to add the Authentication middleware to the pipeline:

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }

    app.UseAuthentication();
    //...

The client

The goal here is to build an api client that can realize when a token has expired and take the appropriate actions to get a new token, and do all of this transparently.

When a request fails because of an expired access token, a new request should be sent to a refresh endpoint with the access and refresh tokens. After that request completes and the client gets the new tokens, the original request should be repeated.

The implementation for this will depend on which type of client you are using. Here we will describe a possible JavaScript client. We’ll be relying on the response to a request with an expired token having a header named "Token-Expired". We’ll be using fetch to perform requests to the web api.

async function fetchWithCredentials(url, options) {
    var jwtToken = getJwtToken();
    options = options || {};
    options.headers = options.headers || {};
    options.headers['Authorization'] = 'Bearer ' + jwtToken;
    var response = await fetch(url, options);
    if (response.ok) { //all is good, return the response
        return response;
    }

    if (response.status === 401 && response.headers.has('Token-Expired')) {
        var refreshToken = getRefreshToken();

        var refreshResponse = await refresh(jwtToken, refreshToken);
        if (!refreshResponse.ok) {
            return response; //failed to refresh so return original 401 response
        }
        var jsonRefreshResponse = await refreshResponse.json(); //read the json with the new tokens

        saveJwtToken(jsonRefreshResponse.token);
        saveRefreshToken(jsonRefreshResponse.refreshToken);
        return await fetchWithCredentials(url, options); //repeat the original request
    } else { //status is not 401 and/or there's no Token-Expired header
        return response; //return the original 401 response
    }
}

In the snippet above there’s getJwtToken, getRefreshToken, saveJwtToken and saveRefreshToken. In a browser these would use the browser’s localStorage to save and retrieve the tokens, for example:

function getJwtToken() {
    return localStorage.getItem('token');
}

function getRefreshToken() {
    return localStorage.getItem('refreshToken');
}

function saveJwtToken(token) {
    localStorage.setItem('token', token);
}

function saveRefreshToken(refreshToken) {
    localStorage.setItem('refreshToken', refreshToken);
}

There also the refresh function. This function performs a POST request to the api endpoint for refreshing tokens, for example if that endpoint is at /token/refresh:

async function refresh(jwtToken, refreshToken) {
    return fetch('token/refresh', {
        method: 'POST',
        body: `token=${encodeURIComponent(jwtToken)}&refreshToken=${encodeURIComponent(getRefreshToken())}`,
        headers: {
            'Content-Type': 'application/x-www-form-urlencoded'
        }
    });
}

This is how using this client would look like if you were trying it out in the chrome developer tools console:

One thing to note here is the 401 that shows up in red in the console. That happens when the request fails because of the expired token.

If seeing the “error” (error in quotes because it’s a valid status code and appropriate in this case) is something you’d like to avoid, you can access the token’s expiration date in JavaScript and refresh it before it expires.

A JWT token has 3 parts separated by a a “.”. The second part contains the user’s claims, and in there there’s a claim named exp which contains the unix time stamp of when the token expires. This is how you can get a JavaScript date object with the expiration date for a JWT token:

var claims = JSON.parse(atob(token.split('.')[1]));
var expirationDate = new Date(claims.exp*1000); //unix timestamp is in seconds, javascript in milliseconds

Checking the expiration date feels convoluted so I don’t recommend doing it (also dealing with timezones is probably a problem). I decided to mention this because it’s something that is interesting to know and that makes it very clear that what you put in a JWT token is not secret, it just can’t be tampered with without making the token invalid.

Middleware and Filters serves similar purpose and both can be used to achieve the common tasks like exception handling, localizations, authentications etc… but both has certain difference in a way it works with the pipeline.

Lets understand the difference and use of Middleware and Filters through an example of Exception Handling.

Middleware

It allows in the pipeline to handle requests and responses Where you can choose if the component “is to pass the request to the next component in the pipeline” or “can perform work before and after the next component in the pipeline”. i.e. Perform request validation, localization, exception handling or logging each request and response etc.

Filters

It run within the ASP.NET Core action invocation pipeline and allows to perform certain operation before or after specific stages in the request processing pipeline. i.e. Perform authentication or authorization to validate requested action processing.

Now lets understand it with the example of Exception Handling generically using both the way.

Scenario: Handle all unhandled exception in code to safeguard the crucial information about code to be delivered to the end user.

1. Using Middleware.

Here we try to handle all uncaught exception through out the application through a middleware we create. Middleware is a normal class so you don’t have to inherit any interface/specific class but your class must have the method called Invoke “public async Task Invoke(HttpContext context)”.

using Microsoft.AspNetCore.Http;
using System;
using System.Net;
using System.Threading.Tasks;
namespace CoreWebAPIDemo.Middleware
{
    public class ExceptionHandlingMiddleware
    {
        private readonly RequestDelegate _requestDelegate;
        public ExceptionHandlingMiddleware(RequestDelegate 
                                                requestDelegate)
        {
            _requestDelegate = requestDelegate;
        }
        public async Task Invoke(HttpContext context)
        {
            try
            {
                await _requestDelegate(context);
            }
            catch (Exception ex)
            {
                await HandleException(context, ex);
            }
        }
        private Task HandleException(HttpContext context, Exception ex)
        {
            context.Response.ContentType = "application/json";
            context.Response.StatusCode = 
                                (int)HttpStatusCode.InternalServerError;
            return context.Response.WriteAsync(ex.Message);
        }
    }
}

In above code here I have RequestDelegate dependency resolving code to handle the http request because my requirement to catch the unhandled exception in the pipeline . Now lets add an extension method for IApplicationBuilder to simplify the call for this middleware.

using Microsoft.AspNetCore.Builder;
namespace CoreWebAPIDemo.Middleware
{
    public static class ExceptionHandlerMiddlewareExtension
    {
        public static IApplicationBuilder UseExceptionHandlerMiddleware(
            this IApplicationBuilder builder)
        {
            return builder.UseMiddleware<ExceptionHandlingMiddleware>();
        }
    }
}

Our Middleware to catch the uncaught exception is ready and now we need to register it to request pipeline which will be from Startup.Configure method. Here we have to be very careful as the pipeline order is driven through the order of middleware services you add. In this we need to catch the exception while processing the request hence I’ll be adding this middleware at the end just before the UseEndpoints middleware call.

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    app.UseHttpsRedirection();      
    app.UseRouting();      
    app.UseStaticFiles();      
    app.UseCors("AllowAll");      
    app.UseExceptionHandlerMiddleware();      
    app.UseEndpoints(endpoints =>
            {
                endpoints.MapControllers();
            });
}

and finally to test the code, lets create a control which will throw the exception.

using Microsoft.AspNetCore.Mvc;
using System;
namespace CoreWebAPIDemo.Controllers
{
    [ApiController]
    [Route("api/[controller]")]
    public class HomeController : ControllerBase
    {
        [HttpGet]
        public IActionResult Index(int value)
        {
            if (value == 1)
                return Ok("I'm Happy");
            else
                throw new Exception("I didn't like your number");
        }
    }
}

output would be:

Now lets do the exception handling through action filter.

2. Using Filter.

Here we will create a action filter which inherits IActionFilter.

using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Mvc.Filters;
using System;
using System.Net;
namespace CoreWebAPIDemo.Middleware
{
    public class ExceptionHandlerFilter : Attribute, IActionFilter
    {
        public void OnActionExecuting(ActionExecutingContext context) 
        { }
        public void OnActionExecuted(ActionExecutedContext context)
        {
            if (context.Exception is Exception exception)
            {
                context.Result = new ObjectResult(exception.Message)
                {
                    StatusCode = (int)HttpStatusCode.InternalServerError,
                };
                context.ExceptionHandled = true;
            }
        }
    }
}

In this case, we are adding code to handle exception OnActionExecute method which will get executed after the action is executed.

Now we need to register it through Startup.ConfigureServices method if we want to apply it forcefully to all the controller’s action execution and here we can add this anywhere in the method without worrying about the order.

services.AddControllers(options => options.Filters.Add(new ExceptionHandlerFilter()));

Or we can also restrict it to a specific controller or action method and this is one big advantage over using Middleware concept to handle exceptions like in this scenario. Also when we reach here our MVC context is fully ready like model binding and all is done and available with the context.

And this is the reason, I have also inherited Attribute class while creating ExceptionHandlerFilter. Now here is the code to use it with the specific controller only.

using CoreWebAPIDemo.Middleware;
using Microsoft.AspNetCore.Mvc;
using System;namespace CoreWebAPIDemo.Controllers
{
    [ApiController]
    [Route("api/[controller]")]
    [ExceptionHandlerFilter]
    public class HomeController : ControllerBase
    {
        [HttpGet]
        public IActionResult Index(int value)
        {
            if (value == 1)
                return Ok("I'm Happy");
            else
                throw new Exception("I didn't like your number");
        }
    }
}

Note: Don’t forget to comment the earlier middleware code for registering “app.UseExceptionHandlerMiddleware();” in case if you are in same project like me while testing.

Other Point

ASP.NET core also provides predefined middleware for exception handing which you can use to control the information flowing to the use in case of uncaught exception or error and you can achieve that by doing this:

1. Create an ErrorController and two action method as below to handle development and production scenario.

using Microsoft.AspNetCore.Diagnostics;
using Microsoft.AspNetCore.Hosting;
using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using System;
namespace CoreWebAPIDemo.Controllers
{[ApiController]
    [Route("api/[controller]")]
    public class ErrorController : ControllerBase
    {
        /// <summary>
        /// The preceding Error action sends an RFC 7807-compliant payload 
            to the client.
        /// </summary>
        /// <returns></returns>
        [Route("/error")]
        public IActionResult Error() => Problem("Oops there is a problem. 
        Excuse me and smile!");
        [Route("/error-local-development")]
        public IActionResult ErrorLocalDevelopment(
        [FromServices] IWebHostEnvironment webHostEnvironment)
        {
            if (webHostEnvironment.EnvironmentName != "Development")
            {
                throw new InvalidOperationException("Ugggh! This is not 
                for Production, go away.");
            }
            var context = 
                 HttpContext.Features.Get<IExceptionHandlerFeature>();
            return Problem(
                detail: context.Error.StackTrace,
                title: context.Error.Message);
        }
    }
}

2. Enable ASP.NET Core predefined ExceptionHandler middleware from Startup.Configure method.

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
     if (env.IsDevelopment())
     {
          app.UseExceptionHandler("/error-local-development");
     }
     else
     {
          app.UseExceptionHandler("/error");
     }     
    app.UseHttpsRedirection();     
    app.UseRouting();     
    app.UseStaticFiles();     
    app.UseCors("AllowAll");     
    app.UseEndpoints(endpoints =>
            {
                endpoints.MapControllers();
            });
}

Middleware vs Filters

The first step is to consider why you would choose to use middleware over filters, or vice versa. Both are designed to handle cross-cutting concerns of your application and both are used in a ‘pipeline’, so in some cases you could choose either successfully.

The main difference between them is their scope. Filters are a part of MVC, so they are scoped entirely to the MVC middleware. Middleware only has access to the HttpContext and anything added by preceding middleware. In contrast, filters have access to the wider MVC context, so can access routing data and model binding information for example.

Generally speaking, if you have a cross cutting concern that is independent of MVC then using middleware makes sense, if your cross cutting concern relies on MVC concepts, or must run midway through the MVC pipeline, then filters make sense.

First, you have some middleware that already does what you want, but you now need the behaviour to occur midway through the MVC middleware. You could rewrite your middleware as a filter, but it would be nicer to just be able to plug it in as-is. This is especially true if you are using a piece of third-party middleware and you don’t have access to the source code.

Second, you have functionality that needs to logically run as both middleware and a filter. In that case you can just have the one implementation that is used in both places.