dev branch for latest changes.A multiplayer deck building game.
Currently, the cookie is refreshed on every single action which requires
session auth.
Okay, that seems pretty normal.
So, we just save the new one to the global.user_to_session_map hashmap,
and just send an event to the client with the new one, so they can update
it in the clients presistent storage, right? This can happen automatically
in the background.
Client <-> Server <-> API <-> Persistent database (PSQL)
API <-> Session store (Redis)
The client only communicates with the server.
The server is authorative, and has the final say in ALL things.
The server communicates with a web API that handles all database
functionality.
The API is not exposed publicly (thus, it will not require authentication
or authorization for most endpoints), and all request go through the server.
The client creates a connection to the server once the user gives their account
credentials, either for an existing account, or a new account.
This connection may be rejected if the credentials are not valid.
When a client connects to the server, it sends the account credentials to
authenticate (or an existing cookie on the client side).
These are then sent to the API, which will create a session
(or verify the previous one) and return a cookie. The cookie should then be
passed to the client.
Should the cookies for both users in a game be stored on the server as well?
In-memory, but just so the user doesn't have to send it with every request,
to save on the traffic.
The web API has access to a PSQL server and a Redis server.
PostgreSQL is used for storing/persisting data.
Redis is used for storing user sessions.
Commits after 09.01.2023 MUST follow Conventional Commits 1.0.0.
Things to remember:
shared, client, server and api