feat: Implement server-side player context for actions to prevent client tampering.
This commit is contained in:
26
docs/development/devlog/2025-12-16-215000_anti_tampering.md
Normal file
26
docs/development/devlog/2025-12-16-215000_anti_tampering.md
Normal file
@@ -0,0 +1,26 @@
|
||||
# Anti-Tampering Implementation
|
||||
|
||||
## Objective
|
||||
Implement a robust anti-tampering system to prevent players (including the host) from manipulating the game state via malicious client-side emissions.
|
||||
|
||||
## Changes
|
||||
1. **Server (`src/server/managers/RoomManager.ts`)**:
|
||||
* Added `getPlayerBySocket(socketId)` to securely identify the player associated with a connection, eliminating reliance on client-provided IDs.
|
||||
|
||||
2. **Server (`src/server/index.ts`)**:
|
||||
* Refactored all major socket event listeners (`pick_card`, `game_action`, `start_draft`, `player_ready`) to use `roomManager.getPlayerBySocket(socket.id)`.
|
||||
* The server now ignores `playerId` and `roomId` sent in the payload (where applicable) and uses the trusted session context instead.
|
||||
* This ensures that a user can only perform actions for *themselves* in the room they are *actually connected to*.
|
||||
|
||||
3. **Server (`src/server/managers/GameManager.ts`)**:
|
||||
* Updated `handleAction` to accept an authentic `actorId`.
|
||||
* Added ownership/controller checks to sensitive actions:
|
||||
* `moveCard`: Only the controller can move a card.
|
||||
* `updateLife`: Only the player can update their own life.
|
||||
* `drawCard`, `createToken`, etc.: Validated against `actorId`.
|
||||
|
||||
4. **Frontend (`GameView.tsx`, `DraftView.tsx`, `DeckBuilderView.tsx`)**:
|
||||
* Cleaned up socket emissions to stop sending redundant `roomId` and `playerId` fields, aligning client behavior with the new secure server expectations (though server would safely ignore them anyway).
|
||||
|
||||
## Result
|
||||
The system is now significantly more resistant to session hijacking or spoofing. Users cannot act as other players or manipulate game state objects they do not control, even if they manually emit socket events from the console.
|
||||
@@ -0,0 +1,12 @@
|
||||
# Fix Draft UI Layout Consistency
|
||||
|
||||
## Objective
|
||||
Fix the layout inconsistency where the "Waiting for next pack..." screen and other views in the Draft interface do not fully occupy the screen width, causing the UI to look collapsed or disconnected from the global sidebars.
|
||||
|
||||
## Changes
|
||||
1. **DraftView.tsx**: Added `flex-1` and `w-full` to the root container. This ensures the component expands to fill the available space in the `GameRoom` flex container, maintaining the full-screen layout even when content (like the "waiting" message) is minimal.
|
||||
2. **DeckBuilderView.tsx**: Added `flex-1` and `w-full` to the root container for consistency and to ensure the deck builder also behaves correctly within the main layout.
|
||||
|
||||
## Verification
|
||||
- The `DraftView` should now stretch to fill the area between the left edge (or internal Zoom sidebar) and the right Lobby/Chat sidebar in `GameRoom`.
|
||||
- The "Waiting for next pack..." message will remain centered within this full-height, full-width area, with the background gradient covering the entire zone.
|
||||
Reference in New Issue
Block a user