Terminal 28

Ave! This is the concluding part of the ESPeriments with Nginx series, where we’ll talk about testing out the HTTPS bits and wiring things up on the ESP8266 end to use HTTPS also. First off, we’ll need to test out the HTTPS API endpoint. Before doing this, I’ll assume the server (web) app is running and the Nginx proxy has been suitably configured (and includes the HTTPS directives as discussed in the previous post). Essentially, we’ll need to simulate HTTP and HTTPS requests to the API endpoint and see the response behavior and codes. There are an eclectic mix of tools to do this sort of work (e.g Postman, etc), but we’ll be using Fiddler by Telerik, which (IMHO) is a solid piece of kit. We’ll use Fiddler’s Composer tab to create a suitable request to the API endpoint. Essentially, the server (web) app is designed to receive a POST request whose payload is the JSON representation of a request object – which should contain a field called “Tag” for purposes of illustration. Here’s a ...

Aaaaaaand we’re back! Right, so we’ll kick off from the last post, where we’d gotten the basic stuff up and running. The next thing to do was to secure the server with SSL. This was necessary because it was necessary to bulletproof some parts of the system,specifically the API endpoint. A hypothetical attacker could seek to compromise the API-bound authentication process by performing a man-in-the-middle (MITM) attack where he’d/she’d have a machine pretend to be the auth server, and would configure the fake machine to respond favorably to any tag of their choice, and possibly even deny other tags. With SSL, the client would be able to verify the identity of the remote auth server, which would be a huge plus. Note that there are other ways of attacking such a system, but I will not enumerate them here. This scenario naturally provided two salient points: one, the API endpoint absolutely needs SSL. It then stood to reason that (at least initially) the API endpoint would need to be con...

*rises from coffin* I have returned from the dead insanely-busy (I know that’s not a real word) ! Hope you guys have had a swell time. Been doing lots of work on stuff,  both personal and professional so I’ve had very little time to settle down and write. Luckily I just completed a milestone project so I had some time to kill. *sips Pina Colada* Today’s post will be a bit lengthy – to make up for lost time . But first, some context. I spent most of January working on a small IoT sort of solution. I won’t go into specifics, but the salient points involved using an ESP12-E module to make requests to a local server (a server on a local network not the internet). For the uninitiated, the ESP12-E module is a cheap (~$3) WiFi-enabled microcontroller…thing. It runs at 80MHz, has up to 4MBytes of flash space and has ~8 GPIOs. It is also Arduino-compatible, so you can get up to speed fairly quickly with it. There are excellent guides on the net describing how to wire the thing up, how ...

Hello all, I’m hoping everyone has had a good week. Tis Thursday folks, the weekend’s a’comin’! I also realized that I barely blog about anything C#, which is a shame since the blog’s tagline implies I should, so this week I’m going to talk about Nancy. I’ll take a rain check on the Alchemy thing though… NancyFx or Nancy for short is a lightweight, server-side web framework for the .NET framework. Basically, it comes into play when you’re trying to build a web-application with server-side smarts, such as a data-bound application (where data is stored, queried and retrieved), building web APIs (web apps returning XML or JSON data in response to requests) and things like that. Granted, there are tons of neat frameworks to do this for every language – there’s Django for Python, there’s ASP.NET and ASP.NET MVC for the dotNet framework itself, etc. However, ASP.NET and ASP.NET MVC are rather heavy and (for me) rather difficult and clunky to deploy on non-Windows hosts. If you’re going t...