Access to XMLHttpRequest from origin has been blocked by CORS policy…

I did a Web API deployment in Azure Web API service. I was able to access the URL in browser and Postman. I started getting following error when I try to integrate in ASP.NET Web App in my local development environment;

Access to XMLHttpRequest at ‘https://xyz-dev.azurewebsites.net/api/Authentication/GetTestUser?name=testuser’ from origin ‘http://localhost:17686’ has been blocked by CORS policy: Response to preflight request doesn’t pass access control check: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.

jquery.js:9172          GET https://xyz-dev.azurewebsites.net/api/Authentication/GetTestUser?name=testuser net::ERR_FAILED

To solve the problem, I did this;

Here is server-side (Web API) code;

Add following to Web API ConfigureServices method;

public void ConfigureServices(IServiceCollection services)
{
    services.AddCors(op =>
    {
       op.AddPolicy("AllOrigin", builder => builder.AllowAnyOrigin().AllowAnyMethod().AllowAnyHeader());
    });
}

Add following to Web API Configure method;

public void Configure(IApplicationBuilder app, IWebHostEnvironment env, ILoggerFactory loggerFactory)
{
      //-------use cords
      app.UseCors("AllOrigin");
}

Here is client-side AJAX call.

<input type="button" id="btnWebApiCall" name=" btnWebApiCall" value="Test CORS" class=" btn btn-primary btn-lg justify-content-center" />

@section Scripts
    {

    <script>

        $(document).ready(function () {

            $("#btnAuthenticateSSO").click(function (e) {
                e.preventDefault();
                $.ajax({
                    type: "GET",
                    url: "https://xyzapi-dev.azurewebsites.net/api/Authentication/GetTestUser?name=testuser",
                    contentType: "application/json; charset=utf-8",
                    //crossDomain: true,
                    dataType: "json",
                    success: function (data, status, xhr) {
                        alert(JSON.stringify(data));
                        console.log(data);
                    }, //End of AJAX Success function
                    error: function (xhr, status, error) {
                        alert("Result: " + status + " " + error + " " + xhr.status + " " + xhr.statusText);
                    } //End of AJAX error function

                });
            });

        });

    </script>

}

The pain is gone.

If interested in learning more about this, read below;

Researched and figured out that browser sends two requests to the server. Tiny request and actual request.

The browser sends a tiny request called a preflight request before the actual request. It includes details such as the HTTP method used and whether any custom HTTP headers are present. The preflight allows the server to see how the actual request would appear before it is sent. The server will then tell the browser whether or not to submit the request, or whether to return an error to the client instead.

See below for problem header without CORS and with CORS in web API;

Headers without CORS implementation in Web API (Problem);

Headers with CORS implementation in Web API (Problem solved);

A simple Get request make these two requests;

Resources

https://medium.com/easyread/enabling-cors-in-asp-net-web-api-4be930f97a5c

https://stackoverflow.com/questions/31942037/how-to-enable-cors-in-asp-net-core

How .NET and SQL Server Handle Dates and Times

.NET and SQL Server have always come up short when it comes to handling date and time data. To be fair, most other languages and databases do as well. Although there have always been ways to cover the inadequacies, the work-arounds have always felt clumsy to me. We deal with them so often in our daily lives to the point that they seem rather simple and intuitive to us, yet dates and times are complicated concepts. Initially, both .NET and SQL Server set out to handle some of the most complicated aspects for us, each with its own DateTime data type.

Read more Here.

https://codemag.com/Article/2203041/.NET-6-Date-and-Time?utm_source=Knowbility3.9.2022&utm_medium=newsletter&utm_campaign=sm-articles

ASP.NET Core Middleware Configuration settings access

How do we access the configuration settings in the Middleware component in ASP.NET Core applications?

As we know middleware is a component that is used in the application pipeline to handle requests and responses which can help perform pre and post-operation within the request and response API pipeline.

We will be using two approaches, one with simple configuration and second with IOptions pattern. You can read more about it here;

https://docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration/options?view=aspnetcore-6.0

Create ASP.NET Core API application based on .NET Core 3.1. We will be using this configuration;

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information"
    }
  },
  "GlobalConfigurationSettings": {
    "LowerEnvironment": "true",
    "CustomerConfig": {
      "CustomerKeyurl": "http://customer/key",
      "CustomerdetailsUrl": "http://customer/id",
      "Agency": {
        "AgencyID": "subvalue1_from_json",
        "AccountKey": 200
      }
    },
    "AllowedHosts": "*"
  }
}

This is a generic custom middleware;

public class CustomMiddleware
{
   private readonly RequestDelegate _next;

   public CustomMiddleware(RequestDelegate next)
   {
       _next = next;
   }
 
   public async Task InvokeAsync(HttpContext httpContext)
   {
       try
       {
           await _next(httpContext);
       }
       catch (Exception ex)
       {
           throw ex;
           //_logger.LogError($"Something went wrong: {ex.Message}");
       }
   }
}

Approach 1- Using IConfiguration to load the Config settings in Middleware

This approach does not require any custom interface. When CreateDefaultBuilder runs, it load application configuration by default from appsettings.json. This is available to any component in the application.

We are going to inject RequestDelegete and IConfiguration from the constructor in middleware;

public class MiddlewareWithIConfiguration
    {
        private readonly RequestDelegate _next;
        private readonly IConfiguration _configurationSettings;

        public MiddlewareWithIConfiguration(RequestDelegate next, IConfiguration optionsSettings)
        {
            _next = next;
            _configurationSettings = optionsSettings;
        }

Implement InvokeAsync (assuming we need asynchronous middleware behavior) method.

public async Task InvokeAsync(HttpContext httpContext)
        {
            try
            {
                var customerKeyUrl = _configurationSettings["GlobalConfigurationSettings:CustomerConfig:CustomerKeyurl"];
                Console.WriteLine($"Middleware using IConfiguration {customerKeyUrl}");
                await _next(httpContext);
            }
            catch (Exception ex)
            {
                throw ex;
                //_logger.LogError($"Something went wrong: {ex.Message}");
            }
        }

Add this line to Startup.cs file;

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{

            app.UseMiddleware<MiddlewareWithIConfiguration>();
}

Approach 2 – Using IOption to load the Config settings in Middleware

We need to add and configure IOptions in Startup.cs file;

public void ConfigureServices(IServiceCollection services)
        {
            //Add functionality to inject IOptions<T>
            services.AddOptions();
            services.Configure<GlobalConfigurationSettings>(Configuration.GetSection("GlobalConfigurationSettings"));
}

We need a custom class to load configuration settings;

    public class GlobalConfigurationSettings
    {
        public string LowerEnvironment { get; set; }
        public CustomerConfig CustomerConfig { get; set; }
    }

    public class CustomerConfig
    {
        public string CustomerKeyurl { get; set; }
        public string CustomerdetailsUrl { get; set; }
        public Agency Agency { get; set; }
    }

Finally, we will be injecting RequestDelegete and IOptions from the constructor in middleware;

public class MiddlewareWithIOptions
    {
        private readonly RequestDelegate _next;
        private readonly GlobalConfigurationSettings _configurationSettings;

        public MiddlewareWithIOptions(RequestDelegate next, IOptions<GlobalConfigurationSettings> optionsSettings)
        {
            _next = next;
            _configurationSettings = optionsSettings.Value;
        }

And InvokeAsync method;

        public async Task InvokeAsync(HttpContext httpContext)
        {
            try
            {
                var lowerEnvironment = _configurationSettings.LowerEnvironment;
                var customerKeyUrl = _configurationSettings.CustomerConfig.CustomerKeyurl;
                Console.WriteLine($"Middleware using IOptions {lowerEnvironment} - {customerKeyUrl}");
                await _next(httpContext);
            }
            catch (Exception ex)
            {
                throw ex;
                //_logger.LogError($"Something went wrong: {ex.Message}");
            }
        }

Add this line to Startup.cs file;

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{

            app.UseMiddleware<MiddlewareWithIOptions>();
}

If we want to restrict URL segment, we can write InvokeMethods like this;

       public async Task Invoke(HttpContext context)
        {
            if (context.Request.Path.StartsWithSegments("/swagger")
                && !context.User.Identity.IsAuthenticated)
            {
                context.Response.StatusCode = StatusCodes.Status401Unauthorized;
                return;
            }

            await _next.Invoke(context);
        }

For an example in controllers, refer to this article;

Resources

https://docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration/?view=aspnetcore-6.0

Protected web api configuration

Like web apps, the ASP.NET and ASP.NET Core web APIs are protected because their controller actions are prefixed with the [Authorize] attribute. The controller actions can be called only if the API is called with an authorized identity.

Consider the following questions:

  • Only an app can call a web API. How does the API know the identity of the app that calls it?
  • If the app calls the API on behalf of a user, what’s the user’s identity?

Read more here;

https://docs.microsoft.com/en-us/azure/active-directory/develop/scenario-protected-web-api-app-configuration

How to use AppSettings.json in Azure Web App and Web API?

In App Service, app settings are variables passed as environment variables to the application code.

For ASP.NET and ASP.NET Core developers, setting app settings in App Service are like setting them in <appSettings> in Web.config or appsettings.json, but the values in App Service override the ones in Web.config or appsettings.json. You can keep development settings (for example, local MySQL password) in Web.config or appsettings.json and production secrets (for example, Azure MySQL database password) safely in App Service. The same code uses your development settings when you debug locally, and it uses your production secrets when deployed to Azure.

Let’s say we have this AppSettings file;

{
  "ConnectionStrings": {
    "MyDB": "Data Source=localhost;Initial Catalog=ZooDB;Persist Security Info=True;User ID=monkey;Password=pepepe",
    "MyLog": "Data Source=localhost;Initial Catalog=ZoodDBLog;Persist Security Info=True;User ID=banana;Password=eat"
  },
  "AllowedHosts": "*"

The connection settings on Azure Api App or Web App blade under configuration would be;

First Database

Name
MyDB

Value
Data Source=remotehost.com;Initial Catalog=ZooDB;Persist Security Info=True;User ID=remoteMonkey;Password=xxxee

Type
SQL Server

Second Database

Name
MyLog

Value
Data Source=remotehost.com;Initial Catalog=ZooDBLog;Persist Security Info=True;User ID=remoteMonkey;Password=xxxee

Type
SQL Server

Let’s say we have these hierarchal settings in AppSettings file;

"ApplicationSettings": {
    "CanImpersonate": "true",
    "GenerateJwt": "false",
    "ActiveDirectorySource": {
      "DataSource": "Database",
      "ActiveDirectory": {
        "Username": "variable",
        "Password": "variable",
        "DomainName": "variable",
        "EmailKey": "mail",
        "FirstNameKey": "givenName",
        "LastNameKey": "sn",
        "PhoneKey": "telephoneNumber",
      },
      "Database": {
        "ConnectionString": "Data Source=localhost;Initial Catalog=ZooDB;Persist Security Info=True;User ID=monkey;Password=pepepe",
        "Table": "ad.monkeytable",
      }
    },
"AllowedHosts": "*"

The connection settings on Azure Api App or Web App blade under configuration would be;

Name
ApplicationSettings:ActiveDirectorySource:Database:ConnectionString

Value
Data Source=remotehost;Initial Catalog=ZooDB;Persist Security Info=True;User ID=monkey;Password=pepepe

Type
SQLServer

If there are application settings other than connection string, they would be configured like this;

Name
ApplicationSettings__ActiveDirectorySource__Database__Table

Value
ad.monkeytable

The only difference between single and hierarchal structure is addition of : and __ qualifier’s (Two underscores connected).

When reading in ASP.NET core application, hierarchy can be stepped down with (:). for example;

# get value from appsettings
var logConnectionString = configuration.GetSection("ApplicationSetting:ConnectionStrings:LogDatabase");

#use the value
Console.WrtieLine(logConnectionString.Value);

If for some reasons, above configuration doesn’t work, try to publish to app service using Visual Studio publish feature. Make sure to add connection dependency manually.

Sources

https://techcommunity.microsoft.com/t5/apps-on-azure-blog/asp-net-core-appsettings-for-azure-app-service/ba-p/392596

https://docs.microsoft.com/en-us/azure/app-service/configure-common?tabs=portal

https://docs.microsoft.com/en-us/azure/app-service/configure-language-dotnetcore?pivots=platform-windows#access-environment-variables