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.
- Part I - Using the VS Code Extension
- Part II - Using the Astro Static Site Generator
- Part III – Deploying to multiple environments
- Part IV – Password protect your environments
- Part V – Traffic splitting
- Part VI – Authentication using pre-configured providers
- Part VII – Application configuration using staticwebapp.config.json
- Part VIII – API Configuration
- Part IX – Injecting snippets
- Part X – Custom authentication
- Part XI – Authorization
- Part XII - Assign roles through an Azure function
- Part XIII - API integration
- Part XIV – Bring your own API
- Part XV – Pass authentication info to your linked API
- Part XVI – Distributed Functions
- Part XVII – Data API Builder
- Part XVIII - Deploy using Bicep
- Part XIX – Introducing the SWA CLI
- Part XX(this post) – SWA CLI behind the scenes
Yesterday I introduced the SWA CLI, a tool that brings the full Static Web App experience to your local machine. Today I want to explain a little bit in more detail how it works behind the scenes and show you some of its features.
How does it work?
The SWA CLI is a combination of a local reverse proxy, an authentication & authorization emulator, a local web dev server(depending on the web framework used) and the Azure Functions Core tooling:
- The reverse proxy intercepts the HTTP requests and forwards them to the correct target server. Here are the routing rules:
/.auth/**requests => forwarded to the Auth emulator server./api/**requests => forwarded tolocalhostfunctions (if present)./**=> all other requests forwarded to the static assets content server.- The authentication & authorization emulator allows you to ‘fake’ authentication against any authentication provider of your choice
- A local web development server that serves the static content. For example for Angular, the webpack DevServer is used.
- The Azure Functions Core tooling that allows to run your Azure Functions locally
Authentication & authorization
The easiest way to see this in action is by trying to authenticate in our Static Web App:
- We start our application through the swa start command:
- We browse to the authentication endpoint in our application e.g. http://localhost:4280/.auth/login/aad
- Now we get an emulator page where we can build up the authentication response:
- We can specify a User ID, Username and any roles or claims we want to add.
- If we now click on Login, an authentication session is initiated:
- If we browse to the .auth/me endpoint, we can see the details:
Nice!