One of my little projects is a static website running on Azure CDN, with a custom domain endpoint enforcing HTTPS traffic only. This caused a little issue when attempting to reach the URL via http, as my sister-in-law kept doing. Now when I set this up, I assumed that any HTTP requests would redirect to the HTTPS equivalent. Obviously, I was wrong. Azure CDN has a rules engine that allows you to redirect traffic, this can be used to replace all HTTP traffic to HTTPS.

Recently, we came across the following issue when attempting to sign a VSTO Add-In with a code-signing certificate: An error occurred while signing: Unknown error “-2147012865” Any search of the error message brought up related answers but not ones specific to this particular error number. Although I can’t be sure of the error number, I believe I had seen this before when we were having network troubles and the timestamp server couldn’t be reached.

Recently I was attempting to code up some Blue/Green deployments of some Azure Functions, and place them behind a Traffic manager. This all worked well for the hostname provided on the Traffic Manager, but not when setting up a custom domain. The way a traffic manager works is a DNS forwarder, so when setting up DNS for a custom domain you need set up a CNAME for your custom domain to the hostname of the traffic manager, but there is no custom domain set up on the Traffic Manager itself.

TL;DR - Send an anonymous OPTIONS call to your SharePoint Online tenant domain and read the response + headers. Out of the box, SharePoint Online allows someone to authenticate through either the older claims-based authentication, or the newer modern authentication. Claims uses Microsoft Online as a Security Token Service and will provide a token with all the user’s access rights; Modern uses the Active Directory Authentication Libraries (ADAL) and OAuth 2.

When Azure Front Door was first released, it allowed you to have one backend host route to a multitude of different services based on the routing path. For example, api.carbonpapersales.com/customers could route to a bunch of app services running in .NET dealing with customer data, and api.carbonpapersales.com/products could point to app services running in node dealing with product data. This is a simple diagram, but you get the idea. But what if the URL path was not enough, and you wanted to route based on stuff in the headers?

In my Azure Pipelines I use the File Copy task to copy static files to an Azure blob container, and while upgrading these tasks to the new v4, I came across the following authentication issue: Authentication failed, it is either not correct, or expired, or does not have the correct permission (ServiceCode=AuthorizationPermissionMismatch) The documentation on this is not very helpful, and took me way too long to piece together all the bits I needed to know.