DEV Community: Clemens Schotte

Help customers find your business with the Azure Maps Store Locator

Clemens Schotte — Mon, 03 Jun 2024 14:23:50 +0000

Maximize Visibility

In today's digital age, the visibility of your business is paramount. Once you've captured customer interest online, the next crucial step is guiding them to your physical storefronts. Azure Maps Store Locator streamlines this journey, offering an interactive and intuitive experience that leads customers right to your doorstep.

Simplifying Store Discovery

Creating a basic store locator using Azure Maps is already a straightforward task, involving the loading of store locations onto a map and potentially setting up a simple search functionality. However, for larger organizations managing thousands of locations and requiring advanced filtering options, a more sophisticated solution is essential. Fortunately, the Azure Maps Store Locator, combining the power of various Azure services, caters precisely to these needs.

Enhance Your Locator Experience

Imagine a tool that effortlessly connects potential customers to the nearest branch of your business, tailored to their specific needs. Whether they're searching for a particular service or other points of interest, Azure Maps Store Locator is the user-friendly and adaptable tool you need. It's backed by a comprehensive management system, enabling you to create a rich locator experience.

Feature-Rich Platform

Azure Maps Store Locator boasts a wide array of features to improve your location-based offerings:

Store Locator Backend: Integrates REST APIs and a Store Locator Web Control for seamless management.
Autocomplete Search: Quickly find store names, addresses, POIs, or zip codes.
Scalability: Manages over 10,000 locations without a hitch.
Proximity Insights: View nearby stores and distance metrics.
Location-Based Search: Searches can be performed based on the user's current location.
Travel Time Estimates: Provides estimated travel times for various modes of transport.
Comprehensive Store Details: Access store information, directions, and more through interactive popups.
Dynamic Filtering: Users can filter stores based on specific features.
Individual Store Pages: Delve into what each store offers with detailed embedded maps.
Security: Employs Microsoft Entra ID for secure access to the location management system.
Rich Data: Store details include location, hours, photos, and the option to add custom features.
Accessibility: Features speech recognition and other accessibility enhancements.
Effortless Deployment: Easily deploy within your Azure ecosystem.

Quick Setup Guide

Deploying Azure Maps Store Locator is straightforward:

Azure Subscription: Confirm you have an Azure subscription. If not, obtain one for free at the official Azure website.
Azure Shell Access: Sign in to Azure Shell. https://shell.azure.com/
Deployment: Run the provided PowerShell script to install the Azure Maps Store Locator.

iex (iwr "https://samples.azuremaps.com/storelocator/deploy.ps1").Content

Integrating the store locator into your website requires some HTML and JavaScript to call the store locator backend REST APIs. Once implemented, the solution is yours to modify and tailor the source code in your Azure Maps Store Locator according to your specific needs.

The Azure Maps Store Locator empowers you to create and maintain an intuitive location-based search experience to delight your customers. Enhance your online presence today with the power of Azure Maps!

You find the Azure Maps Store Locator source code on GitHub.

Protecting and Hiding your Bing Maps Key

Clemens Schotte — Tue, 05 Apr 2022 12:48:20 +0000

Introduction

When using Bing Maps for Enterprise in your solution/application, you need a Basic Key (limited free trial) or an Enterprise key to use the services. For example, you would add a Bing Maps Key to the script URL loading the Bing Maps Web Control like this:

<script src="https://www.bing.com/api/maps/mapcontrol?callback=GetMap&key={your bing maps key}"></script>

Now your key is open text on your site source code and people who look can find and use your key. Search engines will index your page and, as a result, will also store your key. Is this a problem? Not really.

Protecting

The Bing Maps key is mainly used to determine the usage and allow access to Bing Maps features. To protect your Bing Maps key, so it can't be misused on other websites, there is an option in the Bing Maps Dev Center to protect your key. This security option allows you to specify a list of referrers (website URLs) and IP numbers who can use your key. When at least one referrer rule is active, any requests that omit a referrer and any requests from non-approved referrers will be blocked, preventing others from using your key for requests. You can have up to 300 referrer and IP security rules per key.

Your key is now protected but is still visible in your website code. So how do I hide my Bing Maps key?

A best practice is never to store any keys or certificates in source code.

Hiding

To hide the Bing Maps key, you create a simple API endpoint that will only return the Bing Maps key if the request comes from a trusted referral URL. The Bing Maps Samples site is a good example that uses this approach.

In this example we are using an Anonymous HttpTrigger Azure Function written in C# that returns the Bing Maps key:

public static class GetBingMapsKey
{
    private static readonly string[] allowd = { "https://samples.bingmapsportal.com/",
                                                "http://localhost"};

    [FunctionName("GetBingMapsKey")]
    public static IActionResult Run([HttpTrigger(AuthorizationLevel.Anonymous, "get", Route = null)] HttpRequest req)
    {
        string referer = req.Headers["Referer"];
        if (string.IsNullOrEmpty(referer))
            return new UnauthorizedResult();

        string result = Array.Find(allowd, site => referer.StartsWith(site, StringComparison.OrdinalIgnoreCase));
        if (string.IsNullOrEmpty(result))
            return new UnauthorizedResult();

        // Get your Bing Maps key from https://www.bingmapsportal.com/
        string key = Environment.GetEnvironmentVariable("BING_MAPS_SUBSCRIPTION_KEY");

        return new OkObjectResult(key);
    }
}

The Bing Maps key is stored server-side in this Azure Function Application settings field. We are using the GetEnvironmentVariable() to get the key.

Next, we need to load the Bing Maps script and get the key from the API client-side. Finally, we use the following code snippet to load Bing Maps dynamically:

<script>
    // Dynamic load the Bing Maps Key and Script
    // Get your own Bing Maps key at https://www.microsoft.com/maps
    (async () => {
        let script = document.createElement("script");
        let bingKey = await fetch("https://samples.azuremaps.com/api/GetBingMapsKey").then(r => r.text()).then(key => { return key });
        script.setAttribute("src", `https://www.bing.com/api/maps/mapcontrol?callback=GetMap&key=${bingKey}`);
        document.body.appendChild(script);
    })();
</script>

The browser will run this code and create at runtime in the DOM the same line of <script> tag we have seen at the beginning of this blog post to load Bing Maps and the Key. An additional advantage is that the Bing Maps key is not stored in the source code anymore and that you can use IaC and build pipelines to deploy the solution.

Note: Only hiding the Bing Maps key alone is not enough as a security measure. We recommend you still enable the security option in the Bing Maps Dev Center!

Use Azure Maps to calculate an isochrone to reach your customers

Clemens Schotte — Tue, 21 Sep 2021 14:28:31 +0000

Imagine you are a store owner and would like to target customers that live within a 15-minute drive from your store with advertising for your weekly specials. You could draw a circle on a map, guessing that is about 15 minutes away, but it will not truly represent the time it will take for customers to get to your store. For example, a customer living near a major transit route can live further away from the store than a customer living in a less well-served part of the city. To meet this need, an isochrone is a polygon (an area on a map) of expected travel time. It represents the locations that will take the specified time, or less, it will take to get to a specific point (your store, in this case). Estimating an isochrone correctly, including all the variables like traffic, road, and vehicle conditions, is very hard to do by yourself!

Azure Maps Get Route Range

Using the Get Route Range API from Azure Maps makes it very easy to calculate the isochrone. For our store example, we need to calculate a 15-minute isochrone for every store we have. We only need the coordinates (longitude and latitude) from our stores and the drivetime in seconds (15 x 60 = 900 sec).

GET https://atlas.microsoft.com/route/range/json?subscription-key=[subscription-key]&api-version=1.0&query=47.65431,-122.1291891&timeBudgetInSec=900

Search Customer Address

To determine which customer is living inside the 15-minute drive isochrone, we first need the coordinates for every customer's address. Then, we simply loop through all our customers and use the Get Search Address API to get the coordinates.

GET https://atlas.microsoft.com/search/address/json?subscription-key=[subscription-key]&api-version=1.0&query=15127 NE 24th Street, Redmond, WA 98052

Point In Polygon

The last step is to check if a customer coordinate is inside one of our store isochrones. We use the Point In Polygon API to determine if this is true.

POST https://atlas.microsoft.com/spatial/pointInPolygon/json?subscription-key=[subscription-key]&api-version=1.0&lat=33.5362475&lon=-111.9267386

And the request body (the store isochrone)

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "properties": {
        "geometryId": 1001
      },
      "geometry": {
        "type": "Polygon",
        "coordinates": [
          [
            [
              -111.9267386,
              33.5362475
            ],
            [
              -111.9627875,
              33.5104882
            ],
            [
              -111.9027061,
              33.5004686
            ],
            [
              -111.9267386,
              33.5362475
            ]
          ]
        ]
      }
    }
  ]
}

We now can target those customers with store-specific offers and promotions.

Examples

What schools are within a 20-minute walk from my home? What available jobs are within a 30-minute transit commute? Where you are located and what is near you brings context to the choice of where you want to live and Azure Maps Isochrone API can help you bring that location intelligence into your applications.

Azure DevOps Dashboard

Clemens Schotte — Wed, 16 Jun 2021 09:17:15 +0000

Introduction

When you are managing Azure DevOps in a large enterprise organization, and you are still using only one Azure DevOps organization account, you are probably hitting some limits or have potential performance issues. Microsoft's recommendation is to have around 300 projects in a single Azure DevOps organization account. I have seen Azure DevOps organizations with more than 600 projects that still work.

The solution is to set up a multi-organization structure. Move all the inactive projects to an archive or boneyard Azure DevOps organization account and add an extra Azure DevOps organization account per department.

Next, you need some insights and automation on which projects have no activity anymore. The Azure DevOps Dashboard gives you the basic insights and an API to automate tasks like emailing the owners of inactive projects.

Azure DevOps Dashboard

This dashboard solution generates a simple overview of all the Azure DevOps projects in your organization and calculates the last known activity in days on commits, work items, and the project itself. You can connect this dashboard (using the included endpoint) to Microsoft Power Automate or Excel to automate tasks on project level.

Installation

The solution runs on as a single Azure Web App, it uses a background WebJob to collect all the data needed to present in the web dashboard.

Prerequisites

An Azure account with an active subscription. Create an account for free.
Install the Azure CLI on Windows to automate the following steps
An Azure DevOps personal access token (PAT). See here how to get a personal access token.
Download the Azure DevOps Dashboard Release.zip package.

Create an Azure Web App

In the next steps, you will create a resource group, an app service plan (the webserver), and the Web App (the solution itself). We also add two application settings to store the Azure DevOps personal access token.

az login

(Optional) Select the subscription where you like to deploy the dashboard.

az account set --subscription "<your subscription>"

Create a resource group, change the name rg-azdevops

az group create -l westeurope -n rg-azdevops

Create an app service plan and webapp, change the names plan-azdevops and azdevops

az appservice plan create -g rg-azdevops -n plan-azdevops -l westeurope

az webapp create -g rg-azdevops -p plan-azdevops -n azdevops -r "DOTNET|6.0"

Add your Azure DevOps URL and personal access token (PAT)

az webapp config appsettings set -g rg-azdevops -n azdevops --settings azDevOpsPat=<your token>
az webapp config appsettings set -g rg-azdevops -n azdevops --settings azDevOpsUri=https://dev.azure.com/<yourorgname>

Set the always-on future we need for the WebJob

az webapp config set -g rg-azdevops -n azdevops --always-on true

Deploy the Azure DevOps Dashboard

Did you download the Azure DevOps Dashboard Release.zip package? After the installation we also run the WebJob for the first time, this can take a while depending on how many projects you have in your Azure DevOps organization account.

Authentication In the release package authentication is disabled! Please register your application first in your Azure Active Directory by following the steps described here. You only need to update the appsettings.json inside the release package.

az webapp deployment source config-zip -g rg-azdevops -n azdevops --src Release.zip

az webapp webjob triggered run -n azdevops -g rg-azdevops --webjob-name Webjob

Architecture

You can also run the WebJob locally, set the following two environment variable first azDevOpsUri
and azDevOpsPat that corresponds with your Azure DevOps organization account:

SET azDevOpsPat=tjqp44k54nqfmppaqd7di27kpvh...........
SET azDevOpsUri=https://dev.azure.com/yourorgname.....

Using the API

To automate tasks, you can use the API to connect to Excel, Microsoft Power Automate, or whatever you need. The /api/data API will return a list of the following project properties:

[
    {
        "projectId": "guid",
        "name": "project name",
        "description": "project description",
        "url": "https://dev.azure.com/projectname",
        "owners": [
            {
                "displayName": "Contoso Admin name",
                "mailAddress": "admin@contoso.com"
            }
        ],
        "processTemplate": "Scrum",
        "lastProjectUpdateTime": "2021-03-22T11:40:32.09Z",
        "lastCommitDate": "2020-04-23T18:00:27Z",
        "lastWorkItemDate": "0001-01-01T00:00:00",
        "lastKnownActivity": "2021-03-22T11:40:32.09Z",
        "projectAge": 83.92575148777316
    }
]

Source Code

Alle source code can be found on GitHub.

Do I get wet feet? Draw a flood map using Azure Maps Elevation API

Clemens Schotte — Mon, 14 Jun 2021 21:12:51 +0000

Introduction

When you are living in the Netherlands you are used to that, nearly 26% of its land falling below sea level, and about 50% is just only exceeding 1 m (3.3 ft) above. The Dutch people have lived many centuries battling the water, not only from the sea but also from her rivers. To protect the land the Dutch have built many sophisticated protecting- and management systems to handle the water, like the Delta Works. Building only a dike or dam is not enough. Today we have won, but we know that we cannot rust, climate change (heavy rain showers) and sea levels are rising globally. Do we (or you) get wet feet in the future?

To start, we need to know which areas of land are almost below sea level so that we can plan and take additional actions. To make this visible we can use Azure Maps and use the Azure Maps Elevation Service to make a basic flood map. The Azure Maps Elevation Service provides pole-to-pole coverage with <4M absolute and <2m relative accuracy. The elevation data represents a digital terrain model (DTM), man-made entities (e.g., buildings) are artificially flattened, and elevation is measured to the ground surface.

What do we need?

To get started you need a free Azure subscription and an Azure Maps account. This provides us access to the Elevation API that we need to build the flood map. The Elevation API gives elevation back in meters for coordinates, with WGS84 longitude and latitude, on a map. We can use a Bounding Box, Points, and a Polyline as input. In the below picture you see an aerial photo of the harbor and city of Rotterdam. The flood map shows in blue all the land that is below sea level and is vulnerable, and in green land that is high enough.

Azure Maps

We only need a single HTML file, that references the Azure Maps Maps Control, Map Drawing Tools libraries, and some basic HTML and JavaScript.

<!-- Add references to the Azure Maps Map control JavaScript and CSS files. -->
<link rel="stylesheet" href="https://atlas.microsoft.com/sdk/javascript/mapcontrol/2/atlas.min.css"/>
<script src="https://atlas.microsoft.com/sdk/javascript/mapcontrol/2/atlas.min.js"></script>

<!-- Add references to the Azure Maps Map Drawing Tools JavaScript and CSS files. -->
<link rel="stylesheet" href="https://atlas.microsoft.com/sdk/javascript/drawing/0/atlas-drawing.min.css" />
<script src="https://atlas.microsoft.com/sdk/javascript/drawing/0/atlas-drawing.min.js"></script>

We need to initialize the map control and add additional layers to it to draw on, like the controls and the floodmap itself. First we initialize the map control:

// Initialize a map instance.
map = new atlas.Map('myMap', {
    center: [4.2432838, 51.9022471], // City of Rotterdam
    zoom: 12,
    style: 'satellite',
    view: 'Auto',

    // Add authentication details for connecting to Azure Maps.
    authOptions: {
        authType: 'subscriptionKey',
        subscriptionKey: '<your key>'
    }
});

Draw a flood map

Now that we have the basics we need only add a BubbleLayer layer to the map, which we need to draw the floodmap with.

// Create a layer for rendering the elevation points.
layer = new atlas.layer.BubbleLayer(datasource, null, {
    color: [
        'interpolate',
        ['linear'],
        ['get', 'elevation'],
        400, '#006837',
        450, '#1a9850',
        500, '#66bd63',
        550, '#a6d96a',
        600, '#d9ef8b',
        650, '#ffffbf',
        700, '#fee08b',
        750, '#fdae61',
        800, '#f46d43',
        850, '#d73027',
        900, '#a50026'
    ],

    // Don't outline the bubbles.
    // This will make them blend together to create a heat map like visual.
    strokeWidth: 0
});
map.layers.add(layer);

The DrawingManager we not only use to draw the Bounding Box, but it gives us also the coordinates back we need for the Elevation API.

The Get Data for Bounding Box API provides elevation data at equally spaced locations within a bounding box. A bounding box is defined by the coordinates for two corners (southwest, northeast) and then subsequently divided into rows and columns.

Elevations are returned for the vertices of the grid created by the rows and columns. Up to 2,000 elevations can be returned in a single request. The returned elevation values are ordered, starting at the southwest corner, and then proceeding west to east along the row. At the end of the row, it moves north to the next row, and repeats the process until it reaches the far northeast corner.

var elevationBoundsUrl = 'https://{azMapsDomain}/elevation/lattice/json?api-version=1.0&bounds={bounds}&rows={rows}&columns={columns}';

var url = elevationBoundsUrl.replace('{bounds}', bounds).replace('{rows}', numRows).replace('{columns}', numColumns);

url = url.replace('{azMapsDomain}', atlas.getDomain());

processRequest(url).then(response => {
if (response.error) {
    alert(response.error.message);
    return;
}

var points = [];

// Loop through the elevations, create point features with an elevation property.
response.data.forEach(c => {
    points.push(new atlas.data.Feature(new atlas.data.Point([c.coordinate.longitude, c.coordinate.latitude]), {
        elevation: c.elevationInMeter
    }));

    // ...

Now we only need to overwrite the points to the data source, and we have a flood / elevation map.

datasource.setShapes(points);

Example code

This Code Sample shows how to get elevations in a grid pattern with a bounding box. Try it out!

Create your own indoor maps using Azure Maps Creator

Clemens Schotte — Tue, 08 Jun 2021 06:36:23 +0000

Introduction

When you are working inside a building, like an office, factory, shopping mall, or something like a museum. There are probably a lot of sensors that can tell you information about that building, like what is the temperature and air quality per room, is there any door open or is there some alarm happening. When you in a big building and you want to know the fastest route to a specific room/store/painting, you probably apricate some help in navigating. These are all smart buildings.

Using indoor maps will not only help you visualize the building/floorplans and its IoT sensors, but also interact and navigate with it. For example, when you are for the first time in the Louvre Museum and want to know how to get to the famous Mona Lisa painting, you can use an interactive indoor map to find and navigate to what you were searching for.

By using the same technology for mapping outdoors we can use Azure Maps also for indoor mapping solutions. Azure Maps is a collection of geospatial services APIs and SDKs that use fresh mapping data to provide geographic context to web and mobile applications. Azure Maps Creator is the service that facilitates the creation of indoor maps using your own building drawings. Azure Maps has SDKs for Web, Android, and iOS (is coming), and is available in Power BI.

Azure Maps Creator

To get started using the Azure Maps Creator services, you first need a free Azure subscription and an Azure Maps account. To use the Creator services, Azure Maps Creator must be created in an Azure Maps account. For information about how to create Azure Maps Creator in Azure Maps, see Manage Azure Maps Creator.

After you have created an Azure Maps account you get two options to authenticate to the Azure Maps services; a subscription API key or by using Azure Active Directory (what is a more secure way). The API key you use in the API calls. Currently, there are two endpoint regions: Europe, and the United States.

Second, you need to have or create your own CAD drawings from your building like floorplans in the .DWG file format (AutoCAD DWG file format version AC1032). These drawings need then be packaged into a simple .ZIP file including a manifest.json file that describes the Drawing package. See for more information, the Conversion Drawing package guide. This step is very important, creating and preparing your floorplans including all the interactive elements that make your solution stand out or not.

The process after the drawing package creation is very straightforward. You upload the drawing package using the Data Upload API, convert it using the Conversion API, and create a dataset and tileset using the Dataset API and Tileset API. See this tutorial on how to do this step by step: Use Creator to create indoor maps.

Dataset is a collection of indoor map features.
Tileset is a collection of vector data that represents a set of uniform grid tiles.
Feature statesets are collections of dynamic properties (states) that are assigned to dataset features, such as rooms or equipment.

Rendering the indoor map

The Azure Maps Web SDK includes the Indoor Maps module. This module offers extended functionalities to the Azure Maps Map Control library. The Indoor Maps module renders indoor maps created in Creator. It integrates widgets, such as floor picker, that help users visualize the different floors. The Indoor Maps module also supports dynamic map styling. For a step-by-step walkthrough to implement feature stateset dynamic styling in an application, see Use the Indoor Map module.

If you like to see what more is possible with the Azure Maps Web Control, there is a sample gallery with a collection of 270 code samples. See the Azure Maps Web SDK Samples.

Protect your web applications using Azure Application Gateway

Clemens Schotte — Tue, 06 Apr 2021 15:14:16 +0000

What is Azure Application Gateway?

Azure Application Gateway is a reverse proxy with optional WAF (Web Application Firewall) capability to allow incoming connections from external sources. The Gateway operates at Layer 3, 4, and 7 for IP-based, TCP/UDP-based, URL-based, and Host Header-based routing.

When to use the Application Gateway?

Microsoft has multiple services to protect and accelerate your applications; they are used for different scenarios, depending on where your users are:

Azure Traffic Manager – DNS based load balancer across global regions
- https://navatron.com
- https://us.navatron.com
- https://eu.navatron.com
Azure Application Gateway – Single region, URL-based routing at the application
- https://eu.navatron.com
- https://eu.navatron.com/products
- https://eu.navatron.com/support
- https://eu.navatron.com/jobs
Azure Front Door – Global load balancing with SSL offloading
- IPv6
- Application acceleration

Global Route clients to the closest available service region. Offload SSL and accelerate websites at the network edge.
Regional / Internal Route across zones and into your VNET. Private IP space routing and between your resources to build your regional application.

Application Gateway Capabilities

The v2 SKU has several enhancements which do not exist within the v1 SKU, allowing for additional capabilities.

see also:

Feature comparison between v1 SKU and v2 SKU

Scalability

Application Gateway or WAF deployments under Standard v2 or WAF v2 SKU support autoscaling and can scale up or down based on changing traffic load patterns. Autoscaling (up to 125 instances) also removes the requirement to choose a deployment size or instance count during provisioning. Application Gateway can operate both in fixed capacity (autoscaling disabled) and in autoscaling enabled mode. The v2 SKU offers performance enhancements and adds support for critical new features like autoscaling, zone redundancy, and support for static VIPs.

Zone Redundancy

An Application Gateway or WAF deployment can span multiple Availability Zones, removing the need to provision separate Application Gateway instances in each zone with a Traffic Manager. You can choose a single zone or multiple zones where Application Gateway instances are deployed, making it more resilient to zone failure. The back-end pool for applications can be similarly distributed across availability zones.

Static VIP

The v1 SKU did not support a Static VIP and was only accessible via the configured URL. The v2 URL is only configurable with a Static VIP and will not change through reboots.

AKS Ingress Controller

The Application Gateway Ingress Controller allows Azure Application Gateway to be used as the ingress for an Azure Kubernetes Service (AKS) cluster. The ingress controller runs as a pod within the AKS cluster. It consumes Kubernetes Ingress Resources and converts them to an Azure Application Gateway configuration, allowing the Gateway to load-balance traffic to Kubernetes pods.

Key Vault Integration

Application Gateway v2 supports integration with Key Vault for server certificates that are attached to HTTPS-enabled listeners. You can either attach the certificate directly to the Application Gateway or provide a reference to an existing Key Vault certificate or secret when you create an HTTPS-enabled listener.

Integration includes many benefits such as:

More robust security because the application development team doesn't directly handle SSL certificates. This integration allows a separate security team to:
- Set up Application Gateways.
- Control Application Gateway lifecycles.
- Grant permissions to selected Application Gateways to access certificates that are stored in your Key Vault.
Support for importing existing certificates into your key Vault. Or use Key Vault APIs to create and manage new certificates with any of the trusted Key Vault partners.
Support for automatic renewal of certificates that are stored in your Key Vault.

Application Gateway currently supports software-validated certificates only. Hardware security module (HSM)-validated certificates are not supported. After Application Gateway is configured to use Key Vault certificates, its instances retrieve the certificate from Key Vault and install them locally for SSL termination. The instances also poll Key Vault at 24-hour intervals to retrieve a renewed version of the certificate if it exists. If an updated certificate is found, the SSL certificate currently associated with the HTTPS listener is automatically rotated.

Rewriting HTTP/HTTPS Headers

HTTP headers allow a client and server to pass additional information with a request or response. By rewriting these headers, you can accomplish important tasks, such as adding security-related header fields like HSTS/ X-XSS-Protection, removing response header fields that might reveal sensitive information, and removing port information from X-Forwarded-For headers.

Application Gateway allows you to add, remove, or update HTTP request and response headers while the request and response packets move between the client and backend pools. And it allows you to add conditions to ensure that the specified headers are rewritten only when certain conditions are met.

Application Gateway also supports several server variables that help you store additional information about requests and responses. This makes it easier for you to create powerful rewrite rules.

All headers in requests and responses can be modified, except for the Host, Connection, and Upgrade headers.

Socket Routing

Web Application Gateway can make routing decisions based on the IP, and Port (Socket) requests. This allows for one Application Gateway to front-end multiple applications.

URL Routing

URL Path-Based Routing allows you to route traffic to backend server pools based on the request's URL Paths. One of the scenarios is to route requests for different content types to another pool. For example, requests for https://navatron.com/video/* are routed to VideoServerPool, and https://navatron.com/images/* are routed to ImageServerPool. DefaultServerPool is not sent any traffic in this example.

Rules are processed in the order they are listed in the portal. It is highly recommended to configure multi-site listeners first prior to configuring a basic listener. This ensures that traffic gets routed to the proper back end. If a basic listener is listed first and matches an incoming request, it gets processed by that listener.

Multiple-Site Hosting

Multiple-site hosting enables you to configure more than one website on the same Application Gateway instance. This feature allows you to configure a more efficient topology for your deployments by adding up to 100 websites to one application gateway. Each website can be directed to its own pool. For example, Application Gateway can serve traffic for navatron.com and navatron.nl from two server pools called MainServerPool and DutchServerPool.

Similarly, two subdomains of the same parent domain can be hosted on the same application gateway deployment. Examples of using subdomains could include https://blog.navatron.com and https://api.navatron.com hosted on a single Application Gateway deployment.

Redirection

Often, Web servers will contain pools specifically for web redirection from HTTP to HTTPS. Application Gateway can handle this scenario natively, simplifying configs and freeing up resources on the web servers themselves. This is a generic redirection mechanism to redirect from and to any port you define using rules. It also supports redirection to an external site as well.

Optional WAF

Web application firewall (WAF) is a feature of Application Gateway that provides centralized protection of web applications from common exploits and vulnerabilities. WAF is based on rules from the OWASP (Open Web Application Security Project) core rule sets 3.0 or 2.2.9.

Web applications are increasingly targeted for malicious attacks that exploit commonly known vulnerabilities. Preventing such attacks in application code can be challenging and may require rigorous maintenance, patching, and monitoring at many application topology layers. A centralized web application firewall helps make security management much more straightforward and reassures application administrators against threats or intrusions. A WAF solution can also react to a security threat faster by patching a known vulnerability at a central location versus securing each of individual web applications. Existing application gateways can be converted to a web application firewall-enabled application gateway easily.

Application Gateway WAF protects against:

SQL-injection
Cross-site scripting
Other common web attacks, such as command injection, HTTP request smuggling, HTTP response splitting, and remote file inclusion
HTTP protocol violations
HTTP protocol anomalies, such as missing host user-agent and accept headers
Bots, crawlers, and scanners
Common application misconfigurations (for example, Apache and IIS) through detection

These WAF Features can be enabled in monitoring/learning mode or in enforcing mode. All the findings can be reviewed via various monitoring configurations like Azure Monitor, Azure Security Center, or Azure Diagnostics Logs.

End-to-End SSL

When SSL Encryption must be maintained, Application Gateway can be configured for End-to-End SSL. In this process, the Application Gateway will decrypt the traffic, review and evaluate based on configured policies, modify the headers as configured, and then re-encrypt traffic before sending it to the back-end servers.

see also:

Overview of TLS termination and end to end TLS with Application Gateway

SSL Termination

Application gateway supports SSL/TLS termination at the Gateway, after which traffic typically flows unencrypted to the back-end servers. This feature allows web servers to be unburdened from costly encryption and decryption overhead.

see also:

TLS termination with Key Vault certificates

Session Affinity

The cookie-based session affinity feature is useful when you want to keep a user session on the same server. The Application Gateway can direct subsequent traffic from a user session to the same server for processing by using gateway-managed cookies. This is important in cases where the session state is saved locally on the server for a user session.

Custom Error Pages

Application Gateway allows for the creation of custom error pages instead of displaying the default error pages. Custom branding and layout can be used within a custom error page.

For example, a custom maintenance page can be displayed if the application isn't reachable or an unauthorized access page if a malicious request is sent to a web application. These custom error pages can replace HTTP 502 and 403 return codes.

If an error originates from the back-end servers, then it's passed along unmodified back to the caller. A custom error page isn't displayed. Application Gateway can display a custom error page when a request can't reach the back-end.

WebSocket Support

Application Gateway provides native support for the WebSocket protocol. There is no user-configurable setting to selectively enable or disable WebSocket support. The WebSocket protocol enables full-duplex communication between a server and a client over a long-running TCP connection.

HTTP/2 Support

Application Gateway provides native support for the HTTP/2 protocol. The HTTP/2 protocol enables full-duplex communication between a server and a client over a long-running TCP connection. This allows for a more interactive communication between the web server and the client, which can be bidirectional without the need for polling as required in HTTP-based implementations. These protocols have low overhead, unlike HTTP, and can reuse the same TCP connection for multiple requests/responses, resulting in a more efficient resource utilization. These protocols are designed to work over traditional HTTP ports of 80 and 443.

Connection Draining

Connection draining helps you achieve graceful removal of back-end pool members during planned service updates. This setting is enabled via the back-end HTTP setting and can be applied to all back-end pool members during rule creation. Once enabled, Application Gateway ensures all de-registering instances of a back-end pool do not receive any new requests while allowing existing requests to complete within a configured time limit. This applies to both back-end instances that are explicitly removed from the back-end pool by an API call, and back-end instances reported as unhealthy as determined by the health probes.

Health Probes

Azure Application Gateway, by default, monitors the health of all resources in its back-end pool and automatically removes any resource considered unhealthy from the pool. Application Gateway continues to monitor the unhealthy instances and adds them back to the healthy back-end pool once they become available and respond to health probes. Application gateway sends the health probes with the same port that is defined in the back-end HTTP settings. This configuration ensures that the probe is testing the same port that customers would be using to connect to the back-end. In addition to using default health probe monitoring, you can also customize the health probe to suit your application's requirements.

see also:

Application Gateway health monitoring overview

Networking

Azure Application Gateways are always deployed in a virtual network subnet. This subnet can only contain Application Gateways. Although this is an entirely managed service, behind the scenes, Azure is deploying one or more instances of load-balanced virtual appliances into your VNet.

Application Gateway can talk to instances outside of the virtual network as long as there is IP connectivity.
Network Security Groups are supported on the Application Gateway subnet to provide segmentation/isolation.
Front-End IPs on an Application Gateway can be either public or private depending on requirements.

Free and Built-In TLS/SSL certificates in Azure

Clemens Schotte — Sat, 03 Apr 2021 17:17:30 +0000

Today, when a website does not have an SSL/TSL certificate, web browsers give you a warning not secure. This warning not only scares people but also gives you a disadvantage in search engine ranking. On Azure, web sites have a default https-enabled URL, like https://sitename.azurewebsites.net/, but when you have a vanity domain configured, you are missing this secure connection. Luckily there are some free SSL/TLS certificate options to explore.

Let's Encrypt

Wait, there is Let's Encrypt, its free! Why are you not using this excellent service? Yes, that is true, but there are some downsides to use Let's Encrypt (on Azure), like:

You need an Azure Web App Site Extension to enable and renew certificates, like this one from Simon J.K. Pedersen.
Let's Encrypt does not have any official support or SLA model.
It's complex to implement correctly for all the Azure services you need.
Let's Encrypt only validates the domain name. There are no further validations like other CAs, and certificates are misused for phishing attacks.

Azure Built-In free certificates

It should be easy and free to enable SSL/TSL certificates in Azure. This was the number one question on UserVoice feedback. Microsoft implemented this Built-In free certificate option for some services, like Azure CDN, Front Door, Application Gateway, etc. When you put one of those services in front of your web site (like what I did with this blog), you can enable an auto-renewable Built-In certificate for free.

"Custom Domain HTTPS feature enables you to deliver content to your users securely over your own domain. This is done by encrypting the data between the CDN and your users' clients (typically web browsers) via TLS protocol (which is a successor of the SSL protocol) using a certificate. Using our "CDN managed certificate" capability, you can enable this feature with just a few clicks and have Azure CDN completely take care of certificate management tasks such as its renewal. You can also bring your own certificate (stored in Azure Key vault ) or even purchase a new certificate through Key vault and have Azure CDN use that certificate for securing the content delivery."

Use your own certificate

There is also an option to use your own certificate, especially when you need a naked domain (without the "www"-prefix). This is not currently possible with the Build-In certificate option. See "Hosting a Static Site on Azure using CDN and HTTPS" how to fix this.

Infrastructure as Code

Clemens Schotte — Tue, 30 Mar 2021 19:16:36 +0000

Infrastructure as Code

Infrastructure as Code (IaC) is the process of managing and provisioning infrastructure and configuration dependencies for application stacks using machine-readable definition files rather than physical hardware configuration or interactive configuration tools.

What is Infrastructure as Code?

Source Controlled
In code (Scripts & Templates)
Automated & Continuous Deployment
Testing
Feedback loop (Monitoring)

Categories of IaC tooling

You can use many declarative infrastructure deployment technologies with Azure. These fall into two main categories.

Imperative IaC involves writing scripts in a language like Bash, PowerShell, C# script files, or Python. These programmatically execute a series of steps to create or modify your resources. When using imperative deployments, it is up to you to manage things like dependency sequencing, error control, and resource updates.
Declarative IaC involves writing a definition of how you want your environment to look; the tooling then figures out how to make this happen by inspecting your current state, comparing it to the target state you've requested, and applying the differences.

Terraform

Hashicorp Terraform is an open-source tool for provisioning and managing cloud infrastructure. It codifies infrastructure in configuration files that describe the topology of cloud resources. These resources include virtual machines, storage accounts, and networking interfaces. The Terraform CLI provides a simple mechanism to deploy and version the configuration files to Azure.

Infrastructure as Code with Terraform has become pervasive for provisioning cloud infrastructure. Azure engineering has invested in Terraform AzureRM provider as a first-party control plane, of equal importance to Azure-Cli and PowerShell, for Azure. As companies mature in their use of Terraform, there is an increasing need to apply DevOps practices to their IaC development to increase velocity and reduce Mean-Time-To-Recover from failures.

See also:

Immutable Infrastructure CI/CD using Jenkins and Terraform on Azure Virtual Architecture.

Challenges

Doing automation around terraform has several key challenges:

How you deploy in production MUST match how you deploy in development and testing?
Testing requires that physical resources be deployed before the test.
State management is challenging in multi-user/multi-team scenarios.
Not a lot of best practices around how to segment/manage remote state & workspaces.

Testing

Terraform enables the definition, preview, and deployment of cloud infrastructure. Using Terraform, you create configuration files using HCL syntax. The HCL syntax allows you to specify the cloud provider - such as Azure - and the elements that make up your cloud infrastructure. After you create your configuration files, you create an execution plan that allows you to preview your infrastructure changes before they're deployed. Once you verify the changes, you apply the execution plan to deploy the infrastructure.

See also:

Best practices Terraform testing overview.

Automated testing with Terratest. Terratest is a critical component in the toolchain needed for effective terraform development.

Project Lucidity

Project Lucidity allows you to deploy infrastructure to Azure using Terraform easily. It addresses some of the challenges from above:

An opinionated approach to terraform development on Azure using Azure DevOps
Flexible installation script that creates a project with pipelines configured so you can focus on writing terraform and creating test
Minimize fixed design choices while adhering to best practices
- The directory structure for maintaining Terraform modules and deployments.
- Use environment variables stored in .env files instead of .tfvars
- Use Terratest to test your terraform code as an acceptance test
- Secrets should only ever live in KeyVault.

Azure Bicep

Azure Bicep is an abstraction built on top of Azure ARM Templates and Azure Resource Manager that offers a cleaner code syntax with better support for modularity and code reuse. Azure Bicep moves away from the JSON syntax used by ARM Templates and is much easier to read and write Infrastructure as Code (IaC) in Azure.

What is Azure Bicep?

Azure Bicep is a new declarative Domain Specific Language (DSL) for deploying Azure resources. This new language aims to make it easier to write Infrastructure as Code (IaC) targeting Azure Resource Manager (ARM) using a syntax that's more friendly than the JSON syntax of Azure ARM Templates.

Azure Bicep works as an abstraction layer built on top of ARM Templates. Anything that can be done with Azure ARM Templates can be done with Azure Bicep as it provides a "transparent abstraction" over ARM (Azure Resource Manager). With this abstraction, all the types, API versions, and properties valid within ARM Templates are also valid with Azure Bicep.

Azure Bicep is a compiled language. This means that the Azure Bicep code was converted into ARM Template code. Then, the resulting ARM Template code is used to deploy the Azure resources. This enables Azure Bicep to use its syntax and compiler for authoring Azure Bicep files that compile down to Azure Resource Manager (ARM) JSON as a sort of intermediate language (IL).

Security Best Practices for IaC

The security of IaC definitions, deployments, and operational workloads are critically important due to the high level of permissions required to implement an IaC solution effectively. This chapter attempts to outline key best practices that contribute to secure IaC strategies.

Use directory services for authentication

Directory services enable you to safeguard user and system credentials by enforcing strong authentication and conditional access policies. These technologies allow you to manage your identities by ensuring that the right services have the right access to the right resources.

Use directory services, like Azure Active Directory, for authenticating users and services when deploying infrastructure so that Role-Based-Access-Control can be used to apply the principle of least privilege.
When deploying infrastructure, use a dedicated identity so that the blast radius of a leaked credential is scoped as narrowly as possible.
When deploying infrastructure, leverage platform authentication technologies that avoid needing to store a username and password to make it harder for credentials to leak. In practice, this means leveraging Managed Identities or Service Connections in Azure DevOps.
When a username or password must be used based on technology limitations, all sensitive information should be stored in a secret store such as Key Vault and masked in any logging output so that secrets are not leaked during deployments.

Rotate Deployment Credentials

Credential rotation refers to the changing/resetting of a credential(s). Limiting a credential's lifespan reduces the risk from and effectiveness of credential-based attacks and exploits by condensing the window of time during which a stolen credential may be valid.

All secrets required to authenticate to external services (i.e., Azure) should expire on a regular cadence so that any leaked credentials are not valid indefinitely.
Design automated credential rotation from the beginning of a project so that the delivered solution can recover from a security breach quickly.

Apply the principle of least privilege

The principle of least privilege (PoLP), also known as the principle of minimal privilege or the principle of least authority, requires that in a particular abstraction layer of a computing environment, every module (such as a process, a user, or a program, depending on the subject) must be able to access only the information and resources that are necessary for its legitimate purpose. Limiting the access of a computing-environment reduces the risk from and effectiveness of credential-based attacks and exploits by minimizing the blast radius of a leaked credential.

Identities used for infrastructure deployments should have a minimal set of privileges so that a leaked credential has the smallest blast radius possible.
Use separate identities for deploying to each environment (i.e., dev, QA, prod) so that a leaked credential for one of those environments does not grant access to another environment. This also protects against a bug being tested in a dev IaC deployment from unintentionally impacting non-test environments.

Manage secrets securely

Secure secrets management is essential to protect data in the cloud and can be used to store sensitive information like passwords and certificates securely. Managed secret stores often provide the ability to protect sensitive information using strong encryption while avoiding the need to keep secrets in a repository or as a plain text environment variable.

Secrets required for deployments, such as database credentials or private certificates, should be referenced from a secure vault to be stored at rest with encryption and are only accessible via authenticated requests.

Deploy through automated pipelines

CI/CD pipelines are at the core of daily operations for many businesses today. When set up correctly, these processes help keep the delivery process consistent by automating many manual tasks and providing visibility into how the software is being worked on.

Infrastructure deployments to non-development environments should only be done through repeatable processes such as a continuous deployment pipeline so that it is not possible for the deployed environment to drift from the environment as described through IaC templates.

Enforce branch policies and PRs

Branch policies are an essential part of the Git workflow and enable you to: Isolate work in progress from the completed work in your master branch. Guarantee changes build before they get to Main. Limit who can contribute to specific branches.

Changes to IaC should only be deployed to non-development environments after being reviewed by the team and merged into the appropriate branch so that malicious or unintended changes to infrastructure are not deployed into production environments. See Configure Branch Policies in Azure DevOps.

Use gated approvals in automated releases

Approvals and gates give you additional control over the start and completion of the deployment pipeline. Each stage in a release pipeline can be configured with pre-deployment and post-deployment conditions, including waiting for users to manually approve or reject deployments and checking with other automated systems until specific conditions are verified.

Infrastructure deployments should not be deployed into customer-facing environments without the explicit approval of an application operator so that they can monitor the application and its dependencies after the deployment completes. See Release Approvals and Gates Overview.

Azure Blueprints

Just as a blueprint allows an engineer or an architect to sketch a project's design parameters, Azure Blueprints enables cloud architects and central information technology groups to define a repeatable set of Azure resources that implements and adheres to an organization's standards, patterns, and requirements. Azure Blueprints makes it possible for development teams to rapidly build and stand-up new environments with trust they're building within organizational compliance with a set of built-in components, such as networking, to speed up development and delivery.

Blueprints are a declarative way to orchestrate the deployment of various resource templates and other artifacts such as:

Role Assignments
Policy Assignments
Azure Resource Manager templates (ARM templates)
Resource Groups

The Azure Blueprints service is backed by the globally distributed Azure Cosmos DB. Blueprint objects are replicated to multiple Azure regions. This replication provides low latency, high availability, and consistent access to your blueprint objects, regardless of which region Azure Blueprints deploys your resources to.

How it's different from ARM templates

The service is designed to help with environment setup. This setup often consists of a set of resource groups, policies, role assignments, and ARM template deployments. A blueprint is a package to bring each of these artifact types together and allow you to compose and version that package, including through continuous integration and continuous delivery (CI/CD) pipeline. Ultimately, each is assigned to a subscription in a single operation that can be audited and tracked.

Nearly everything that you want to include for deployment in Azure Blueprints can be accomplished with an ARM template. However, an ARM template is a document that doesn't exist natively in Azure – each is stored either locally or in source control. The template gets used for deployments of one or more Azure resources, but once those resources deploy there's no active connection or relationship to the template.

With Azure Blueprints, the relationship between the blueprint definition (what should be deployed) and the blueprint assignment (what was deployed) is preserved. This connection supports improved tracking and auditing of deployments. Azure Blueprints can also upgrade several subscriptions at once that are governed by the same blueprint.
There's no need to choose between an ARM template and a blueprint. Each blueprint can consist of zero or more ARM template artifacts. This support means that previous efforts to develop and maintain a library of ARM templates are reusable in Azure Blueprints.

How it's different from Azure Policy

A blueprint is a package or container for composing focus-specific sets of standards, patterns, and requirements related to the implementation of Azure cloud services, security, and design that can be reused to maintain consistency and compliance.

A policy is a default allow and explicit deny system focused on resource properties during deployment and for already existing resources. It supports cloud governance by validating that resources within a subscription adhere to requirements and standards.

Including a policy in a blueprint enables the creation of the right pattern or design during assignment of the blueprint. The policy inclusion makes sure that only approved or expected changes can be made to the environment to protect ongoing compliance to the intent of the blueprint.

A policy can be included as one of many artifacts in a blueprint definition. Blueprints also support using parameters with policies and initiatives.

Blueprint definition locations

When creating a blueprint definition, you'll define where the blueprint is saved. Blueprints can be saved to a management group or parent subscription that you have Contributor access to. If the location is a management group, the blueprint is available to assign to any child subscription of that management group.

Managing Blueprints as Code

Using the Blueprints in the Azure Portal is a great way to get started with Blueprints or to use Blueprints on a small-ish scale, but often you'll want to manage your Blueprints-as-Code for a variety of reasons, such as:

Sharing blueprints
Keeping blueprints in source control
Putting blueprints in a CI/CD or release pipeline

Testing strategies

Compliance-as-Code can be summarized as the organizational capability to automate the implementation, verification, remediation, monitoring, and compliance status reporting. This automation comes in the form of code and is integrated into the code repositories used by Devs and Engineers. It becomes "just another piece of code." I have written an entire blog post about Compliance-as-Code here.

CaveRace

Clemens Schotte — Sun, 28 Mar 2021 08:51:11 +0000

CaveRace is a classic maze-based video game I developed back in 1997 with some other students. Inspired on a game, I played on my Commodore Amiga, called Dyna Blaster (Bomberman).

Forest level	Winter level	Winter level

Download

You can download the 16-bit MS-DOS version of CaveRace (version 1.2) here.

Story

On the planed Eldora, there are miners collecting gold and diamonds. When the miners get unexpected visitors from outer space, the mining of precious minerals is in danger. The only defense the miners have is their explosions to make a way inside the mines and caves. CaveRace is a game where you collect as much as possible precious minerals and destroy all alien visitors.

Planed Eldora	Collect treasure	Alien visitors

Borland C

The game is mainly written in the programming language Borland C 3.1, and some graphic routines are in x68 assembly language. The minimal system requirements are an Intel 80386 IBM compatible PC running MS-DOS and VGA 320×200 pixels (Mode 13h) in 256-color mode video system.

The game is using your mouse and keyboard for navigation and gameplay. The game loop is in sync with the refresh rate of the screen, not the best choice, but simple to understand. No sound is present in the MS-DOS version, later on, I ported CaveRace to Windows, this version has upgraded graphics and sounds (explosions).

There is also a MapEditor available to create levels yourselves. Let me know what you have created.

Graphics

The original artwork is created on an Amiga using Deluxe Paint in the file format IFF (Interchange File Format). The game CaveRace is using a binary RGB byte file format. Game tiles (16 x 16 pixels) and screens (320 x 200 pixels) are converted to this binary RGB byte file format.

File	Tiles	Bytes	Description
BGS	5 x 50(16x16)	64000	BackGrounds
BOM	17 x (16x16)	4352	Boms
CAR	320 x 200	64000	Carder (Picture)
ENM	16 x (16x16)	4096	Enemys
FNT	36 x (3x5)	540	Font
HIS	320 x 200	64000	Hi-Scores (Picture)
ITM	13 x (16x16)	3328	Items
MAN	18 x (16x16)	4608	Man
MN1	320 x 200	64000	Menu 1 (Picture)
MN2	320 x 200	64000	Menu 2 (Picture)
PAL	256 x (RGB)	768	Palette
STS	4 x (16x16)	1024	Status
TRS	6 x (16x16)	1536	Treacure

Game cheats

Start the game using the switch -powerblast, and now you can use the function keys for additional power.

Key	Result
F1	next level
F2	max. health
F3	max. bombs
F4	more bomb power
F5	double points
1	screen capture, output is saved to the file screen.raw
%	shows the rendering time

When running the game on old and slow systems, you can use the -slow switch to speed up the game.

Open Source

The MS-DOS version of CaveRace is opensource under the Apache-2.0 license and can found op GitHub.

CaveRace for Windows

There is also a Microsoft Windows and Windows Phone 7 version of CaveRace. Written in C# and using DirectX graphics. More information about how I ported the C version to C# in an upcoming blog post.

Desert & Lava levels	Forest & Winter level

Generate PDF files with asp.net core on Azure

Clemens Schotte — Sun, 28 Mar 2021 08:42:21 +0000

There are many libraries and services to generate PDF files for asp.net core web applications. There are excellent commercial solutions out there, but if you need a free solution, it gets harder. Some libraries are hard to use, or others are limited in functionality. I need a free, easy to use, and quick solution to generate PDF files on an Azure Web App.

Can a View retrun a PDF?

What I need is a View that returns a PDF and not HTML what it usually does. The beauty of using a standard View is that I can use my web and asp.net core knowledge to design the View. In this case, I need to generate invoices.

I'm using MVC as a pattern to structure my web project.

I start by creating an invoice controller and a correlated view, where I can design an invoice in HTML.

public class InvoiceController : Controller
{
    public IActionResult Index()
    {
        return View();
    }
}

html to pdf

Next, we need a way to render the HTML (the View) as PDF. I use the opensource command-line tool wkhtmltopdf. It is easy to use and compatible to run on Azure Web Apps.

wkhtmltopdf is an opensource (LGPLv3) command-line tool to render HTML into PDF using the Qt WebKit rendering engine. It runs entirely "headless."

Download wkhtmltopdf and add the files to your project. I created a folder /wkhtmltopdf in my solution. When downloading, pick the correct version that is compatible with your Azure Web App (Windows or Linux).

Add the files wkhtmltoimage.exe, wkhtmltopdf.exe, and wkhtmltox.dll to your solution and change the 'Copy to Output Directory' to 'Copy always.'

Rendering the PDF

An easy way to interact with the wkhtmltopdf command-line tool is to use the Rotativa library from NuGet.

First, we need to tell Rotativa where to find the wkhtmltopdf tool. Add the following line to Startup.cs

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    ...

    RotativaConfiguration.Setup(env.ContentRootPath, "wkhtmltopdf");
}

Next, we create a new action result in our InvoiceController that will return the PDF file. This new action result 'IndexAsPDF' will reuse the View we already had created.

public class InvoiceController : Controller
{
    ...

    public IActionResult Pdf()
    {
        return new ViewAsPdf("Index")
        {
            FileName = "Invoice.pdf",
            PageSize = Size.A4,
            MinimumFontSize = 16,
            ContentDisposition = ContentDisposition.Inline,
        };
    }
}

When we go to the URL https://localhost:44349/Invoice/Index it will show the HTML version of the Invoice, but when we go to https://localhost:44349/Invoice/Pdf we get the PDF version.

Hosting a Static Site on Azure using CDN and HTTPS

Clemens Schotte — Sun, 28 Mar 2021 08:36:17 +0000

Most websites don’t need a dynamically generated page for every visitor; it is slow, expensive, and requires continuous updates to be secure. A static site is fast and reliable. I hear you thinking; this is old school, most websites are interactive and are using a CMS in some kind to manage their content.

Headless CMS

The solution for a static website is to make use of a headless CMS, like Hugo or Jekyll. Basascly, you generate a static site from content and a template, similar to what this blog is doing.

A fast and scalable website

Microsoft Azure Cloud platform is the ideal candidate to host your website and web applications. Usually, when I create a website, I use App Service Web Apps, which runs your solution in a scalable manner.

But there is also another option, which is cheaper and is very fast. You can also host your static website from a Storage Account, and when you combine this with Azure Content Delivery Network (CDN), your site is lightning fast and available worldwide.

Storage Account

We start by creating a general-purpose storage account in Azure. Use a unique name and choose a location close to yourself. I live in the Netherlands, so West Europe is, in my case, the best option. Replication I don’t need, so locally redundant, is the cheapest for me.

Next, we need to enable the Static website option in the storage account, and which also gives us the primary endpoint URL we need later.

Upload some test HTML content into the BLOB storage. I used the build-in Storage Explorer when uploading. Use the container $web (this was created by enabling the Static website option).

Let’s test if the files are visible in the browser. Use the primary endpoint URL from the enable the Static website option. It looks something like: https://«your unique name».z6.web.core.windows.net/

The z6 in the URL is the location of the datacenter and can be different in your situation.

Content Delivery Network (CDN)

To make your website fast and responsive, host it closeby your visitors. Visitors from the US and Australia are far from West Europe, so by using a CDN, the content is as closeby as possible. Azure CDN has 130 point-of-presence (POP) locations worldwide.

Creating an Azure CDN is easy, give it a unique name and point it to the primary endpoint URL from the Storage account we had created earlier.

Test if your site is still working, and go to the CDN edge URL. It looks something like: https://«your unique name».azureedge.net/

Domain names and Azure DNS

Our site is now working, served by a storage account, and cached by a CDN worldwide. Now we need a beautiful domain name and URL before we can communicate this to our visitors.

I require a subdomain “www” and a naked/root domain without the “www” prefix pointing to the CDN edge URL. For the subdomain, this is easy, use a CNAME-record. But for a naked/root domain, it is a little bit more complicated. You can’t use a CNAME, but need an A- and AAAA-record pointing to an IP address. But how do I know the right IP address for the Azure CDN edge, and what happens if this IP address changes (and changes happen)? Luckily, when using Azure DNS, we can point to Azure resources what automatically takes the right IP address. We add the naked/root domain and subdomain to the CDN under Custom domains. And test if the website is working in our browsers.

Traffic encryption using SSL for HTTPS

If your website is not using HTTPS, most browsers warn you nowadays. To make the traffic secure between your visitors and the site, we need encryption. We do this by enabling HTTPS at the CDN endpoint. By enabling HTTPS, you get a free certificate that automatically renews. There is a catch if you need HTTPS for a naked/root domain; you need to bring your certificate. Store your certificate in a Key Vault and give the CDN permissions to read this certificate. Then it is possible to enable HTTPS for a naked/root domain.

URL rewire rules

I don’t like the “www” prefix before my domain, but people still type this. To make it easy for people, I want to redirect traffic to the right URL.

Trafic to “www” needs to go to my naked/root domain.
Trafic that is not using HTTPS (encryption) needs to go to HTTPS.

The Azure CDN Rules engine is more than capable of rewriting the URL, and I used HTTP 308 (permanent redirect) to redirect the traffic to the right place.

Azure Static Web Apps

Azure Static Web Apps (currently in preview) gives you similar capabilities combined with a GitHub native workflow and serverless API’s.