Martin Costello's Blog
The blog of a software developer and tester.
This week the Azure storage team finally announced that Azure Storage now support hosting static websites. This has been a long-standing request from users of Azure (for nearly 4 years), so it's great to see something now available for use, even if at the time of writing it's currently only in public preview.
I've been using .NET Core since it was released back in June 2016 as my development technology of choice for my personal projects, as well as helping introduce it as a mainstream technology choice at Just Eat (my current employer).
I find it so much more pleasurable to code against compared to "traditional" ASP.NET. With features such as self-hosting, built-in dependency injection and a high level of testability, you can really focus on solving the domain problem at hand, rather than worrying too much over boilerplate and ceremony.
Each new release, both major and minor, brings something new to geek-out over, but ASP.NET Core 2.1 has been a particular stand-out so far for new features and benefits that I find really compelling as a software developer.
Over the past few months I've been working on some new ASP.NET Core applications in my day job at Just Eat, and as part of that devised a new strategy for integration testing the applications with respect to their HTTP dependencies.
I've written a blog post about the problems I faced and how I went about solving them over on the Just Eat Tech Blog.
Since I set up my blog in March 2014, it's been running in IIS as part of an Azure App Service. Initially this was required as the blog was originally a WordPress site, so a server was required to run the PHP code for WordPress. However when I got fed up with keeping WordPress up-to-date and migrated to a static Middleman site, I left it hosted in Azure. This was mainly because it was the easiest option, as that's where it was already, but also because this allowed me to specify HTTP response headers still, such as for
At the end of the day though, this blog is still statically generated, and running a whole web server (actually two, one in Azure's East US datacentre, another in UK South) is just overkill. Given that Amazon S3 supports static website hosting, I thought I'd migrate it to an S3 bucket instead.
A few weeks ago at work it was our quarterly Hackathon. After a dearth of ideas I thought of an idea to extend our Alexa app to incorporate something I've been working on in the office over the last few months. Over the course of a few days a colleague and I tweaked the skill and achieved our aim, which was pretty fun. Did I mention we also won the technical category?
Off the back of that success I thought I'd have a go at writing my own skill, which was finally accepted into the Alexa Skill Store on the 14th February after it's third round of certification tests. It's a fairly simple skill with just two "intents" that allows you to either ask about current disruption on any London tube line, the London Overground or the DLR, or for just a specific line. It's also 100% open-source, hosted on GitHub. The free AWS Lambda tier also makes it free to run (unless the skill becomes wildly popular...).
Now the dust has settled and I've got some free time, I thought I'd do a blog post about how I got started with Alexa and the idea for the skill, how I coded it and set up the Continuous Integration, how I got it through the certification tests and, finally, setting up monitoring for it in production.
A few years ago I thought I'd set up a blog. Initially I created a blog in Blogspot but I decided some time later that I'd rather host it myself with custom DNS, etc., mainly as a learning exercise. As I'm mostly a developer in the Microsoft stack, I decided I'd set it up in Windows Azure as an Azure Website (now a "Microsoft Azure Web App") as that was something I knew of and knew a little about. A few clicks through a wizard later and I had a WordPress blog running in Azure, backed by a MySQL database. Great - time to get blogging!
Flash-foward a few years, and I had a sum total of one solitary blog post. Yeah, so I'd been a bit slack on the whole writing a blog thing. However I've got an idea for a second blog post that I've been procrastinating over writing for a while, so I thought I'd start on that (aside: this isn't that blog post, that's coming soon). By this point I'd grown two different Azure subscriptions and the blog was running in the wrong one and I was starting to hit limits on my free Azure credits due to other usage, so I figured I'd switch it around. The problems begin.
So recently I've been doing some work ensuring some websites I work on are secure. This has been from a mix of hands-on testing of them myself, dealing with feedback from dedicated security testers testing the applications, and this week attending an "ASP.NET Secure Coding" training course.
From my own testing I found the odd thing here and there during development based on what I've read in the past is best-practice. These were exclusively application/coding changes. Fixing these was a mix of "Oh yeah" realisations or a quick Google leading to MSDN or Stack Overflow, leading to some simple one-line changes here and there.
The same was true of the results from the dedicated security testers. This was slightly more work, as they were very good at saying "X is an issue", but almost useless at saying how to fix it. They also did some tests which were more of the server and network configuration, which in some cases fell out of my personal work remit. However, a secure app is a secure app, meaning that you just can't ignore it because it's not controllable by the code. This meant yet further reading to find out how to fix the software issues, as well as reading further afield to find out how to fix the server and network configuration issues as well.
Then there was the security testing course. The title was a bit of a misnomer, as it wasn't so much "how to code securely" as "how to find security problems". It was very useful as it was quite eye-opening to discover what seemingly innocent "oh that's not important" small niggly things could, in the hands of a skilled "hacker", actually lead to your machine being completely owned by an attacker.
However, after three rounds of realisation, fixing and testing, there was one common theme I found with all of this - there was no central resource detailing how to fix all of the issues that came up. There were a lot of resources where just one problem would be described (and sometimes a fix for it described), but a lot of the time there'd be a page about a problem, but you'd need to go to a completely different one for the fix. Some required some creative Googling to find, others were right there (if you knew what you were looking for).
So, Dear Reader, why have I written this? Well, I thought it would be a good idea to collate all the stuff that's best practice into a single blog post, and then include for each one the instructions of how to fix it. Helpful right? Well, at least I hope so.