Something about website development that has always mystified me has been the cookies. Overall, as a concept, I’ve understood what they do, and how they work, but when it comes to practice, I am at a loss. So, when it came to the Job Tracker application, I learned that I would have to deal with user login, I got very scared.
For those who don’t know, I’ll explain the general concept. When a user logs in to a website, their information is authenticated on the server against the password they have stored previously, and if that is successful, then the server will generate a cookie that stores basic information on the user like their user id or username, and that is sent back to the user. This cookie is then stored on their system, and every time they access the website again, if the cookie is still valid, then they are given access to pages that are specific to them or show them the logged in version of the website. When a user clicks on any page, generally there is a check to make sure that they can even view the page.
Conceptually, this all makes sense to me. However, in practice, it has never been that easy. Every single time I’ve wanted to code a website with some sort of user log in, I’ve had to spend several days researching tutorials on YouTube, and usually everyone has different ways to go about it. Overall, another concern to me, was the privacy and safety of using cookies in general, which put me down a several-day long rabbit hole of how to even program user login, authentication, and authorization.
My initial plan with our capstone project was to create a user login and an authentication API using Nodejs that would send a cookie back to the front end. I had researched this for days as previously stated, and was given a lot of conflicting information on cookies in general. So, after this I had also integrated JSON Web tokens in to my cookie to ensure that it was safe. My biggest fear was what to do with the token on the front end of the website after it was created, and decided to back-burner the concept until more functionality was complete in both front and back ends.
Ironically enough, the answer to all of our problems came to us in the form of the front end library we were using. When one of the front end engineers in my group showed me the starter website that is created using Remix had successfully logging in a user, and displaying their name. I realized that there had to be some way this information was getting there. Luckily for us, as it turns out, the starting website when you create a new Remix application already has code to handle showing logged in users certain pages, and the login process using their Primsa database.
After reading through, and playing with the code of the Remix front end for a few hours, I came to learn that the user id is retrieved from the database, and that is stored in the cookie. This is something that could easily be replaced with an API call to get the user’s id from the API. Just like that, my long research process of trying to understand cookies ended by working smarter and not harder.
