Dev #7
Assignees
w-vandal (Vandal William)
Clear assignees
w-vandal (Vandal William)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Forge-Store/Forge-Engine#7
Reference in New Issue
Block a user
Ajoute la vraie route hébergée multi-joueurs qui manquait totalement (voir le constat d'exploration : /game/<slug>/play est réservé au créateur connecté, "Publier" ne génère qu'un exécutable mono-joueur) — un visiteur anonyme peut maintenant jouer un jeu explicitement publié en ligne, avec sa propre partie (variables/objets per_player posés dans le commit précédent). core/player_identity.py : identité visiteur via un cookie NON SIGNÉ (forge_player_id, secrets.token_urlsafe(16), 1 an) — une simple clé de partition, jamais un jeton d'autorisation. routes/public_play/ : 4 routes, miroirs des routes existantes de l'aperçu créateur mais threadées avec le vrai player_id du cookie au lieu du sentinel PLAYER_SHARED : - GET /jouer/<slug> (game_play_public.py) - GET /jouer/<slug>/runtime-payload - POST /jouer/<slug>/flow/nodes/<id>/run-data - POST /jouer/<slug>/flow/nodes/<id>/run-variable Chacune vérifie elle-même db.is_public_played(slug) (404 sinon) — un jeu n'est exposé publiquement que si le créateur l'a explicitement basculé "Publier en ligne" (nouveau db/games/is_public_played.py, réutilise la table générique _meta, comme game_meta.py pour 'name'). core/auth_guard.py : les 4 endpoints publics ajoutés à _PUBLIC_ENDPOINTS — la garde générique de connexion les laisse passer sans session, mais chaque vue vérifie quand même is_public_played elle-même (défense en profondeur, pas seulement une liste d'exceptions). CSRF (core/csrf_guard.py) n'a besoin d'AUCUN changement : le jeton est déjà lié à la session Flask, qui existe pour n'importe quel visiteur (connecté ou non). templates/play.html : FORGE_PLAY_URLS (posé en Phase -1) ne construit plus ses URLs via des noms de endpoint fixes (url_for('runtime_payload', ...)) mais reçoit des URLs déjà résolues par la route elle-même (runtime_payload_url/flow_node_run_data_url/flow_node_run_variable_url) — nécessaire puisque ce même template sert maintenant DEUX familles de routes (aperçu créateur ET partie publique), chacune avec ses propres noms de endpoint. routes/play/game_play.py (aperçu créateur, INCHANGÉ comportement) et game_play_public.py passent chacun ses propres URLs. templates/base.html : bascule "🌐 Publier en ligne" dans la barre de navigation du jeu, à côté de "📦 Publier" (export .zip) — deux fonctionnalités distinctes. db/games/game_meta.py expose maintenant is_public_played, disponible partout où `game` est dans le contexte. Vérifié : 237 tests passent (5 nouveaux dans test_public_play.py, dont un bout-en-bout via HTTP avec deux VRAIS clients de test anonymes — deux cookies forge_player_id différents — qui obtiennent des valeurs de variable indépendantes, et un qui verrouille que l'aperçu créateur reste inchangé). Syntaxe JS validée sur les deux variantes de play.html rendu (aperçu créateur et partie publique). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>Le job "test" échouait ("Could not open requirements file: requirements-dev.txt") : docker run -v "$PWD":/app lancé DEPUIS un runner qui exécute déjà le job dans son propre conteneur (Docker- outside-of-Docker) ne peut pas monter "$PWD" — ce chemin vit dans le conteneur du job, pas sur l'hôte où tourne le vrai démon Docker sollicité par ce docker run imbriqué ; /app se retrouvait donc vide dans le conteneur imbriqué. Corrigé en utilisant la clé "container" (standard Gitea/GitHub Actions) : le job tourne DIRECTEMENT dans l'image voulue, le checkout dépose les fichiers dans son propre système de fichiers, aucun montage de volume à faire. Un seul job "test" ne peut avoir qu'UNE image : scindé en test-python (python:3.13-slim) et test-js (node:20-slim, pour les tests node:test de static/js/play/__tests__/), build-and-push dépend des deux. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>"container: image: python:3.13-slim" (tentative précédente) casse actions/checkout@v4 : c'est une action Node.js, qui a besoin de Node dans l'environnement d'exécution des steps — "container:" remplace CET environnement en entier par l'image donnée, qui n'a pas Node ("command not found", nektos/act#107), pas seulement l'environnement des commandes qu'on y lance soi-même. Nouvelle approche : le job tourne sur le runner par défaut (checkout fonctionne normalement, Node y est déjà disponible), et les tests s'exécutent PENDANT un `docker build` (Dockerfile jetable passé par stdin, jamais commité, un par langage) plutôt que dans un conteneur lancé après coup — le transfert du contexte de build vers le démon Docker passe par le protocole API (tar), jamais par un chemin hôte à monter, donc insensible au problème Docker-outside-of-Docker qui avait fait échouer le tout premier essai (docker run -v "$PWD":/app). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>