Skip to main content

Posts

Showing posts with the label Web development

Safely injecting a JSON configuration object into a Razor Page

While reviewing an ASP.NET Core Razor page application that needed to share server-side configuration with client-side JavaScript, I noticed the following approach to inject a JSON object: <script> var featureFlags= @Html.Raw(Model.FeatureFlagsJson); </script> It works — until it doesn't. This post walks through the right way to do it, why the naive approach can blow up in your face, and what the production-safe pattern looks like. Remark: There was a mistake in the original version of this post. I updated it with a fixed version of the code Why the naive approach is dangerous Directly interpolating server-side values into a <script> block creates an XSS (Cross-Site Scripting) vector . If any value in your config object contains characters like </script> , " , or ' , the browser can interpret that as the end of your script tag — or worse, execute attacker-controlled code. Consider this innocent-looking config value: public string ...

DAB 2.0 Preview: Autoconfiguration with autoentities

If you've been maintaining a large dab-config.json , you know the pain: every table, view, and stored procedure needs its own entities block. Schema grows, config grows. Someone adds a table and forgets to update the config, and suddenly your API is silently missing endpoints. DAB 2.0 Preview introduces autoentities — a pattern-based approach that discovers and exposes database objects automatically, every time DAB starts. This post covers how it works, how to configure it from the CLI, and what to watch for. Getting started As DAB 2.0 is still in preview, you first need to install the preview version: dotnet tool install microsoft.dataapibuilder --prerelease Note: MSSQL data sources only, for now. Initialize a new dab-config.json file if it doesn't exists yet: dotnet dab init Remark:  Notice that we prefix dab with dotnet to avoid collisions with the globally installed release version. How it works Instead of defining each entity explicitly, you define one ...

ASP.NET Core - TryParse error when using Minimal APIs

Minimal APIs are the recommended approach for building fast HTTP APIs with ASP.NET Core. They allow you to build fully functioning REST endpoints with minimal code and configuration. You don't need a controller but can just declare your API using a fluent API approach: This makes it very convenient to build your APIs. However you need to be aware that a lot of magic is going behind the scenes when using this approach. And this magic can bite you in the foot. Exactly what happened to me while building an autonomous agent invoked through a web hook. The code In my application I created the following API endpoint using the minimal API approach: The minimal API injects an AzureDevOpsWebhookParser that looks like this: Nothing special… The problem The problem was when I called this endpoint, it failed with the following error message: InvalidOperationException: TryParse method found on AzureDevOpsWebhookParser with incorrect format. Must be a static method with for...

Using HTTP Files in VS Code with REST Client

I regularly switch between multiple IDEs, mostly VS Code and Visual Studio but sometimes also Rider or Cursor. One of the Visual Studio features I miss when using VS Code is the support for HTTP files. What if I told you that there is a way to use HTTP files in VS Code? Enter the REST Client extension for Visual Studio Code, a lightweight, powerful tool that lets you test APIs without ever leaving your editor. What is the REST client extension? Similar to the HTTP support in Visual Studio, the REST Client extension allows you to send HTTP requests and view responses directly in VS Code. It's minimal, scriptable, and integrates seamlessly into your existing workflow. It offers the same functionality as in Visual Studio and more:   .http and .rest file extensions support Syntax highlight (Request and Response)         Auto completion for method, url, header, custom/system variables, mime types and so on Comments (line ...

Defending yourself against compromised npm packages

The recent software supply-chain attacks proof once again that the npm ecosystem is a double-edged sword. With over 2 million packages available, developers can build applications faster than ever before. But this convenience comes with a significant security risk. When a single compromised package can affect thousands of downstream projects, we need better defenses. In this post, I'll show you how combining npm lock files with the --ignore-scripts flag creates a powerful security layer that can protect your projects from many common attack vectors. The growing threat of supply chain attacks Supply chain attacks in the npm ecosystem aren't theoretical—they're happening regularly. In recent years, we've seen high-profile incidents like the event-stream compromise, where a popular package was hijacked to steal Bitcoin wallets, and the ua-parser-js attack, where malicious code was injected to install cryptominers and password stealers. These attacks often follow a...

The quest of the 403.16 error in IIS

Ever heard about the 403.16 HTTP error response code? I certainly did not. But it was exactly this error code we got back after configuring IIS to expect a client certificate. In this post I’ll explain how we tackled the issue and found a solution(workaround?). How to configure IIS to expect a client certificate? First step is to enable SSL on IIS: Open IIS Manager . Select your site and click Bindings . Add or edit an HTTPS binding and select a valid SSL certificate . Now we need to configure our website so that it requires a client certificate: In IIS Manager, select your site. Click SSL Settings . Check Require SSL . Under Client certificates , select Require . Click on Apply . A last optional step is to configure client certificate mapping: Navigate to Authentication settings. Enable IIS Client Certificate Mapping Authentication . Remar...

Web Deploy - WDeployConfigWriter issue

At one of my customers, we are still (happily) using Microsoft Web Deploy to deploy our web applications to IIS. This works great and is all nicely automated and integrated in our Azure DevOps pipelines. Until the moment it no longer works. Something that happened last month when trying to deploy one of our projects. A look at the web deploy logs showed us the following error message: Web deployment task failed. ((2/11/2024 15:00:08) An error occurred when the request was processed on the remote computer.)(2/11/2024 15:00:08) An error occurred when the request was processed on the remote computer.Unable to perform the operation. Please contact your server administrator to check authorization and delegation settings. Time to contact the server administrator... Unfortunately that’s my team in this case. So let’s investigate. We logged in on the web server and checked the event logs. There we got some extra details: A tracing deployment agent exception occurred that was propagat...

Web Deploy error - Source does not support parameter called 'IIS Web Application Name'.

At one of my customers, everything is still on premise hosted on multiple IIS web servers. To deploy web applications, we are using Web Deploy . This works quite nicely and allows us to deploy web application in an automated way. Last week, a colleague contacted me after configuring the deployment pipeline in Azure DevOps. When the pipeline tried to deploy the application, it failed with the following error message: "System.Exception: Error: Source does not support parameter called 'IIS Web Application Name'. Must be one of (Environment)" Here is a more complete build log to get some extra context: Starting deployment of IIS Web Deploy Package : \DevDrop\BOSS.Intern.Web.zip">\DevDrop\BOSS.Intern.Web.zip">\DevDrop\BOSS.Intern.Web.zip">\DevDrop\BOSS.Intern.Web.zip">\\<servername>\DevDrop\BOSS.Intern.Web.zip Performing deployment in parallel on all the machines. Deployment started for machine: <servername> with port...

Azure Static Web Apps–SWA CLI behind the scenes

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 s...

Azure Static Web Apps–Introducing the SWA CLI

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(this post) – Introducing the SWA CLI Today I want to introduce you a...

Azure Static Web App–Deploy using Bicep

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(this post) -  Deploy using Bicep So far I’ve deployed our Azure Static Web App using Github Actions. Bu...

.NET Core - Renew localhost certificate

Today when I tried to debug a .NET Core application, I got a browser warning that my localhost certificate was no longer valid. The good news is that renewing your localhost certficate when using Kestrel is easy. You can use the built-in dotnet dev-certs command to manage a self-signed certificate. We can first remove the existing outdated certificate by executing the following command: dotnet dev-certs https --clean Output: Cleaning HTTPS development certificates from the machine. A prompt might get displayed to confirm the removal of some of the certificates. HTTPS development certificates successfully removed from the machine. Now we can generate a new self-signed certificate using following command: dotnet dev-certs https –trust Output: Trusting the HTTPS development certificate was requested. A confirmation prompt will be displayed if the certificate was not previously trusted. Click yes on the prompt to trust the certificate. Successfully created and truste...

Azure Static Web App–Data API Builder

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(this post) – Data API Builder So far I have shown you 2 different possibilities to integrate an API inside your Azure Static Web App: You...