@@ 3,7 3,19 @@ See `dev` branch for latest changes.
---
A multiplayer deck building game.
-## Shortest possible explanation of the structure
+
+## **Current major issues**
+### **Session cookie refreshing**
+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.
+
+
+## **Shortest possible explanation of the structure**
```
Client <-> Server <-> API <-> Persistent database (PSQL)
API <-> Session store (Redis)
@@ 16,13 28,13 @@ 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.
-### Client
+### **Client**
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.
-### Server
+### **Server**
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\
@@ 33,16 45,16 @@ 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.
-### API
+### **API**
The web API has access to a PSQL server and a Redis server.
-### PSQL and Redis
+### **PSQL** and **Redis**
PostgreSQL is used for storing/persisting data.
Redis is used for storing user sessions.
-## Commit conventions
+## **Commit conventions**
Commits after 09.01.2023 MUST follow [Conventional Commits 1.0.0](https://www.conventionalcommits.org/en/v1.0.0/).
Things to remember: