[Hackathon Mini Series] — A story of the magical Vodafone hackathon 🔮
Our fourth blog post of our mini series is written by Tala who travelled from Latvia to London to take part in our hackathon. This is the story of her teams work to create something magical!
A few weeks ago the first face-to-face Vodafone hackathon in two years took place, co-located between London, UK and Pune, India. The hackathon, organised by Vodafone UK Engineering, was called “Hack To The Future” and aimed to facilitate new technology ideas and solutions for internal and customer facing Vodafone software products. More than 80 people hacked over two days creating and implementing innovative ideas to present to a panel of the senior leadership team.
How it started
Our team, consisting of myself, our team lead Jamie Haywood, a UX designer Eric Dodd, backend developers Joseph Snell, Mario Osmani and Will Nowell and Chris Allmark, an engineering manager responsible for presentation. On the first day we started with a brainstorm session and after completely pivoting from Jamie’s initial idea, we decided to re-evaluate the login process in Vodafone applications and create a web application with passwordless login. To implement this, we chose the magic links approach.
Magic links are essentially links that are sent to your mailbox email once you enter your email address in the login form. Then, when you open your mailbox and click the link, you’re redirected back to Vodafone website and — magic — you’re logged in! No complex passwords, no need to remember anything but your email address and as a result less friction and greatly simplified login flow.
Day one
Being based in Latvia and coming to London specifically for the hackathon, the first day started with an emotional overload after meeting my colleagues in person for the first time! We kicked off the day with coffee, pastries and a robust discussion about our goals and agenda. Then everyone split up into their teams and, after finding our collaboration space and getting acquainted with each other, we started whiteboarding the architecture of our app. Once everyone was happy with the flowchart drawn on a whiteboard, Jamie set up a repository and myself and Eric started creating an email template. Meanwhile, the backend devs worked on creating the backend server to serve the endpoints. This was built on the Spring framework and used annotations for creating the API’s. Next they worked on generating and storing JWTokens which would be exchanged through API calls to validate the user’s identity. For the POC, they created an in memory database that could be used to add users to and query during the demo the next day.
Eric created some beautiful mock ups in Figma and we then collaborated to implement them in code. After having a short break filled with pizza and chatting with other teams, we proceeded with designing and building the login page. As an outcome of day two, we had some really good looking web app pages as well as the back-end server and a database built by the Mario and Joseph of the team.
Day two
For front-end developers, the second day started with integrating all built pages together and creating a logical flow when a user is navigated from one page to the other or, in case of an error, is informed that something went wrong. Another goal of day two was to integrate front-end with back-end. So that when a user submits the email form, we send an API request to the back-end to save their email address to the SQL database alongside their token. As part of back-end integration, we got stuck with sending a POST request to the API from the front-end due to CORS policy not being configured. After some tampering with the server we allowed communication by adding @CrossOrigin from the front-end. The other issue we faced was we couldn’t get the email template to behave how we needed it to inside the server to send correctly.
Since day two was also meant for presentations, we only got half a day to code and then we had to gather up with other teams to present our projects to each other. And on this note, I just have to mention that Chris prepared a fantastic presentation with a wide variety of “Back To The Future” references, thorough explanation of magic links concept with pros and cons list and diagrams.
Our application
The web application was built, using React for front-end and Java Spring Boot for back-end. To make the application resemble Vodafone website, we utilised Source Web — global components library used in Vodafone that provided us with brand colours, fonts and other styles.
The login flow starts at the page with a form with just one email input field and a submit button.
Once the form is submitted, the entered email address is validated by the back-end. If it’s a valid email address, a token is generated and a magic link is sent to the user’s email address. After that the user is redirected to another page asking them to check their inbox.
The email user receives contains a redirect link in the form of the “Log In” button which redirects the user back to Vodafone website.
Once the user clicks “Log In” button and is redirected back, the token is checked again and, given the check has passed, the user is authenticated. Eventually, if everything goes well, a success message is shown which means the user is logged in!
Future improvements
I might be biassed, but I really think our current flow is flawless. To be fair though, one improvement we could work on is rendering the email template in the email client. One of the issues we faced and nervously tried to fix in the last 10 minutes before presentations was actually rendering the HTML template. For the sake of completion, we ended up sending an email with just a standalone link but, for the application to be production ready, we’d need to work out how to send that Vodafone styled template we built.
Despite all advantages of magic links, they do also have some drawbacks. For instance, magic links flow relies on email deliverability, such links can end up in the spam folder, and security of magic links is tied to the security of the user’s email address provider. Therefore, a potential way to enhance the password-less login flow, making it even more secure and reliable, would be to introduce MFA to our application, making it either the main way to sign in or an alternative to magic links.
Conclusion
Magic links approach is a great alternative to a traditional login process with email and password. It drastically reduces both the number of failed attempts to sign in and support requests as well as protects the company from password breaches. A simplified login process not only provides users with a better user experience, but also makes the life of developers easier by eliminating the need to securely store passwords.
To sum up, I just want to say that a hackathon is an amazing opportunity to work on something completely different from your daily work, meet your long distance team mates for the first time and even go to a pub (after work of course). This is an event I’d definitely recommend attending and I’m already looking forward to the next one!
Want to know more?
If this article has inspired you, and you want to know more please reach out to us on our various social media channels.
If you want to work with us, find us on LinkedIn and drop us a message, we would love to hear from you! ✉️
