I always intended to give the app an open-source license. Now that it’s in a state that I feel is functional I asked my employer who sponsored about 10% of the code if they would allow me to apply an open source license, and as the code is unrelated to my job, or their core business, they said yes. So I’ve applied an MIT license. The code is available here.
Since my last post about the location sharing app I was building I stopped working on it. But I came back to it this week to get it working with Azure AD, the protocol is OpenID Connect, and Microsoft’s documentation is very good. I had already got LDAP authentication working, but I didn’t deploy that version of the app as I didn’t want to have to install an LDAP service on a web facing server. But as I don’t have to support Azure AD I could deploy the version with that working, but before I could I do that I needed to allow for disabling LDAP authentication. So having sorted that out I have deployed the current version, with LDAP authentication disabled. It’s also configured to only allow consumer Microsoft accounts to authenticate against it, because this is a demo, not a commercial service. It is once again available at https://location.craig-james-stewart.co.uk/.
It’s been a while, and honestly I haven’t really done much work on this since my last post. I’d like to claim I’ve had too much on, but honestly I just haven’t had the motivation. My employer does “Learning and Development” days, and my manager allowed me to work on my location app as part of this. So the progress since my last blog post is thanks to this.
So in my last post I mentioned random numbers, and talked about needing to trade off between security, speed, and the randomness of the source of random numbers. I stand by the considerations that need to be made, but it was brought to my attention that I was looking at math/rand in go where they also have crypto/rand which makes using /dev/urandom much simpler. The trade offs are the same in practice, but the work was much easier to implement that way, so thank you Liam
I'd try crypto/rand. There seems to be a debate about having to create the seed for math/rand but apparently that's not something they are planning on fixing as it's not meant for true randomness.— liam sorsby (@liamsorsby) September 2, 2019
I have nothing to show on the location app I’ve been building, but I’ve hit a hurdle that I felt warrants some discussion. I want to use two random strings that are unrelated to each other in order to make the app more secure. An ID for each location shared, and a key to prevent someone simply trying to enumerate all the ID’s. Because the key is a security device it is important that it is not derived from the ID, or from the same deterministic source as the ID. With this in mind I have been reading about the random number generator available in Go.
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 in my previous blog post I said I was going to try and build a web app to find someone’s location using their smartphone’s location services. The first step in this is choosing a language and/or framework to build it in. I’ve decided to use Go, which a former collegue of mine tells me makes me a hipster.