quest'n'click 4.5.0 · r1

Construite pour quest'n'click 4.5.0, révision r1. Si elle est publiée, et laquelle est la courante, est dit par publication.json.

Changer de domaine ou de fournisseur OIDC

English · Type : procédure · Public : administrateur · Contexte : Studio hébergé · Statut : prête · S'applique depuis : 4.2.3

Le Studio Server (Studio d'équipe hébergé) · contrat : expérimental · vérifié par la CI (matrice de support de la 4.4.0, 2026-10-23) : Postgres, S3 et Keycloak en CI ; Chromium et Firefox (job studio-hosted) ; WebKit sous macOS, à la main seulement · vérifications automatiques : jobs studio-hosted, studio-install-smoke ; plan de CI studioHosted ; 3 fichiers de tests · passes humaines : studio-hosted pas faite (#149), studio-collab pas faite (#150), studio-preview pas faite (#166), studio-assets-hosted pas faite (#167), studio-mcp-remote pas faite (#196), studio-oidc-generic pas faite (#197) · limites connues : history-keeps-old-names

Déplacer un Studio en service sur de nouveaux noms, ou vers un autre fournisseur OpenID Connect. Le jeu et son histoire ne bougent pas ; ce qui change, c’est la façon dont on l’atteint et qui le Studio croit que sont les gens.

Ce que vous obtenez

Le Studio servi sur ses nouveaux publicUrl et playUrl (ou connectant les gens par le nouveau fournisseur), chaque membre de retour avec son rôle, et les anciens noms ou l’ancien fournisseur retirés.

Contexte et versions

Prérequis

Où lancer les commandes

clever … : sur votre machine, dans le dépôt du moteur où les applications sont liées. invite : dans un shell sur l’application studio (clever ssh --alias my-game-studio). Les réglages du fournisseur : dans sa console d’administration.

Étapes

Changer de domaine

  1. Ajoutez les nouveaux noms à côté des anciens : studio. et play. à l’application studio, celui du worker au worker (Domaines et TLS).
  1. Chez le fournisseur, ajoutez les nouvelles URI au client studio, en gardant les anciennes pour l’instant : l’URI de redirection <nouveau publicUrl>/auth/callback, la redirection après déconnexion <nouveau publicUrl>, et mettez l’URL de déconnexion back-channel à <nouveau publicUrl>/auth/backchannel.
  1. Changez publicUrl, playUrl (et worker.url si le worker déménage) dans la configuration, posez-la, et redéployez le studio (Configuration, étape 5). Le serveur n’accepte les mutations qu’avec une Origin égale au nouveau publicUrl : l’ancien nom cesse aussitôt de marcher pour les écritures.
  1. Prévenez les membres :
    • Tout le monde se reconnecte sur le nouveau nom : le cookie de session (__Host-ws_session) appartient à l’hôte qui l’a posé, et celui de l’ancien nom n’est jamais envoyé au nouveau.
    • La CLI garde ses jetons par serveur : npm run studio-server -- login --server https://<nouveau nom du studio> ; un client MCP configuré sur l’ancienne URL est repointé sur la nouvelle.
    • Un lien d’invitation affiché avant marche toujours en remplaçant son hôte par le nouveau nom : le jeton est le même.
    • Les URL des builds publiés (/play/<n>/ sur l’origine du jeu) changent avec playUrl.
  1. Une fois tout le monde sur le nouveau nom, retirez les anciennes URI chez le fournisseur et les anciens noms des applications (clever domain rm <ancien nom> --alias my-game-studio).

Changer de fournisseur OIDC

Le Studio connaît une personne par le (iss, sub) du fournisseur. Un nouveau fournisseur donne à chacun une nouvelle identité : pour le Studio, ce sont de nouveaux utilisateurs, membres de rien. Les rôles doivent être redonnés, par invitation.

  1. Posez le secret client du nouveau fournisseur et le oidc de la configuration (issuer, clientId, audience, cliClientId), et redéployez le studio. Il lit la découverte du nouvel émetteur au démarrage. Chaque session prend fin à sa vérification suivante (les jetons de rafraîchissement de l’ancien fournisseur ne disent rien au nouveau), et les jetons Bearer de l’ancien fournisseur sont refusés.

  1. Réinvitez chaque membre, avec son rôle, du côté de l’opérateur ; chacun se connecte par le nouveau fournisseur avec le même e-mail vérifié :

    # dans un shell sur l'application studio (clever ssh --alias my-game-studio)
cd "$APP_HOME" && npm run studio-server -- invite --email lea@example.fr --role dev
  1. En owner sur le nouveau fournisseur, retirez les anciennes identités de la liste des membres : elles y figurent encore (et le dernier owner parmi elles ne peut être retiré qu’une fois un nouvel owner créé, étape 7).

Limite · history-keeps-old-names L’histoire du jeu, les commentaires et le journal d’audit gardent les auteurs tels qu’ils ont été écrits, sous les anciennes identités. Rien ne fusionne une ancienne identité dans une nouvelle.

Résultat attendu, et comment le vérifier

Erreurs fréquentes

SymptômeCauseCorrection
Le fournisseur refuse la redirectionLa nouvelle URI de retour pas ajoutée au client studioÉtape 2
forbidden (403) à chaque enregistrementUn onglet encore ouvert sur l’ancien nomRechargez sur le nouveau nom
« not a member of this project » après le changement de fournisseurPas encore réinvitéÉtape 7
Les cadres du jeu restent videsplayUrl pas sur le même domaine que publicUrlDeux sous-domaines d’un même domaine

Fichiers ou données modifiés

STUDIO_CONFIG_JSON (et le secret client pour un changement de fournisseur) ; les domaines des applications ; le client chez le fournisseur ; de nouvelles lignes d’utilisateurs et de membres, des invitations et des entrées d’audit. Les fichiers du jeu et son histoire ne changent pas.

Reprise ou retour arrière

Références

Modifier la source de cette page · Signaler une erreur