Caputchin
Porte de page au proxy

Personnalise le défi

Voir en Markdown

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, 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 :

TypeCe que fait le visiteurQuand ça convient
Jouer à un jeuJoue un court jeu de vérification dans la pageSignal plus fort contre les bots. La valeur par défaut. Coûte quelques secondes au visiteur.
Confirmer avec une case à cocherTouche une fois pendant qu'un contrôle de preuve de travail tournePlus 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.

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.

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.

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

Sur cette page