IIS Field Readiness - blog of the European IIS team

How to find the Global Admin for your Azure AD tenant

friis[at]microsoft.com — Fri, 20 Apr 2018 11:46:19 GMT

The smooth working of a bot will require a proper configuration on Azure AD. Sometimes users themselves don't have the permission to modify settings in AAD, only Global Admin will have the right, then the question becomes: how to find my Global Admin ? For now it's not feasible via Azure Portal, but we can user Powershell commands to achieve this goal.

Here we'll use the Azure Active Directory PowerShell for Graph module. It can be downloaded and installed from the PowerShell Gallery: www.powershellgallery.com. The gallery uses the PowerShellGet module. The PowerShellGet module requires PowerShell 3.0 or newer and requires one of the following operating systems:

Windows 10 / Windows 8.1 Pro / Windows 8.1 Enterprise / Windows 7 SP1 / Windows Server 2016 TP5 / Windows Server 2012 R2 / Windows Server 2008 R2 SP1

PowerShellGet also requires .NET Framework 4.5 or above. You can install .NET Framework 4.5 or above from here. For more information, please refer to this link. For more detailed info on installation of the AzureAD cmdlets please see: Azure Active Directory Powershell for Graph.

1. Launch Windows Powershell console as Administrator;

2. If you have never installed Azure AD module in Powershell, please type "Install-Module AzureAD"; 3. You'll receive the following warning: 4. Type Y to continue; or you can type A to accept all so you'll not be asked again; 5. Once installation finished, type command "Connect-AzureAD", a pop-up window for user connection will show up. Please logon with your Azure account; 6. Once you get logged in, some basic information regarding this AAD tenant will be shown in Powershell console: 7. Then execute the command "Get-AzureADDirectoryRole", a list of available roles under this AAD tenant will be shown; 8. From the list, copy the ObjectId for the fole "Company Administrator" into Notepad; (Note: Global Administrator = Company Administrator in this context) 9. Then execute the following command to get the Admin account info (please replace the highlighted part with the ObjectId you've copied in Step 8): Get-AzureADDirectoryRoleMember -ObjectId "Put-ObjectId-here" 10. You'll get some necessary information from the displayed result regarding your Global Admin. Hope this article would be useful for you. Jin W. from Microsoft France IIS/ASP.NET/Azure Bot team You might also be interested in: Administrator roles in Azure Active Directory https://docs.microsoft.com/en-us/azure/active-directory/active-directory-assign-admin-roles-azure-portal Azure Active Directory PowerShell 2.0 https://docs.microsoft.com/en-us/powershell/module/azuread/?view=azureadps-2.0

Fail to create bot with error ‘Authorization_RequestDenied’

friis[at]microsoft.com — Wed, 04 Apr 2018 22:09:12 GMT

Since last December our team starts to support Azure Bot Framework, so in this blog you'll start seeing some best practices from our field experience Many of our customers encounter the following error when creating a bot in Azure Bot portal (please check here for bot creation steps): "Authorization_RequestDenied Insufficient privileges to complete the operation. Please check that your account has sufficient access to the Microsoft app registration portal link below. " This is a known issue which is often caused by insufficient permission of the user account in Azure AD. Basically there are 2 settings to verify if the account has appropriate permissions: In Azure portal, go to Azure Active Directory -> click on "User Settings" -> verify the following values:

Under "App registrations" section, "Users can register applications" should be "Yes";
If your account is a guest user, then under "External users" section, "Guest users permissions are limited" should be set to "No".

You may find that you are not able to modify those settings, that's because they are managed by Global Admin accounts for this AD tenant. Please contact your Global Admin account to implement the right settings. Another situation you may encounter is, you don't have access to the "User settings" page with message "No access": This is probably because you are a guest user with a custom domain in this Azure AD tenant, and action plan is the same: reach out to your Global Admin asking for permission check. If this cannot resolve your problem, please don't hesitate to raise a support ticket so we can work together on it. We'll continue sharing our knowledge about Azure Bot Framework, stay tuned and let's Bot together! Some articles you may be interested in: Migrate your bot from Bot Framework Portal to Azure Portal https://docs.microsoft.com/en-us/bot-framework/bot-service-migrate-bot Debug bots with Bot Framework Emulator https://docs.microsoft.com/en-us/bot-framework/bot-service-debug-emulator Jin W. from Microsoft Support team of IIS/ASP.NET/Azure Bot

Issues with managing Bot Registration Properties

u014_delatrei — Mon, 05 Mar 2018 12:43:01 GMT

I've seen quite a few questions recently about issues managing the Bot Registration properties. While working with the Bot Services, you might need to make some changes to the properties, such as generating a new password or adding a Co-owner to the Bot. You can edit the Bot Registration properties by going to the Settings blade, and then to Manage link, next to the Microsoft App ID. These steps are also outlined in the documentation for how to register a bot with Bot Service https://docs.microsoft.com/en-us/bot-framework/bot-service-quickstart-registration When you click on the Manage link, it should open up the Registration properties on https://apps.dev.microsoft.com, where you can manage the App Password, the Platform, the Owners, the Permissions, etc. If you don't have the right permissions to manage the Bot Registration properties, you will see an error message, saying "The application was not found. The application no longer exists, or is not associated with your account." However, it's not clear from the error message what permissions you are missing to be able to manage the Registration properties. If you believe that you should have the necessary permissions, but still see the above error message, you might be in the following scenario:

You have access to more than one tenant AND
You are creating the bot in a tenant that is not your default (The default tenant is the one that is automatically selected when you first sign into Azure in an incognito window.)

If the two conditions above are met, you will see the error message when trying to manage the Bot Registration properties because it is not possible to manage application registrations that are not in the user's default tenant. The challenge here is that there is no way of changing the default tenant in Azure, at least for now. This feature might be added in the future, but until then the workaround you may pursue is the following:

Browse the apps.dev.microsoft.com logged in with the application owner account
Try to see if you can force the URL to reach the application: https://apps.dev.microsoft.com/#/application/
Test the same URL but this time logged in as the Global Admin of the directory.

You should be able to manage the Bot Registration properties using the above workaround while logged in as application owner or Global Admin of the directory. For creating other bots in the future, another possibility is to set up an account that is only in the default tenant, and use that to create the bot. Hope that you've found this article helpful. This blog will continue to add more content related to the Bot Framework. For more Bot Framework content, also check out this blog: https://blog.botframework.com/ If you have a question that is not answered in one of the blog articles, don't hesitate to open a support ticket with Microsoft. By Roxana Gheorghe

Logging for ASP.net CORE applications when you receive 502.3 and 500 status codes

friis[at]microsoft.com — Wed, 07 Feb 2018 10:27:09 GMT

As we start to see more and more ASP.net Core applications being used in production, our customers are coming to us with problems that are specific to these types of deployment scenarios. This article will attempt to deal with one such scenario – where the ASP.net Core web-application running behind IIS is sending back 502.3 response codes or simply 500 response codes. IIS and ASP.net Architecture lesson. Before we delve into the topic, a small architecture refresher is always nice to have. With ASP.net running on the full .Net framework, the .Net Runtime was hosted inside the IIS worker process, and all execution and response elaboration took place here. The diagram below attempts to show that:

The client computer (browser or application) will create and send an HTTP request to a web-server (which in our case is IIS)
The http.sys driver (kernel component of IIS) receives the request and queues for processing in the worker process (user mode component)
Once finished processing, the worker process has elaborated an HTTP response for the request, an sends it back to http.sys
Http.sys sends the response back across the wire, to the requesting client.

Should you need a complete refresher of the IIS architecture, I would suggest the IIS architecture and components video series available here: https://linqto.me/n/IISArchitecture . In the case of an ASP.net Core web-application that works behind an IIS web-server, the application runs in its own process, called dotnet.exe. This process is activated when the request is received by the worker process, and the dotnet.exe process is a child process of the w3wp.exe process. Let's see the architecture: With ASP.net Core request processing, the request follows the same path to the Worker process, so we will only focus on the different steps: 3 – the ANCM (short for ASP.net Core Module) is a native module that lives inside the worker process, and will start the dotnet.exe process and then forward the request to it for processing. 4- the ASP.net Core application that lives inside dotnet.exe (child process of w3wp.exe) will process the request and issue a response. This architecture should look pretty familiar to some since it resembles CGI (common gateway interface) execution for languages like Perl and Php in IIS, however the dotnet.exe process is not restarted after executing each request. Causes of 502.3 responses for ASP.net Core applications If we review the Http status and substatus codes for IIS (available here: https://linqto.me/IISCodes), the 502.3 status code translates into: Bad Gateway: Forwarder Connection Error. The gateway in this case is the IIS worker process, since this is working as a reverse proxy between the connecting client and the dotnet.exe process. In plain English, when you see this status code in the IIS logs, it means that the dotnet.exe process either did not respond to the request or took too long to respond (step 3 in the above diagram). Using FREB tracing, is such cases does not yield many more details. You will only see that the status code of the request is changed by the ANCM module but will not have any information as to what occurred in the dotnet.exe process, which can be a challenge. The first thing you need to know is that the ANCM module does expose configuration in IIS. While not available under an Icon in the central pane of the IIS Manager, this configuration can be reached by using the configuration manager feature in the IIS manager, and then going into the system.WebServer/AspNetCore tag as shown below: Settings available for the ANCM : Some settings to call out here are the following:

Start-up time limit: the allowed limit for the dotnet.exe process to start and begin processing requests. The default value is 120 seconds.
Shutdown time limit: when the worker process shuts down for recycling, it will have to await the shutdown of the dotnet.exe process before it performs a shutdown of its own. This time is by default 10 seconds.
Request timeout: the amount of time that the ANCM is willing to wait for the dotnet.exe process to process an HTTP request it has been forwarded. Should this time be exceeded, the ANCM module will return a 502.3 response code.

How to gather more data – logging The ANCM module also provides the possibility to turn on logging for the ASP.net Core application. This can be done by setting the value of stdoutLogEnaled to 'true' and. The tricky part is that the Logs folder (default value of the stdoutLogFile) has to be created by hand, if not no logs will be generated. As such, you will need to bring up File Explorer, navigate to the root folder for your ASP.net Core website (such as C:\inetpub\wwwroot) and create a folder called 'Logs' inside. You can also control the level of verbosity for the logs. This is done inside the appsettings.json file in which you have the following configuration section:

"Console": { "LogLevel": { "Default": "Warning" } }

By default, the level is set to 'Warning' and all first hand exceptions and critical errors will be logged. If you set the logging level to 'Information' everything, including the request Urls will be logged. Below is an excerpt from one such log show that a new request has arrived for processing:

info: Microsoft.AspNetCore.Hosting.Internal.WebHost[1] Request starting HTTP/1.1 OPTIONS https://corewebapi/api/EchoCors

You can see you have information on the Request verb used, the url and protocol version. When trying to understand why your application is not behaving as expected, using logging to review errors in execution in this way can provide you with vital clues for troubleshooting. In the ASP.net Core WebAPI CORS tutorial I have written on this blog, this technique proved invaluable for debugging the WebAPI application while writing the tutorial. By Paul Cociuba https://linqto.me/about/pcociuba

ASP.NET HttpContext in async/await patterns using the Task Parallel Library – Part 3

friis[at]microsoft.com — Tue, 05 Dec 2017 16:50:41 GMT

The SynchronizationContext (SC) is a vital component for the ASP.NET request lifecycle and it is strictly coupled to the HttpContext. In the previous posts we saw how running asynchronous operations by using specific TPL patterns might lead to losing the SynchronizationContext and, thus, reference to the HttpContext. Such a behavior can impact applications in several ways, both directly (e.g. tasks failing due to null references when accessing the HttpContext or one of its fields) and indirectly (e.g. faults in external libraries). Before jumping to the summary and conclusions, I owe you an answer to the challenge from the previous post. Below the question I left you to meditate upon, which refers to our demo MVC application used to output debug traces about the execution flow and the SC flow status (I encourage you to quickly re-check the previous posts to recall the code involved):

What do you expect to happen when calling the Index action with

configureAwait = false
tsFromSyncContext = true

Previously we went through some tests and analyzed what happens when turning those flags on and off individually. Specifically:

configureAwait set to false causes the SC to stop flowing starting from the very first await operation. This yields into a definitive loss of the SC, which is then unavailable both in the awaited task and in the awaiter context once it resumes the execution.
tsFromSyncContext set to true, instead, proved to be useful to persist the SC on the awaited task.

This is the output we get when running the application with both flags enabled. Notice the second await operation (the one calling Task.Factory.StartNew) fails. The error message is somewhat cryptic. However if we speculate on what the consequences of calling ConfigureAwait(false) on the awaiter context are, we should understand the SC is lost once the execution is returned to the controller context. Therefore, when the second await operation is invoked and tries to post the newly created task against the current SC, the operation simply can't happen as there is no SC available any more. If you followed me thus far, this example should point out how delicate this whole system could be and how the TPL primitives could be challenging to handle and lead to unexpected behaviors.

Wrapping it all up!

Up to this point, I hope we have a clearer vision on the various scenarios we can run into when using async/await patterns in ASP.NET. However, I bet there are still a few questions open. The most interesting ones, or better, the ones I would be asking myself are:

Why awaiting on Task.Run (or other primitives like Task.Factory.StartNew) does not persist the SC while awaiting on a custom async method does?
Why if we force the awaiter to use the SynchronizationContextTakScheduler we don't face this problem?
Avoiding primitive TPL APIs might just not be a feasible option. How can we deal with this situation and instrument a workaround?

Let's try to address them one by one.

Why awaiting on Task.Run does not persist the SC while awaiting a custom async method does?

To find out, we need to peek at the .NET source code. Luckily, it's public! :) Task.Run and other primitive TPL methods rely on the internal method Task.InternalStartNew, which then calls into the following one: [code highlight="9" language="csharp"] internal void PossiblyCaptureContext(ref StackCrawlMark stackMark) { // In the legacy .NET 3.5 build, we don't have the optimized overload of Capture() // available, so we call the parameterless overload. #if PFX_LEGACY_3_5 CapturedContext = ExecutionContext.Capture(); #else CapturedContext = ExecutionContext.Capture( ref stackMark, ExecutionContext.CaptureOptions.IgnoreSyncCtx | ExecutionContext.CaptureOptions.OptimizeDefaultCase); #endif } [/code] The Capture method, invoked with the IgnoreSyncCtx flag, does exactly what we would expect. It skips capturing the SC, suppressing its flow. [code highlight="2" language="csharp"] // capture the sync context if (0 == (options & CaptureOptions.IgnoreSyncCtx)) syncCtxNew = (ecCurrent.SynchronizationContext == null) ? null : ecCurrent.SynchronizationContext.CreateCopy(); [/code] Guess what? The framework doesn't let user-defined async methods to follow this very same path and simply lets the SC flow. What this actually means is if in our code we simply run await on DoStuff, the SC never gets lost.

Why if we force the awaiter to use the SynchronizationContextTakScheduler we don't lose the SC?

This question also needs some internals lookup. The SyncrhonizationContextTaskScheduler exposes a queueing mechanism that posts the work items against the currently captured SC. In this way, the SC keeps flowing and it is persisted. [code highlight="3" language="csharp"] protected internal override void QueueTask(Task task) { m_synchronizationContext.Post(s_postCallback, (object)task); } [/code] On the contrary, the ThreadPoolTaskScheduler (default for ASP.NET), ignores the SC completely: [code highlight="14" language="csharp"] protected internal override void QueueTask(Task task) { if ((task.Options & TaskCreationOptions.LongRunning) != 0) { // Run LongRunning tasks on their own dedicated thread. Thread thread = new Thread(s_longRunningThreadWork); thread.IsBackground = true; // Keep this thread from blocking process shutdown thread.Start(task); } else { // Normal handling for non-LongRunning tasks. bool forceToGlobalQueue = ((task.Options & TaskCreationOptions.PreferFairness) != 0); ThreadPool.UnsafeQueueCustomWorkItem(task, forceToGlobalQueue); } } [/code]

Avoiding primitive TPL APIs might just not be a feasible option. How can we deal with this situation and instrument a workaround?

Eventually if we just cannot get rid of calling Task.Run, what can we do? The best option is to plan for stateless asynchronous operations. If you think about it, the great advantage of async/await is to offload background operations and allow the request to keep on executing in the meantime. Making those tasks stateless not only solves the potential problem of losing the HttpContext, but it also makes the web application more robust in case a background operation fails. Odds of a ASP.NET request really needing to await on a purely stateless operation are not many and should let you think twice whether background operations are worth to be made asynchronous at all, given they would still have to be awaited for the request to complete. Last but not least if you are thinking of porting your web app on microservices for great scaling and orchestration (e.g. deploying it on a Azure Service Fabric cluster), stateless agents performing specific, request-agnostic tasks can be much easier to implement. That said, there might be situations where going stateless is not possible or easily achievable. Similarly there certainly are scenarios where an ASP.NET request should await on an async operation. For such situations, the most immediate approach is either to await on custom async methods (which do not lead to SC loss) or on new tasks by using the Task.Factory.StartNew overload accepting a TaskScheduler as parameter. In other words, this would mean overwriting all code references from [code gutter="false" language="csharp"] Await Task.Run(myBackgroundDelegate()); [/code] To [code gutter="0" language="csharp"] Await Task.Factory.StartNew(myBackgroundDelegate(), CancellationToken.None, TaskCreationOptions.RunContinuationsAsynchronously, TaskScheduler.FromCurrentSynchronizationContext()); [/code] Unfortunately, this approach might not fit all the situations too. For instance what if Task.Run is used in an external library? In such a scenario, there is actually one an additional "trick" we can use. The caveat is to await on a wrapper task, that manually posts the actual awaitable operation against the SC. To grasp how this works a little better, let's see it applied to our very first example using the Context action of the Home controller. Besides the code for storing the SC I added a new log line to show if the SC context is properly restored once the execution resumes on the controller context: [code highlight="7, 11-17, 19" language="csharp"] public async Task Context() { Response.Write(" Context action invoked.

Current HttpContext in controller context is { System.Web.HttpContext.Current.ToString() }
Current HttpContext in controller context is { System.Web.HttpContext.Current.ToString() }

Response complete."); return new HttpStatusCodeResult(200); } [/code] If you recall when we walked through this sample in the first post, we saw the HttpContext being lost in the awaited Task context. Here's the output we get this time: If we were to use this approach with the Index action instead and get the full verbose output, we would see the SC being of type AspNetSynchronizationContext and the task scheduler of type ThreadPoolTaskScheduler. Why is that? Simply because the "posting" against the SC is not piloted by the task scheduler in this case, but it is manually requested. In other words, we are explicitly taking care of what the AspNetSynchronizationContextTaskScheduler would do for us!

I know, this whole story is kind of endless and can get seriously confusing at times. However, I hope this posts contains enough insight to let you understand the basic inner workings between the TPL and the ASP.NET HttpContext. As already stressed out, I believe a code sample is worth more than a thousand words. Although the demo web app I used is not at all complicated and it is fairly easy to setup, I will soon update this post to include the link to my GitHub repo project, so you can just clone it and mess around with it! One final word to thank all the people who actively contirbute to this blog. I am humbled and impressed by receiving your feedback and I appreciate your efforts in highlighting possible mistakes or confused explanations! Also, thanks in advance to the ones who I am sure will be helping in the future too! Happy parallel HttpContexting! :) Catch you on the flipside! albigi / Alessandro Bigi

ASP.NET HttpContext in async/await patterns using the Task Parallel Library – Part 2

friis[at]microsoft.com — Sat, 02 Dec 2017 00:39:53 GMT

In case you don't recall the previous post, or just landed here, make sure to skim through it before continue reading. We left with some very boring theoretical discussions. As promised, we will get to the juicy bits this time!

Investigation - Part 1

Let's focus on the sample controller we built and give it a few spins:

Run 1

Red numbers represent calls to the Log method from the MVC controller itself. Blue numbers, instead, are calls to the Log method originating within a Task. Let's analyze the flow:

The controller executes on thread 79. Nothing remarkable here. All the information is available.
The controller awaits DoStuff, which is scheduled to run on the same thread. No information is lost here
We are back executing the controller. The thread is now 77 as the previous one was disengaged while awaiting the async call. No information is lost here as the SC is flown to the new thread
Here we are awaiting again, on the StartNew API this time. Note at this stage DoStuff is again executed on thread 79, but the SC is no longer available (it has not flown to the new thread). We do get information loss here as the HttpContext is also no longer available
When the execution resumes in the controller, we are back to normal.

At this stage I believe everyone should have clear one thing: if DoStuff needed to access the HttpContext (e.g. reading the session on the inbound cookies), we would have got a NullReferenceException!

Run 2

I know my readers are quick and they know exactly what happens if we run the code using ConfigureAwait(false). However, for the discussion's sake, it actually took me a while to understand the output below. Hence I decided to include it in the post! If you are familiar with using ConfigureAwait(false), this output shouldn't surprise you. If you are not (as I wasn't myself), check again this great post. :) In a nutshell: ConfigureAwait(true) is the default behavior when awaiting a task. This causes the SC to be captured and once the awaited task completes, the continuation is "posted" against the previously captured SC. On the contrary, ConfigureAwait(false) does not capture the SC and suppresses its flowing upon the task completion.In our example this means the awaiter (controller context) resumes discarding the current SC once the first DoStuff task completes (step 3). The controller has therefore lost its SC (as we see in the following steps).

Note: when a task is posted against a SC, this essentially means the Post method of the SC is invoked. The Post method queues the task to be appropriately worked. As you can see, the whole capturing of and posting against the SC is completely independent from the EC flow and the task scheduler used. The SC exposes a higher abstraction layer: it doesn't care how tasks are scheduled and worked, it is agnostic with respect to the low level implementation details.

Investigation - Part 2

Let's start with a quick summary:

Awaiting on native TPL async APIs, such as Task.Run or TaskFactory.StartNew, causes the SC to be lost
Likewise, the SC is lost when awaiting on non-primitive async methods and ConfigureAwait(false) is used
If the SC is not flown, so doesn't the HttpContext and all the ASP.NET state

So far so good, I guess! We understood the SC is vital for the HttpContext to be persisted and if, for whatever reason, the SC doesn't flow along with the EC, we might end up getting a NullReference when trying to access the ASP.NET request state. Well, how do we force the SC to flow along with our async code then?

Run 3

Let's take a look at what happens if we run the test page with the tsFromSyncContext switch set to true. The issue is gone!! Black magic?! :) From a code perspective, tsFromSyncContext switched on just changes this line of code [code lang="csharp" highlight="5"] await Task.Factory.StartNew( async () => await DoStuff(doSleep, configAwait).ConfigureAwait(configAwait), System.Threading.CancellationToken.None, TaskCreationOptions.None, TaskScheduler.Current); [/code] into: [code lang="csharp" highlight="5"] await Task.Factory.StartNew( async () => await DoStuff(doSleep, configAwait).ConfigureAwait(configAwait), System.Threading.CancellationToken.None, TaskCreationOptions.None, TaskScheduler.FromCurrentSyncrhonizationContext()) [/code] Any guess what's happening?! Yes!! You got it, I know you do! The line highlighted caused the awaiter to use the AspNetSyncrhonizationContextTaskScheduler instead of the ThreadPoolTaskScheduler. The former is obviously aware of the importance of the SC and this is why it ensures the current SC flows. The latter instead, as previously mentioned, is a hard worker: its main goal is to maximize throughput and performance, therefore it tries to leave behind as much overhead as possible, including the SC.

Before we jump into the next post for the conclusions and you start to get seriously bored by my writing, let me leave you with a challenge! What do you expect to happen when calling the Index action with:

configureAwait = false
tsFromSyncContext = true

If you followed me so far, you should be able to figure it out. Or even better, run the web app and see it for yourself! Honestly, it took me a while to properly understand what is going on and which line of code in our web app is accountable for what behavior. The answer to the challenge in the next post, but just a quick hint…this is a tricky question! :) albigi

ASP.NET HttpContext in async/await patterns using the Task Parallel Library - Part 1

friis[at]microsoft.com — Sat, 02 Dec 2017 00:24:57 GMT

Hopefully brief but yet needed introduction

For a long time, when ASP and ASP.NET WebForms were the latest trend, web developers had to rely mainly on synchronous programming. After all, server computing can count on multithreading and it's free from UI thread freezes. While users don't normally accept a client application freezing the UI for more than a few seconds, they are more prone waiting for a webpage to load. Moreover, AJAX and all browser-driven web requests can be used to split the page loading across multiple requests, each one running synchronously on a dedicated server thread. As far as simple web pages are concerned, this approach still works fairly decently today. Asynchronous programming is not necessary to render trivial page content or push some JS code to the client browser. However, as web applications grow in complexity, background tasks are getting more and more vital. Asynchronous programming plays a key role in modern web applications, allowing them to run background operations without significant impacts for user requests being served at the same time. The main advantages of offloading long-running operations are essentially two:

The server is able to serve requests quicker, possibly informing the user with regular updates on the background processing status. This remarkably increases the user experience (I guess we are all familiar with that horrible feeling when we are like "should I click back or reload the page? Will I have to fill in the form all over again?")
The server can offload the long-running operations, so that request threads are freed up and can be used to accommodate more incoming requests. This remarkably lowers the odds of starving the thread pool and eventually queue the requests or drop them with a service unavailable message.

Asynchronous programming is not new in .NET. However, starting with .NET Framework 4 the TPL (Task Parallel Library) has taken over the stage as it offers a broad and easy-to-use set of APIs to write asynchronous code. My own naïve definition for TPL is "the set of libraries introducing Tasks-related types and the async/await operators" (as I said, that is extremely naïve and oversimplified. Async experts, please accept my apologies!) There are lots of great discussions and blog posts about the TPL and asynchronous programming patterns in .NET. A quick search should bring up the latest and coolest ones. Although being familiar with the topic surely eases the reading of this post, I wouldn't say that is a strict requirement. Given the complexity and broadness of the topic, I will try to focus on a very specific problem. This first post describes the initial problem and introduces all the main characters of our discussion. Two more poss will follow: the first to add more details about the investigation; the second to summarize the topic and wrap up all the findings of the previous posts.

The problem

it is simple, in its formulation. Randomly our web application throws a NullReferenceException while performing asynchronous operations. With further investigation and debugging we realize that, while handling a request, the System.Web.HttpContext.Current object is null. The HttpContext object stores all the request-relevant data, including the pointers to the native IIS request object, the ASP.NET pipeline instance, the Request and Response properties, the Session (and many others). Without all of this information, we can safely tell our code is unaware of the request context it is executing into. Designing entirely stateless web applications is not easy and implementing them is indeed a challenging task. Moreover, web applications are rich of third party libraries, which are generally black boxes where unspecified code runs. How could it be that such a fundamental object, the HttpContext, is lost during the request execution? What can we do if it happens in our code and what approach should we take if it's happening inconsistently in third party libraries? Let's focus on an practical example and consider the code below: [code lang="csharp" highlight="8"] public class HomeController : Controller { public async Task Context() { Response.Write("
Context action invoked.

Current HttpContext in controller context is { System.Web.HttpContext.Current.ToString() }

Response complete."); return new HttpStatusCodeResult(200); } private Action WriteHttpContext() { return delegate () { var context = System.Web.HttpContext.Current; Response.Write($"

Current HttpContext in awaited Task context is " + $"{ (context == null ? "null" : context.ToString()) }" + $"

"); }; } } [/code] This is an action method on a MVC controller. In my tests I compiled it against .NET 4.7, but the behavior should be unchanged for any other supported version (currently, 4.5.2 or above). The controller writes directly into the response output buffer and returns upon completion (no Views involved). The core part is the code line highlighted: the controller pauses the execution while an async task is executed. In this example, the task just writes more data into the response output buffer. Although this is not really a consuming operation that would require a background task, I tried to keep the code as short and simple as possible. So bear with me and let's pretend it actually makes sense to execute WriteHttpContext asynchronously. If you load the page you would see this output: Blimey! :) The HttpContext was lost, for real!

Some quick (yet due) theory

Boring. I know….but I really cannot figure out a way to explain the juicy bits without mentioning a few key concepts. Let me introduce you some good friends from the TPL: the TaskScheduler, the ExecutionContext and the SynchronizationContext? TaskWhat? ExecutionWho? :)

The TaskScheduler is exactly what you would expect. A scheduler for tasks! (I would be a great teacher!) Depending on the type of .NET application used, a specific task scheduler might be better than others. ASP.NET uses the ThreadPoolTaskScheduler by default, which is optimized for throughput and parallel background processing.
The ExecutionContext (EC) is again somehow similar to what the name suggests. You can look at it as a substitute of the TLS (thread local storage) for multithreaded parallel execution. In extreme synthesis, it is the object used to persist all the environmental context needed for the code to run and it guarantees that a method can be interrupted and resumed on different threads without harm (both from a logical and security perspective). The key aspect to understand is the EC needs to "flow" (essentially, be copied over from a thread to another) whenever a code interrupt/resume occurs.
The SynchronizationContext (SC) is instead somewhat more difficult to grasp. It is related and in some ways similar to the EC, albeit enforcing a higher layer of abstraction. Indeed it can persist environmental state, but it has dedicated implementations for queueing/dequeuing work items in specific environments. Thanks to the SC, a developer can write code without bothering about how the runtime handles the async/await patterns.

There are a few very important takeaways about the SC:

ASP.NET has its own one, named AspNetyncrhonizationContext
The AspNetSynchronizationContext is responsible for making the HttpContext current, that is setting the static propery System.Web.HttpContext.Current to the HttpContext object related to the current request being processed.
Unlike the EC, the SC does not have to flow from thread to thread. It can, but it is not strictly necessary. Whether it actually does flow or not depends on the specific implementation of the async/await pattern.

To extensively understand how all of these elements come into play and how they seamlessly work together, I strongly recommend you to read this great post.

Investigation - Part 0

I studied Telecommunications Engineering at university. A rather theoretical subject, I would say. Then my professional career led me to study Computer Science. One of the aspects I like most about it is the opportunity to challenge myself in problem-solving with a practical approach. In situations like this, I cannot deny some theoretical basis are of great value to understand the problem context. However, there is nothing like opening an IDE and writing down some code to test and assess what happens in real life. Luckily for us, this is a fairly quick task and all we have to do is re-decorate our sample web app: [code lang="csharp" highlight="7,8,12-18"] public async Task Index(bool doSleep = false, bool configAwait = true, bool asyncContinue = true, bool tsFromSyncContext = false) { Response.Write($"{Log("Index called.")}

"); var currentContext = System.Threading.SynchronizationContext.Current; try { await DoStuff(doSleep, configAwait) .ConfigureAwait(configAwait); Response.Write($"{Log("await DoStuff completed.")}

"); await Task.Factory.StartNew( async () => await DoStuff(doSleep, configAwait) .ConfigureAwait(configAwait), System.Threading.CancellationToken.None, asyncContinue ? TaskCreationOptions.RunContinuationsAsynchronously : TaskCreationOptions.None, tsFromSyncContext ? TaskScheduler.FromCurrentSynchronizationContext() : TaskScheduler.Current) .Unwrap().ConfigureAwait(configAwait); Response.Write($"{Log("await new Task completed")}

"); } catch (Exception e) { Response.Write($"{Log($"Error {e.Message}")}
"); } return new HttpStatusCodeResult(200); } static string Log(string msg) { var syncCtx = System.Threading.SynchronizationContext.Current; var taskSchdlr = TaskScheduler.Current; var httpCtx = System.Web.HttpContext.Current; return $"{msg}

" + $"Thread: {System.Threading.Thread.CurrentThread.ManagedThreadId}
" + $"Task scheduler: {taskSchdlr}
" + $"Sync Context: {syncCtx}
" + $"Http Context: {httpCtx}

"; } async Task DoStuff(bool doSleep = true, bool configAwait = true) { if (doSleep) { Response.Write($"{Log($"DoStuff called. configAwait is {configAwait.ToString()}. Sleep is called")}
"); await Task.Run(async () => System.Threading.Thread.Sleep(SLEEPINTERVALMS)).ConfigureAwait(configAwait); } else { Response.Write($"{Log($"DoStuff called. configAwait is {configAwait.ToString()}. GetAsync is called")}
"); await new System.Net.Http.HttpClient().GetAsync("https://www.microsoft.com").ConfigureAwait(configAwait); } } [/code] Ok, I know, lots of re-decorations and debugging output. The juicy part is just the two lines highlighted above. I don't think it is worth discussing on the controller implementation, but here's a quick reference to better understand the query string parameters:

configAwait: controls the ConfigureAwait behavior when awaiting tasks (read on for additional considerations)
tsFromSyncContext: controls the TaskScheduler option passed to the StartNew method. If true, the TaskScheduler is built from the current SynchronizationContext, otherwise the Current TaskScheduler is used.
doSleep: if True, DoStuff awaits on a Thread.Sleep. If False, it awaits on a HttpClient.GetAsync operation Useful if you want to test it without internet connection
asyncContinue: controls the TaskCreationOptions passed to the StartNew method. If true, the continuations are run asynchronously. Useful if you plan to test continuation tasks too and to assess the behavior of task inlining in case of nested awaiting operations (doesn't affect LegacyASPNETSynchronizationContext)

Alright, I think I can safely admit this is possibly one of the most verbose posts of mine. Time to wrap it up and call it a day as we are going to deep dive into all of the above in the next post! albigi

Error "431 Failed to setup secure session" when connecting to a FTP Server with multiple FTP sites

friis[at]microsoft.com — Tue, 28 Nov 2017 16:25:30 GMT

Summary for lazy readers

Let's consider this scenario:

We are using FTPs (FTP over SSL) to connect to a FTP site hosted on a Windows Server 2008 or later
We have multiple FTP sites using SSL and we are using the virtual hostname feature
FTP clients suddenly report connection error: "431 Failed to setup secure session"
The FTP site certificate has been renewed or it is still valid

Let's also add a few conditions more:

We have another FTP site using a wildcard FTPs binding (no virtual hostname used)
The certificate used by the wildcard FTP site is expired or invalid

As you may have guessed already, the key is to make sure a valid certificate is used by the FTP site using the wildcard binding.

Moar details1!

When I faced this issue myself, my very first question was:

What's the link between the two FTP sites? Aren't they supposed to be completely unrelated?

The quick answer is: yes and no :) From a resource isolation perspective, they are completely unrelated. Each site has its own directories, ACLs, authentication enforcement and so on. However, the link between the two does exist when it comes to the binding definition. To go through the detailed answer, we first need to understand how virtual hostnames work. Virtual hostnames do not exist in the FTP protocol. Although RFC 7151 defines the HOST command, which extends the FTP commands subset, not all clients and servers implement it. As far as Windows Server and FTP 7 or later are concerned, the virtual hostname feature entirely relies on the proprietary implementation defined in the article referenced earlier:

the virtual host name is used as part of the user name during the login process

Virtual hostnames are a clever way to cope with the two contrasting goals:

Have multiple FTP sites
Have all the sites bound to the same IP & Port

Quite as much as HTTP SNI does, virtual hostnames allow clients to inform the server about the specific site they are intending to reach. This allows the server to disambiguate among multiple sites listening on the same port. While SNI is an extension over the TLS handshake protocol, meaning the server can be informed about the client will to reach a specific hostname before the HTTP request is actually processed, in FTPs (being it implicit or explicit) there is no way to use such feature. Using virtual hostnames is a good workaround, but it causes the client "intentions" to be unveiled to the server only during the FTP handshake, which means once the TLS channel has been already brought up and the incoming request mapped to the destination site. Did you guess what's the caveat here? :) Let me show you with a practical example.

My FTP server be1i.albigi.lab has two sites: FTPA and FTPB
Both are using a FTPs implicit, with binding on IP 172.23.8.163 and port 990
FTPA is not using virtual hostnames and the SSL certificate bound to it is self-signed and has localhost as subject name (invalid according to the client)
FTPB is using virtual hostname ftpb.albigi.lab and its certificate is a valid one issued by the domain authority with be1i.albigi.lab as subject name

Here's how they look like in IIS Manager: And here's the netstat -ano output after both sites are up and running: Notice there is one only binding on port 990 (actually two, if we consider the IPv6 binding) and the process listening on it is the FTP Service: Below are the client connection settings:

FTPA

FTPB

Here's where the magic happens: the connections are exactly identical but the FTPB one uses a username prefix (yes, for anonymous users too!) Now, here's what happens from a client perspective:

FTPA

This is totally what we would expect, right? Depending on the client used and its configuration, receiving an invalid certificate can either show a security prompt (like the one in the screenshot) or simply do not trust the server and close the connection. This is when the error 431 Failed to setup secure session gets logged.

FTPB

Believe it or not (I don't like to believe, so I would encourage you to test this out for yourself) we get the same prompt! For both sites, discarding the warning and telling the client to ignore the certificate validation issues results into a successful connection. What's going on?

FTPA

The FTP client logs show this:

FTPB

And the client logs: A part from the FTP USER command, there are no differences at all! By now, I believe you should have guessed what's actually happening. But we are curious and we like to play geeky games, right? Let's change the FTPB site SSL settings so that it is not bound to any certificate: Logically speaking, a FTP site with such settings should never work. From our client, let's connect to the FTPB site…wait, what? It's still complaining about the certificate but it's working! Surprised, are you? I don't believe so! :) Ok, enough playing!

Let's wrap it up!

There is one and only one actual SSL binding up!

Which one?

The SSL certificate set in the most general binding is used.

Why?

A site not using virtual hostnames is considered to have a more general binding, thus FTPA configuration is honored.

Do I have to setup a FTPB site then?

Of course! FTPB configuration comes into play only when the FTP client has shared his will to connect to FTPB by sending the virtual hostname in the USER prefix. Once the FTP handshake is complete, the life cycle of the communication is completely separated between the two sites.

Do I need to bind the SSL Certificate to all of the FTP sites?

Ah! Good question! No, you do not. The SSL channel is always established between the client and the FTP site with the most general matching binding configuration. If you have many FTPs sites with different virtual hostname bindings, a good strategy is to have a "general" site (wildcard binding) used for central administration of the SSL certificate. The site can be as simple as possible and don't authorize any user (it doesn't really matter as during the FTP logon the proper site based on the virtual hostname is selected). All the other actual sites do not need any specific SSL configuration.

So, if we want to solve the error "431 Failed to setup secure session", let's first make sure the site handling the FTPs connection in the first place uses a valid certificate! Catch you guys on the flip side! albigi / Alessandro

Putting it all together – CORS tutorial

friis[at]microsoft.com — Fri, 24 Nov 2017 19:54:13 GMT

Hosting the two sites on IIS and understanding the request flow and needed configuration to allow the entire application work correctly is what we will focus on in this article. This far, in this tutorial we have gone through creating the front-end website using Razor Pages and the back-end HTTP web-service using WebAPI, as well as preparing the two solutions for publishing on IIS as explained in: https://docs.microsoft.com/en-us/aspnet/core/publishing/iis?tabs=aspnetcore2x . Since the application is expected to run using Windows Integrated authentication there will be a couple of more steps that we will need to take in both solutions to make sure that the ASP.net Core interacts correctly with IIS and is forwarded the authentication tokens from the IIS worker process (w3wp.exe). The first thing to accomplish, is to setup the applications to work with IIS. This is achieved in the Startup.cs class of each of the two projects. We will be adding IIS as a service, in the ConfigureServices method, using the options pattern. The only option we are interested in is having the applications configured for Windows Authentication. This is done by setting the AutomaticAuthentication option and setting to true. The code is shown below: public void ConfigureServices(IServiceCollection services) { services.AddMvc(); //needed to enable IIS integration with Windows Auth services.Configure(options => { options.AutomaticAuthentication = true; }); } The highlighted code is what needs to be added to the ConfigureServices method in both projects, after which they should be recompiled and published. Inside the IIS Manager Console, I recommend setting two websites (they can be on different servers on the same server) and setting up HTTP bindings with host header entries, for corerazor and corewebapi, by selecting the 'Bindings' action for each website: Host bindings for CoreRazor – front end website Host bindings for CoreWebAPI – backend http webservice application SIDE NOTE: If you plan to host both websites on the same Windows server, and if you have no DNS so that you can setup CNAME aliases for the hostnames coreRazor and coreWebApi , you can modify the hosts file of the computer you will be accessing the website from to map the two entries to your server's IP address. To do this, you may wish to follow the article below: https://www.petri.com/easily-edit-hosts-file-windows-10 . The second step in configuring the two applications to use Windows Integrated authentication, is to configure the ASP.net Core Platforms Handler to forward the Windows integrated authentication token to the dotnet.exe process that is hosting the application. The easiest way to achieve this is using the Configuration Editor in the IIS Mangeger console. Just select each of your sites, and then double click the 'Configuration Editor' icon in the middle pane: Once inside this feature, you will be able to access any configuration relating to the website, that is coming either from ApplicationHost.config file or the website's web.config file. Using the dropdown control from the top of the Configuration Editor window, select the System.WebServer/AspNetCore tag from the list of availabe tags as shown: Within this section, you will find all of the possible configuration for the ASP.net Core Platforms Handler. Among the settings is one called forwardWindowsAuthToken whish should be set to 'true', in order for the module to forward the authentication token to the dotnet.exe process. Next, we need to understand the request flow, which may be then most important part of this tutorial. Nothing gets the point across better than a visual diagram: In the above diagram, the client browser will: 1. Make a request to https://coreRazor/asyncPoster . The request will be of type GET and will result in the Razor Page executing on the server and sending back some HTML markup to the browser to render. Once the page is displayed, the user will proceed and enter some text in the text area control and press the 'Echo Text' button. At this point the interesting stuff starts to happen. 2. The JavaScript engine will send a CORS preflight request to the https://coreWebAPI/api/EchoCors url. The purpose of this request is to make sure that the website allows requests coming from another site (notably https://coreRazor) to be sent and processed. The request materializes as an OPTIONS request on the wire, and the following HTTP headers are sent out: OPTIONS /api/EchoCors HTTP/1.1 Host: corewebapi Connection: keep-alive Access-Control-Request-Method: POST Origin: https://corerazor User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36 Access-Control-Request-Headers: content-type Accept: */* Accept-Encoding: gzip, deflate I have underlined the important information in red – the Origin header indicates where the Javascript that is perfoming the CORS request originated from: https://corerazor. The Access-Control-Request-Method indicates what kind of request the script woud like to make (a POST request in this case). According to: https://fetch.spec.whatwg.org/#cors-preflight-fetch , the CORS preflight request has to go out without any authentication. And this is the main problem in our case. If you have followed along with the tutorial up to this point, you will know that Windows Integrated Authentication will reject any requests that are sent without credentials, and the response from the IIS server will be a 401 status code, requesting authentication. This will not allow the JavaScript engine to know if requests from the origin site are allowed to the target backend site, and will result in failure. In order to remedy this, we need to modify the IIS settings, for the backend https://coreWebAPI site to allow anonymous requests in certina cases. This is where a good understanding of the HTTP pipeline in IIS comes in handly, and I would suggest a detour to video number 2 in the IIS Architecture and Components videos I have posted online a while ago: https://linqto.me/n/IISArchitecture . The HTTP processing pipeline is based on events being raised and pieces of code called 'http modules' subscribing to the notificatins sent out on these events to perform changes to the request or the response. Two pipeline stages are important here: 1) Authentication and 2) Authorization. In the authentication stage, we are trying to understant who is the user behind the request. So we may chose to say the user is the 'anonymous user', and that annonymous authentication should also be turned on. Below are the authentication settings on IIS for the https://coreWebAPI site – note that both Windows Integrated Authentication and Anonymous Authentication are enabled: In the next stage of request processing, the Authorization stage (or Authorization event), we need to make sure we only allow the anonymous requests from CORS preflight and require all other incoming requests have authentication credentials supplied. We can achieve this through Authorization Rules. A default authorization rule granting all users access to the site is already in place and supplied by default by IIS. We will start by modifying this rule to only allow anonymous users, if they send requests that are using the OPTIONS http verb. Below is the target configuration in IIS for this authorization rule: However, this authorization rule is not enough as it will block all other requests. We need a second 'Allow' Authorization rule that needs to be introduced. This rule will perimit access to the application to a desired group of users – for the demonstration, I have chosen the 'Users' group, which should include most authenticated user accounts from the server where the backend application is hosted. In a real world scenario, we would configure an Active Directory group, such as 'Domain Users' if a really large scope was targetted, or some more restrained, like a specific user group. Here is what the web.config file for the backend website will contain following the modifications to the authorization rules: These two rules will ensure that: CORS preflight OPTION request rules will be honored without requiring authenticatin, will all other incoming requests will need to present valid credentials to be allowed through to our ASP.net Core WebAPI application. If we review the response headers for the CORS preflight request shown earlier, we can see that the server does authorize the receipt of CORS request from the https://coreRazor website: HTTP/1.1 200 OK Vary: Origin Server: Kestrel Access-Control-Allow-Credentials: true Access-Control-Allow-Headers: content-type Access-Control-Allow-Origin: https://corerazor X-Powered-By: ASP.NET Content-Length: 0 In the highlighted headers, we can see that the server is indicating that CORS requests to this server from the website are allowed if they supply credentials, and if the requests orginates from the https://coreRazor site. With this information, the JavaScript engine can now proceed to perform the POST request with JSON content to send to the WebAPI controller for processing. By Paul Cociuba https://linqto.me/about/pcociuba

Building the ASP.net Core WebAPI backend – CORS tutorial

friis[at]microsoft.com — Fri, 24 Nov 2017 19:53:55 GMT

With the front end site complete, we can shift focus to building the WebAPI backend that will be powering the Echo Text service. Just as for the front-end site, In Visual Studio 2017, you can choose to create a new Project, and select the 'Web' category. Give the project a name and then select the WebAPI application template from the second step of the new project Wizard. Do not forget to setup Windows Integrated as an authentication method for this backed application as well, by pressing the Change Authentication button in this step of the Wizard. Once the project is created on disk by Visual Studio, you can proceed and delete the ValuesController class that is located under the 'Controllers' folder inside the Solution Explorer. Then add a new Controller to the folder, and chose the WebAPI Empty Controller template: Call the new controller 'EchoCorsController'. Be careful, for the project to work as shown here, you will need to respect the name of the controller class, otherwise the JavaScript code from the previous tutorial will not POST to the correct url. For completeness, I will also be using a model class to represent the data received from the front end site. To achieve this, create a Models folder in the solution, and add a class called TextMessage inside. The end result should have the project looking like the following in the solution explorer: The TextMessage class contains a single string property called EchoText, and is a POCO object (Plain old CLR objet): public class TextMessage { public string EchoText { get; set; } } It will be an instance of the TextMessage object that we will be binding to in the EchoCorsController when receiving the JSON data from the front end. Here is the code of the controller class: [Produces("application/json")] [Route("api/EchoCors")] public class EchoCorsController : Controller { // POST api/echocors [HttpPost] public IEnumerable<string> Post([FromBody]TextMessage eMessage) { //return back a JsonResult to echo the text return new string[] { "Echo back:" + eMessage.EchoText }; } } The controller has one method called Post. By convention this will respond to incoming Http POST requests. To make sure that the Post method is only invoked by POST requests, the [HttpPost] attribute has been added to decorate the action method. The method will take a parameter of type TextMessage (our model class), and, before invoking the action method, the MVC Framework will look to data-bind data from the request to populate the fields of this object instance. The [FromBody] attribute will indicate to the data binder that it should only seek to find suitable values for the TextMessage's properties inside the request body, and not in the query string, route data, etc… Below I have placed a POST request captured with the Chrome F12 browser tools from the front end. The part highlighted in gray represents the request body, and contains the JSON data that the front-end will be transmitting. POST /api/EchoCors HTTP/1.1 Host: corewebapi Connection: keep-alive Content-Length: 48 Accept: application/json, text/javascript, */*; q=0.01 Origin: https://corerazor User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36 Content-Type: application/json Referer: https://corerazor/AsyncPoster Accept-Encoding: gzip, deflate {"echoText":"Life is too short - learn ASP.net"} The last two steps of the implementation will have us making sure that only authenticated users can access the controller's POST method, and setting up CORS access. Ensuring only authenticated users are allowed to access the POST method of the controller is very simple. The [Authorize] attribute will be used to make sure that all requests are authenticated before the action method code will be executed: // POST api/echocors [HttpPost] [Authorize] [EnableCors("AllowSpecificOrigin")] public IEnumerable<string> Post([FromBody]TextMessage eMessage) { //return back a JsonResult to echo the text return new string[] { "Echo back:" + eMessage.EchoText }; } By default, and for security purposes, Javascript on a page can only formulate and send requests back to the server the page was loaded from. Since the front end site page was loaded from https://corerazor it should not be able to send requests to another server called https://corewebapi . To allow this to happen, we need to setup CORS – Cross Origin Requests. This is explained in the following tutorial: https://docs.microsoft.com/en-us/aspnet/core/security/cors . I will outline the steps, and also explain some of the extras we need to do in our project. The first thing is to install the ASP.net Cors Nuget package. A simple command in the Nuget Package manager console for our solution will help us achieve this: Install-Package Microsoft.AspNetCore.Cors This command will bring in the Nuget package and make sure that all dependencies are in place to start working with CORS. Once the package is installed, it has to be enabled. There are OWIN services are to be configured in the project's startup.cs class in the ConfigureService method. Let's start with the services configuration: public void ConfigureServices(IServiceCollection services) { services.AddCors(options => { options.AddPolicy("AllowSpecificOrigin", builder => { builder.WithOrigins("https://dev-web17:81", "https://corerazor"); builder.AllowCredentials(); builder.AllowAnyHeader(); builder.AllowAnyMethod(); }); }); services.AddMvc(); } Using the AddCors extension method, and the options pattern, we will add the Cors service before the MVC service. There are several important options we want to pass to this method. The first indicates that we will be creating a policy object called 'AllowSpecificOrigin'. Inside the policy object, we use the options pattern again to setup the parameters for this policy. We indicate the urls that we want to accept requests from – here I am adding a local url (https://dev-web17:81) and the production url (https://corerazor ). We then need to specify that we are allowing CORS requests to send credentials using the AllowCredentials extension method. We also want to specify that we accept all http headers using the AllowAnyHeader extension method. And finally, we indicate that we allow all kinds of HTTP vers (GET, POST, etc) by using the AllowAnyMethod extension method. Once the CORS access policy is declared in the Startup.cs class of the project, we can augment the controller action method with an attribute which will apply the policy we have defined at the previous step. The action method code is augmented with the EnableCors attribute, which takes as an argument, the name of the policy we created when setting up the CORS service: // POST api/echocors [HttpPost] [Authorize] [EnableCors("AllowSpecificOrigin")] public IEnumerable<string> Post([FromBody]TextMessage eMessage) { //return back a JsonResult to echo the text return new string[] { "Echo back:" + eMessage.EchoText }; } With this last modification, the project is complete and we can proceed with IIS publishing just like the front-end project. You can refer back to the front-end tutorial for publishing ASP.net Core projects to IIS: https://docs.microsoft.com/en-us/aspnet/core/publishing/iis?tabs=aspnetcore2x . Proceed to the next article in the series -> By Paul Cociuba https://linqto.me/about/pcociuba