Today I couldn’t figure out why any of my ILogger messages in my Azure Function weren’t appearing in Application Insights. According to my research they should appear as Trace messages.

logger.LogInformation("Message ID: {id}", message.MessageId);

I tried various Log Level tweaks to host.json to no avail.

Fortunately one of my colleagues (hi Ivan!) had previously had the same issue, and he’d already found the fix, which is documented here.

Turns out that dotnet-isolated Functions work a bit differently.

var host = new HostBuilder()
    .ConfigureFunctionsWebApplication()
    .ConfigureServices((context, services) =>
    {
        services.AddApplicationInsightsTelemetryWorkerService();
        services.ConfigureFunctionsApplicationInsights();
    })
    .ConfigureLogging(logging =>
    {
        logging.Services.Configure<LoggerFilterOptions>(options =>
        {
            // https://learn.microsoft.com/en-us/azure/azure-functions/dotnet-isolated-process-guide?tabs=windows#managing-log-levels
            // By default, the Application Insights SDK adds a logging filter that instructs the logger to capture only warnings and more severe logs.
            // To disable this behavior, remove the filter rule as part of service configuration:
            var defaultRule = options.Rules.FirstOrDefault(rule => rule.ProviderName == "Microsoft.Extensions.Logging.ApplicationInsights.ApplicationInsightsLoggerProvider");
            if (defaultRule is not null)
            {
                options.Rules.Remove(defaultRule);
            }
            // Set log level to Information so that we don't log traces
            var loggingRule = new LoggerFilterRule("PropertySync", null, LogLevel.Information, null);
            options.Rules.Add(loggingRule);
        });
    })
    .Build();

Here’s an annoying bug I had today. I have an Azure Function which contains both [ServiceBusTrigger] and [HttpTrigger] functions. My HttpTrigger were timing out while debugging locally, for some mysterious reason.

It turned out the problem was that I had added a comment to my function’s host.json. Unfortunately that breaks things completely.

GitHub issue here.

At my current client we are writing a Blazor WASM app which is deployed as a Static Web App. The backend is an Azure Function which is deployed as a “Bring your own” function, however I think this still applies if the backend is a Managed Function.

The static web app is hosted in Azure at https://calm-ocean.33.azurestaticapps.net/. All of it’s pages are protected with OAuth on Microsoft Entra ID (formerly Azure AD).

The API is an Azure function with an HTTP endpoint at say https://my-func.azurewebsites.net/api/blogs.

At first this endpoint had no authentication, meaning it can be called directly and return a 200.

I then linked the Static Web App to the Azure function, which adds an “Azure Static Web Apps” Identity provider to the Azure Function, which means only the Static Web app can call the Function.

After linking, if I try call my function endpoint at https://my-func.azurewebsites.net/api/blogs it now returns a 400 (it should probably return a 401).

The security hole

The Static Web App (https://calm-ocean.33.azurestaticapps.net/) proxies any calls to the function’s endpoints at https://calm-ocean.33.azurestaticapps.net/api.

This means that by default, unauthenticated users can still call the API but via the Static Web App, i.e. https://calm-ocean.33.azurestaticapps.net/api/blogs – even though all other pages are protected by OAuth! Which is a big security hole 😱

The fix

The fix is quite simple. Specify that all routes should be locked down in the staticwebapp.config.json file (except our Blazor authentication pages):

{
 "routes": [
    {
      // Our Blazor pages have authentication via the [Authorize] attribute (in _Imports.razor).
      // Blazor's auth routes are at authentication/*, so allow anonymous access to them.
      // FYI, Azure Static Web App's built-in auth is at .auth/
      "route": "authentication/*",
      "allowedRoles": [ "anonymous" ]
    },
    {
      // Our API is an Azure function which is proxied on the "api" route. We don't want to allow anonymous access! We need to specify that calls to api/* are authenticated.
      // Let's lock down the whole site, so that requests to any page will need SWA auth, which is then passed on to our api/* calls.
      "route": "/*",
      "allowedRoles": [ "authenticated" ]
    }
  ],
  "responseOverrides": {
    "401": {
      "statusCode": 302,
      "redirect": "/.auth/login/aad"
    }
  }
}

Once deployed to Azure, if you try call the API directly (i.e. in an incognito browser window), you’ll be redirected to login.
One obvious gotcha is that this won’t work when you’re debugging locally, because your local function will be on a completely different port and isn’t proxied.

Pro tip: if you’re having trouble getting this to work, you can navigate to /.auth/me on your Static Web App to see the information about the currently logged in user. If you don’t see anything then you can sign in at /.auth/login/aad. These .auth routes are built-in to Azure Static Web Apps.

PS. after figuring all this out, I found this page which is a thorough treatment of how to combine Azure Static Web App’s authentication with Blazor WASM. Personally I haven’t needed to go that far myself – I’m so far only using the guides I’ve linked to above to do Blazor authentication.