After spending quite a lot of time finding a way to share the cookies for sessions between the client and multiple servers, I noticed that simply cookies cannot be sent to places with a different domain. If we were able to access and modify the cookies of servers from Google or Facebook, this would be a huge problem for security reasons. I thought this wouldn’t be a problem if we run many servers and maintain one session using cookies. I should’ve done research about it before designing the project, and tested the session before we decided to run 3 servers, but I got to learn the valuable lessons! Following this hurdle, I decided to store the session id associated with the user’s email to the database, Google Datastore in our project, and check if the session id from the client is matched with the one in the database every time before the endpoints in the app are called. By doing this we can validate if the session or the user is valid. This workflow is expensive as we have to make a network call from the client to the database. If we were using cookies, this could be done in the server storing the session info.
- A user log in to the website. The access token (session id) from OAuth provider is stored in the database and sent to the client. The session id is stored in the browser as a cookie and expired in 1 hour.
- When a client wants to access user data, the endpoint, GET /session, is called to receive the status if the session is valid, and an email address and session id are sent to the server.
- With the email address from the client, the server access database and looks up the matching address and session id.
- If email address or session id is not found, the server sent 401 status. The serve sends 200 status only if there’s email address and session id matched with the ones from the client.
This workflow is not ideal and very expensive, and there’s so much room for improvement. I’ll keep working on the authentication and session workflows to make the app more efficient and simple.
