Every now and then I have to build some browser based application for which I often end up using an SPA (single page application) approach. For instance, combining Vite with React and React Router in my opinion is a fast approach to get something ready quick. Adding MUI on top for a nice-looking experience can help too.

Then comes the time when this needs to be hosted somewhere, such that browsers can download the static assets linked from the index.html at the root to make the application availble for others to use. Using your everyday hosting provider can be simple and straightforward, and very often a good enough choice. Those providers usually have some offerings for static web hosting (which an SPA basically is), which they build in their infrastructure through virtual hosts through Apache HTTP Server or nginx or something like that. Those servers do the trick, and they can be configured through - sometimes very complicated - configuration settings. Sometimes I use this sort of thing too. So far so good.

In my previous post about local development using the Azure Key Vault Emulator I briefly mentioned my own fork of the emulator to address some missing APIs. One thing I had planned to change in the emulator for a while was how the REST API endpoints exposed by the emulator are created. The old approach (from which I forked) manually crafted the REST APIs including the models needed. That’s been a thorn in my flesh from the first moment I saw it, and I knew that I wanted to fix that. After all, Microsoft has official Open API specs for the Azure Key Vault REST APIs, so why not use those?

One problem you’ll sometimes encounter when working with cloud services from AWS, Azure or Google cloud is that developing locally can be made more difficult when working with services that do not have a standardized interface with an implementation readily available for local installation. For instance, when working with a pub/sub system that is compatible with Kafka you can just install a minimal Kafka cluster locally and all is good. But what to do when the APIs offered by the service you need are not standardized? That’s when emulators come in. In the rest of this post I’m going to focus on Azure, since that’s what I’m working with most often.

I’ve been running a honeypot for a while just to see what creepy things crawl around on the internet. One of the things I wanted to see is what credentials are probed when trying to sign in, so I equipped the honeypot with a fake WordPress login page.

Today, I’m writing about these credentials. For my evaluation I’m looking at data only from the past 6 months, more or less. On average, almost 80 attempts to login are made every day. Needless to say that for the honeypot, all attempts to login fail - there’s really nothing to login to.

I recently had to switch phones, because my old phone conked out. I had an app on that phone that I used for short-lived MFA codes for various logins I use. That app was a poor choice, because it didn’t allow for a backup of the secrets used for the code generation, so I had to go to the relevant logins and one by one remove MFA, then add it again. While doing so, I was wondering how this stuff works underneath, so I started looking into this.

One of the things I have been working on at work over the past few months is an open source implementation for .Net of the standard-to-be for HTTP message signatures. I’ve ended up calling this NSign which granted is a bit broad – the libraries deal only with HTTP signatures – but I found that the name quite fitting.

The general idea of HTTP message signatures is that clients and/or servers can create and verify digital signatures or message authentication codes over HTTP messages, that is either request or response messages. As the standard-to-be puts this: