ChrisM-PekandCursor
8de569bbf1
Require a site-issued SANC code when the server has app URL and API token configured, with replay-safe ledger binding and FR/EN UI including galactic code display. Co-authored-by: Cursor <cursoragent@cursor.com>
58 lines
2.8 KiB
Markdown
58 lines
2.8 KiB
Markdown
# beta.144 — Code d’accès à la création
|
||
|
||
Le site accepte la candidature, whitelist le pseudo et envoie un code `SANC-XXXX-XXXX`.
|
||
Hello World demande ce code avant de créer le personnage. Le client ne parle pas
|
||
au site. Seul le serveur appelle l’API, avec le jeton `SANCTUARY_API_TOKEN`.
|
||
|
||
Sans ces réglages, Hello World reste celui de beta.143 : biographie, couleur et
|
||
familier, sans code. Dès que l’URL et le jeton sont présents, un nouveau
|
||
personnage exige un code reconnu. Un habitant déjà enregistré entre sans écran.
|
||
|
||
## Réglage serveur
|
||
|
||
Variables d’environnement, ou fichier `config/sanctuary/access.json` si une
|
||
variable manque :
|
||
|
||
```json
|
||
{"appUrl":"https://exemple.sanctuary","token":"..."}
|
||
```
|
||
|
||
`appUrl` est l’origine du site, sans barre finale. Le serveur appelle
|
||
`POST {appUrl}/api/v1/access-codes/verify` puis `redeem`. Le jeton n’est pas
|
||
écrit dans les logs, le client ou le pack. Une URL ou un jeton illisible ferme
|
||
la création : aucun personnage n’est inventé hors ligne.
|
||
|
||
## Parcours
|
||
|
||
1. La whitelist laisse passer le pseudo. L’écran s’ouvre tant que l’UUID n’a pas
|
||
d’habitant.
|
||
2. Le joueur saisit le code. L’affichage du champ et de l’exemple utilise
|
||
l’alphabet galactique standard (`minecraft:alt`, la police de la table
|
||
d’enchantement). La valeur envoyée reste le texte tapé. Un format complet
|
||
déclenche `verify`, pas chaque frappe. « Code reconnu » n’écrit rien.
|
||
3. Confirmer envoie le code de la session, la biographie, la couleur et le
|
||
familier. Le pseudo envoyé au site est celui de la session.
|
||
4. `redeem` répond `redeemed` avec `discord_id` : le lien est enregistré, puis
|
||
l’habitant est créé. Les connexions suivantes sautent l’écran.
|
||
5. Erreur, site injoignable ou jeton refusé : le joueur reste sur Hello World.
|
||
|
||
Une déconnexion avant `redeemed` ne consomme pas le code. Si le site a répondu
|
||
`redeemed` et que l’écriture de l’habitant est interrompue, le lien Discord
|
||
reste dans `data/sanctuary-access.json` (`pending`, schéma 1, graine du monde).
|
||
La confirmation suivante termine le personnage sans rappeler `redeem`.
|
||
|
||
Si le code est déjà consommé et que le site ne renvoie plus `discord_id`, le
|
||
joueur reste bloqué avec un message de reprise. Le site doit alors renvoyer
|
||
`minecraft_username` et `discord_id` pour le même pseudo. Le mod accepte cette
|
||
réponse, que `valid` soit vrai ou faux, et finit la création.
|
||
|
||
Le registre des habitants ne change pas. Le Discord est un fichier à part.
|
||
Un fichier illisible est conservé et refuse l’accueil.
|
||
|
||
## Limites
|
||
|
||
Le gel dans le monde n’est pas ajouté : Hello World reste avant l’entrée, comme
|
||
aujourd’hui. Inventaire, commandes et dimensions ne sont pas accessibles tant
|
||
que l’habitant n’existe pas. La whitelist RCON reste celle du site. Un pseudo
|
||
ajouté à la main, sans code, voit l’écran sans pouvoir le valider.
|