So I have been making improvements to the location app I blogged about recently. The first cut of the app wasn’t really all that much of an achievement as I could have done the same with a file and a webserver, without needing an app written in go. Now in my last blog post I stated that I would build an API, and I have done so. I have also moved the default page, and created a new one. If you choose to look at the code you will notice a function for checking an id and key (which are both currently hard coded to “test”) this is to allow multiple locations to be shared (via a randomly generated ID) and also make it harder to enumerate the location ID’s that the system knows about by pairing that with a randomly generated key. The creation of these ID’s and keys is going to be what I work on next, as well as some optimisations to the code.
So the current app allows someone to look at the currently shared location by visiting this link now if that location is empty the page will try again every 5 seconds. To set that location for 30 seconds (I’ll make that longer when the ID and key aren’t hard coded to be test) by visiting this link. Do be aware though that there is currently no protection from anyone seeing that location. The location is stored in redis, with a separate key for latitude and longitude. There are a number of different ways I could have done this, but this one was simple. I chose redis because it can store simple key value pairs well, and for what I am doing nothing more complicated is needed.
Next steps are, as I already said, creating the random ID’s, and setting a random key to validate them. But I will also need a way to limit who can do so, and find a way to make it easy to share the link for setting the location, while also opening a page to see that location when it is set.
One of things I had to do before putting this code on the internet was to ensure I didn’t pass any user generated data to functions outside the app in an unsafe manor. Fortunately because go is typed the latitude and longitude will generate an error if you try to set them as anything that isn’t a number, so the scope for abusing them isn’t great, but the ID and key are strings, and strings that I need to pass through to the redis instance in the background, so these need to be sanitized. I’m relying on the function that checks the id is valid to do that, as that will fail in a way that prevents further use of the strings if they are not valid, now obviously that checks they both match the string “test” exactly, but as that section of the function is temporary I have included a regex before it to check they’re not massively long, or contain any funky characters. Those checks are currently overly restrictive, and will be loosened up eventually, but better to start overly restrictive, and allow more as you find it safe than to start overly permissive and let someone hack you. Especially as the source code is readily available.