Working on this project has taught me a lot about the development process. Previously, I had mostly done solo projects. Even when I did group projects in the past I ended up doing such a significant amount of the work that it didn’t feel like a group project. This project’s work is much more evenly distributed and has offered me an opportunity to learn a lot. For this post about 5 things I’ve learned, some will be technical and some will be more general about working with a team.
The Importance of Having a Clearly Outlined Plan
We were quite a few steps into our project before we all got fully aligned on what our app would actually be. We didn’t have clear definitions of some of the key aspects of what the gameplay portion of our text adventure would consist of. At one point when we were discussing what the data structure would look like, we realized how different our visions for the project were. Once we were able to align on our vision for the project, everything went much more smoothly. I think the if we had developed a more clearly outlined plan from the start we could have avoided both confusion and extra work. Luckily it was still before we started development that we came across this discrepancy, and we were able to avoid actually developing the app in separate directions.
Authentication and Authorization
Before this project I would have used the terms authentication and authorization interchangeably. Through this project I learned how they differ, and implemented procedures for both. I’ll outline how I achieved both authentication and authorization:
Authentication
Authentication is the process of identifying the identity of a user. The easiest way to think of this process is that of logging into a website. You enter your email and password and the website is able to identify you.
In previous projects I had always used third party authentication such as OAuth instead of storing account data on a server. This time I wanted to learn more about the authentication process, so I decided to do it myself on our server. To do this I used a password hashing node package called bcrypt which was very easy to implement. It hashes the passwords so that our user server doesn’t store plaintext of users’ passwords. I then set up a function that utilized an internal bcrypt password comparison function to authenticate users. Setting it up was pretty straightforward.
Authorization
Authorization has to do with the privileges that a given user is granted. These privileges can include what the user can and cannot see as well as what they can create edit or delete. This means that a lot of authorization is dependent on authentication.
The authorization in our project mostly has to do with which text adventure games a user can see or edit. In order to implement this, I implemented a system that stores a cookie based on the session in the authenticated user’s browser. The server can then read the cookies of the user making a request, and see their credentials when deciding what a user should be able to do. This wasn’t that difficult to set up, but it took some deeper understanding to start to actually use it.
MongoDB Security
When I was setting up the database and the backend for our project, I made a mistake that compromised the security of our entire database. MongoDB databases have a connection URI complete with username and password in order to authenticate connections to the database. I used this connection URI as in-line code to connect to the database and promptly pushed it directly to our public github repository. Luckily github (GitGuardian technically) automatically detected this mistake and warned me about it.
After doing some research I found that there are many bots that scan through as many github repositories as they can looking for passwords and keys that have been mistakenly pushed.
To fix this problem I changed the password for the account so that it wouldn’t work for anybody who did catch it, and then changed the implementation for connecting to the database. For now I’m using a simple .txt file in the project repository that has the connection URI and is also listed as a file to ignore in the .gitignore file. Right now this solution works well, it isn’t going to be the final solution though. Once the project is hosted somewhere, I will implement environment variables in order to save the sensitive information.
The Importance of Clear Communication
This seems like a very straightforward concept that I thought I already knew what I needed to know about. The part of this concept that I hadn’t thought about was how to facilitate clear communication. I think the difficulty with implementing clear communication is that there is no one way to do it. There were a couple of times during our project that two people found that they worked on the same feature. Luckily we were generally able to combine the efforts of both people, but I know that some work was duplicated despite this. This was after setting up trello boards and talking about what we did and what we were doing each week.
This problem didn’t have a huge impact on our performance, but it shouldn’t keep happening. Our biggest change to improve this is communicating the feature we’re actively working on before starting work on it. It has created a record of what everybody is doing, and preventing duplicate efforts. Its also worth noting that we don’t have rigidly defined roles in this project. It might actually be helpful to have clearly defined roles, as it makes collaborating much easier.
Prioritizing Your Most Important Features
I think this project has made me rethink how to structure the importance of features. Our project is about playing and making interactive fiction, and we’re very behind on the playing aspect of the project. There were several features that we prioritized that in hindsight are less important than the actual core functionality of the project. Yes logging in is important and necessary, but at one point I think three of us were making contributions to the login process. If I were to start this project over I’d probably suggest one person does authentication/authorization and the rest work on game creation and playing. I’m not worried about where we are, as we’ve structured our data in such a way that it should not be difficult to implement the gameplay, but I wish we were at a point where that part of the project was fully behind us.
Conclusion
Overall I think this project has been eye opening. I really wish that somehow this was the only class that we were all taking. Balancing this project with all of our personal lives and then several other classes on top of that has been difficult for all of us. I think the part that bothers me about balancing the time spent on this project with other classes is that I know none of us can afford to give the time that a project like this really deserves. I’m hoping that at some point, maybe even after the class is completed, we can all spend a little bit of extra time to polish our app and make it the best it can be.
Leave a Reply