Skip to main content

Azure Static Web App– Application configuration using staticwebapp.config.json

As a follow-up on the presentation I did at CloudBrew about Azure Static Web Apps I want to write a series of blog posts.

Before I continue with the authentication and authorization part, I want to take a side step into configuration. When talking about configuring a static web app, we have to make a difference between:

  • Application configuration: This allows us to configure the application behavior and features and is managed through  the staticwebapp.config.json file. Use this file to define route and security rules, custom headers, and networking settings.

  • Build configuration: Tweak the build process.

  • Application settings: Change application-level settings and environment variables that can be used by backend APIs.

Conceptually you can see an Azure Static Web App as a reverse proxy with behind it storage for your static content and an (optional) API. We can configure and tweak the rules of this reverse proxy through our staticwebapp.config.json file.

Azure Static Web App will look for this file in the folder set as the app_location or any subfolder. Additionally, if there is a build step(like for an Angular or React app), you must ensure that the build step outputs the file to the root of the output_location.

An example file looks like this:

You can configure a lot of settings in this file but I’ll focus on 2 specifically for this post:

  • "routes" - are an array of "route" objects that can each be associated with access rules ("allowedRoles"), actions ("redirect", "rewrite") - and request ("methods") and response ("headers","statusCode") properties.
  • "navigationFallback" supports applications that rely on client-side routing by providing a server-side fallback route which serves the required page, with filters to control usage.

I always start by configuring a navigationFallback. This guarantees that any URL that doesn’t match to a specific route rule can be handled. This is especially important when you are hosting an SPA and you want to redirect the user to the entrypoint of your SPA(typically an index.html file):

Another thing you’ll certainly use are the routes. Here we get a lot of power in our hands. For every route we can configure:

  • A route pattern: rule to check if a request matches the specified route, e.g. "/articles/*.html"
  • A list of AllowedRoles: defines an array of role names required to access a route. e.g. ["authenticated"]
  • A Rewrite property: defines the file or path returned from the request . The browser url doesn’t change and the URL is rewritten behind the scenes.
  • A Redirect property: defines the file or path returned from the request. The user is redirected to the target path using a 302 response.

Remark: There is a lot more we can configure, but I'll handle these settings when needed in a later post.

More information

Configure Azure Static Web Apps | Microsoft Learn

Configuration overview for Azure Static Web Apps | Microsoft Learn

Labels:

Popular posts from this blog

Podman– Command execution failed with exit code 125

After updating WSL on one of the developer machines, Podman failed to work. When we took a look through Podman Desktop, we noticed that Podman had stopped running and returned the following error message: Error: Command execution failed with exit code 125 Here are the steps we tried to fix the issue: We started by running podman info to get some extra details on what could be wrong: >podman info OS: windows/amd64 provider: wsl version: 5.3.1 Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM Error: unable to connect to Podman socket: failed to connect: dial tcp 127.0.0.1:2655: connectex: No connection could be made because the target machine actively refused it. That makes sense as the podman VM was not running. Let’s check the VM: >podman machine list NAME         ...
Read more

Azure DevOps/ GitHub emoji

I’m really bad at remembering emoji’s. So here is cheat sheet with all emoji’s that can be used in tools that support the github emoji markdown markup: All credits go to rcaviers who created this list.
Read more

VS Code Planning mode

After the introduction of Plan mode in Visual Studio , it now also found its way into VS Code. Planning mode, or as I like to call it 'Hannibal mode', extends GitHub Copilot's Agent Mode capabilities to handle larger, multi-step coding tasks with a structured approach. Instead of jumping straight into code generation, Planning mode creates a detailed execution plan. If you want more details, have a look at my previous post . Putting plan mode into action VS Code takes a different approach compared to Visual Studio when using plan mode. Instead of a configuration setting that you can activate but have limited control over, planning is available as a separate chat mode/agent: I like this approach better than how Visual Studio does it as you have explicit control when plan mode is activated. Instead of immediately diving into execution, the plan agent creates a plan and asks some follow up questions: You can further edit the plan by clicking on ‘Open in Editor’: ...
Read more