--- type: how-to title: Personnalise le défi summary: Choisis un jeu ou une case à cocher en un geste, fige la langue et le thème, et renomme le cookie et le chemin du callback que la porte utilise sur ton origine. --- La page de vérification que montre la porte se règle par clé de site, sur sa page **Porte de proxy** dans le tableau de bord, et via l'[API de gestion](/docs/automation/management-api), MCP et Terraform comme tout autre réglage. Chaque option ci-dessous garde par défaut le comportement que tu as déjà, donc une clé de site à laquelle tu ne touches pas continue de marcher exactement pareil. ## Choisis un jeu ou une case à cocher **Type de défi** décide de ce que le visiteur fait vraiment : | Type | Ce que fait le visiteur | Quand ça convient | |---|---|---| | **Jouer à un jeu** | Joue un court jeu de vérification dans la page | Signal plus fort contre les bots. La valeur par défaut. Coûte quelques secondes au visiteur. | | **Confirmer avec une case à cocher** | Touche une fois pendant qu'un contrôle de preuve de travail tourne | Plus rapide, plus léger, aucun jeu à installer. Signal plus faible. | Deux règles encadrent le choix : - **Une clé de site qui exige un jeu montre toujours un jeu.** Si le réglage **Exiger un jeu pour vérifier** de la clé de site elle-même est actif, ou si ton équipe exige un jeu sur chaque clé, l'option case à cocher n'est pas disponible et le tableau de bord dit quel réglage la fige. La régler via l'API renvoie `409 gate-forces-game-mode`. - **Choisir un jeu demande un jeu installé.** La clé de site a besoin d'au moins un jeu installé avec un artefact rejouable, le sien ou hérité de l'équipe. Sans aucun, *choisir* le type jeu renvoie `409 no-games`. Activer la porte à elle seule, non : une clé de site qui n'exige pas de jeu bascule sur la case à cocher, donc la porte marche toujours pendant que tu règles la question des jeux. Si le dernier jeu installé est retiré plus tard, une clé de site qui exige un jeu cesse de servir la vérification plutôt que de basculer en silence, parce qu'une case à cocher ne peut pas vérifier sur une clé qui exige un jeu. Une clé qui n'exige *pas* de jeu bascule sur la case à cocher, pour que ton site reste joignable. Ce dernier cas vaut la peine d'être repéré, parce qu'il met un site protégé hors service : la porte répond à chaque visiteur par une page « Vérification indisponible » jusqu'à ce qu'un jeu redevienne disponible. Il peut aussi survenir sans que personne ne change un réglage, puisqu'un jeu ne compte qu'une fois sa version épinglée passée par notre contrôle de déterminisme. La page Porte de proxy prévient dès qu'une clé de site est dans cet état et pointe à la fois vers la liste des jeux et vers le réglage qui exige un jeu, pour que tu puisses soit en installer un, soit lever l'exigence et laisser la case à cocher prendre le relais. ## Fige une langue ou un thème **Langue** et **Thème** sont tous deux par défaut sur *suivre le visiteur*, ce qui est presque toujours ce que tu veux : - **Langue** suit la langue du navigateur du visiteur, dans les onze mêmes langues que le widget prend en charge. - **Thème** suit la préférence claire ou sombre du système du visiteur, et change avec elle. Fige-en un à la place quand le site protégé est monolingue, ou quand il est engagé sur un seul thème et que tu veux que la vérification s'y accorde plutôt que de suivre l'appareil du visiteur. Dans les deux cas, la page de vérification porte **la marque de cette clé de site** : le même nom de marque, le même logo, les mêmes couleurs et les mêmes liens que ton widget, résolus depuis la même clé de site. Tu configures ça une fois, dans les réglages d'apparence de ton widget, et la porte le reprend. Les presets de marque sur mesure demandent le plan Apex, comme pour le widget ; les options de langue et de thème, elles, marchent sur tous les plans où la porte est disponible. La formulation de la page de vérification elle-même n'est pas personnalisable. ## Renomme le cookie et le chemin du callback Ne change ça que quand les valeurs par défaut se heurtent à ton app. **Nom du cookie** (par défaut `cpt_gate`) est le cookie propriétaire que ton proxy pose à partir du laissez-passer. Renomme-le si ton app utilise déjà ce nom, ou si tu fais tourner plusieurs apps protégées sur un même domaine et que tu veux les dégager indépendamment. **Renommer d'un nom personnalisé à un autre met ton site protégé hors service jusqu'à ce que tu recopies l'extrait de proxy inverse depuis la page Porte de proxy de ta clé de site et recharges ton proxy.** La porte cherche le nouveau nom pendant que ton proxy écrit encore l'ancien, donc un visiteur est envoyé à la vérification, la réussit, et y est renvoyé aussitôt, dans une boucle qui se termine sur une limite de débit. Quitter le `cpt_gate` par défaut, en revanche, peut se faire d'abord et se câbler ensuite sans risque, parce que la porte reconnaît toujours la valeur par défaut. **Le champ POSTé vers ton callback est toujours `cpt_gate`**, quel que soit le nom que tu donnes au cookie. Donc la lecture du corps dans ton callback ne change jamais ; seul change le nom qu'il écrit dans `Set-Cookie`. La réponse de la porte inclut un champ `cookie_name` qui dit à ton callback quel nom utiliser. **Chemin du callback** (par défaut `/__cpt/callback`) est la route sur ta propre origine qui reçoit le laissez-passer et pose le cookie. Déplace-le si le routeur de ton app occupe déjà ce chemin. Ce doit être un chemin simple sur ton origine : pas de schéma, pas d'hôte, pas de query string, pas de fragment. ## Restreins la porte à certains chemins **Ne couvrir que ces chemins** et **Ne jamais couvrir ces chemins** prennent un motif par ligne et façonnent la configuration de proxy inverse générée. Laisse les deux vides et chaque chemin est protégé. Ils sont indicatifs : ils changent l'extrait que tu copies, et c'est ton proxy qui les fait respecter. Laisse toujours la sous-requête de l'autorisateur et ton chemin de callback sans porte, ce que la configuration générée fait déjà pour toi. Un portail de connexion typique : ``` Ne couvrir que ces chemins : / /api/firstfactor Ne jamais couvrir ces chemins : /api/verify /healthz ``` ## Voir aussi - [Configurer la porte de page au proxy](/docs/proxy-page-gate/set-up) : la marche à suivre nginx. - [Recettes de proxy inverse](/docs/proxy-page-gate/reverse-proxy-recipes) : le contrat du callback et les autres proxies. - [Vue d'ensemble](/docs/proxy-page-gate/overview) : le concept et le cookie de laissez-passer.