Volunteer Shopper Web App
Volunteer Shopper Web App
Web Development
Web Development
A fellow student from Berkeley, Tony, came to me with the idea of an automated volunteer shopping app early in the pandemic. He based his idea of a Facebook group that was attempting to do the same thing but manually with people monitoring the page and matching people. A group of 4 students, including myself, joined up together to remotely work on this since it would be learning opportunity and could help out our community.
We split up the work between the front end and data delivery, the database and pairing shoppers to volunteers, and sending out the emails.
I worked on front end and data delivery, mostly the data delivery part. One of our partners had found a pretty useful UI format from 2017 on YouTube and we based our front end off of that after he updated it a bit. For the data delivery, I had to connect this web app with Firebase which involved setting up the database rules, security settings, and a discussion about how we should host this site. We could not decide between hosting with Firebase or GitHub pages, but ended up choosing Firebase because we were already using their real time database to hold our data and do the pairing.
The most difficult part of my work was getting the user's location in coordinates for pairing calculations. I used the HTML Geolocation API, specifically "navigator.geolocation.getCurrentPosition()." Originally this looked simple enough, but then the hosting and security issues came in and complicated it heavily. It turns out you cannot use this, on Chrome at least, from insecure origins. So after a significant amount of debugging on hosting the site and modifying how this function was called in the java script file, I was able to fix the issue and our real time data base could now receive location data from the browser.
The next issue we had to sort out was connecting to the database from the website to deliver the data. It worked fine, but we had to make sure that the database was secure and it could not be accessed by bad actors. Our API key was exposed in the codebase and we found it very difficult to have a setup were this was not that case with our hosting options, so instead we researched approaches that could deal with this being the case but still secure the database. We couldn't just make the database write only since our automated email tool(Send Grid) needed to read from the database. The next option was to have authenticated users, but we were unable to get the Firebase hosted website to be an authenticated user without having the authtoken or API key exposed in the code base to any user who opened up developer tools. After some serious debugging we had lost our bandwidth for the project and left it at about 90% complete with a user interface, working pairing system, database, and functional auto-email system.
Looking back on the project now I can think of a new solution where we restrict the read rights to authenticated users only but leave writes open and then authenticate our send grid account. This would work better since the auto-emailer is not user facing, but would still leave us vulnerable to excessive writes to the database. There is a way to restrict that as well through Firebase, but at that point we would just be treating symptom after symptom without addressing the cause.
This project showed me my lack of knowledge in modern security concerns and solutions , which has inspired me to take a computer security class the for Spring 2020 semester.
This was still a great project even though it did not make it all the way through development. I gained great experience debugging an application intended for real world use. Security is generally not a giant concern in school projects(outside of CS161: Computer Security) since your work is often not on any network and not necessarily intended for real world deployment. This experience while light in actual code written was far more valuable in documentation reading and debugging.