Basic implementation of auth0 on both the server and client side of the game. This was a challenging endeavor that required 5 separate NPM packages just to get everything working. None of the existing auth0 socket.io integrations considered the fact that you might want to have authentication be optional (guest mode), which presented a challenge in writing this for the backend.
Client side:
implemented the Auth0Provider and useAuth0 hooks to let components drive the state of log in / sign up / log out. When the player logs in, the WebSocket manager fires a 'login' clientToServer event to the socket.io client.
Server side
said login event authenticates by using a Machine to Machine set of keys on a separate webserver-specific auth0 application. The server handles verification of a user and confirming their usernames
B/c none of the auth0 specific npm packages for socket.io were configured to handle optional login, I modified some existing middleware to account for this scenario.
We're still staying in a monolithic structure due to low # of players. The webserver will handle authentication requests 🙏🏻
Player impact:
Players will now have to be 'guests' if they don't sign up
Players will get engagement stats, titles / awards, and possibly profile pictures / saved decks / etc. once they register in the future
this involved creating and authorizing the application's access to the API on the auth0 interface
I had to customize the DB for auth0 to accept usernames, since usernames will be the basis of what we display as names (you just have to turn some toggles on)
Closes: #365
Basic implementation of auth0 on both the server and client side of the game. This was a challenging endeavor that required 5 separate NPM packages just to get everything working. None of the existing auth0 socket.io integrations considered the fact that you might want to have authentication be optional (guest mode), which presented a challenge in writing this for the backend.
Client side:
Server side
Player impact:
New sign-in screen: