--- type: how-to title: Personalize o desafio summary: Escolha um jogo ou uma caixa de seleção de um toque só, fixe o idioma e o tema, e renomeie o cookie e o caminho do callback que o portão usa na sua origem. --- A página de verificação que o portão mostra é configurada por chave de site, na página **Portão de proxy** dela no painel, e pela [API de gestão](/docs/automation/management-api), MCP e Terraform como toda outra configuração. Cada opção abaixo já vem no comportamento que você tem hoje, então uma chave de site em que você nunca mexe continua funcionando exatamente como funcionava. ## Escolha um jogo ou uma caixa de seleção **Tipo de desafio** decide o que o visitante de fato faz: | Tipo | O que o visitante faz | Quando se encaixa | |---|---|---| | **Jogar um jogo** | Joga um jogo curto de verificação na página | Sinal mais forte contra bots. O padrão. Custa alguns segundos ao visitante. | | **Confirmar com uma caixa de seleção** | Toca uma vez enquanto roda uma checagem de prova de trabalho | Mais rápido, mais leve, sem jogo para instalar. Sinal mais fraco. | Duas regras limitam a escolha: - **Uma chave de site que exige jogo sempre mostra um jogo.** Se a configuração **Exigir um jogo para verificar** da própria chave de site estiver ligada, ou se a sua equipe exigir um jogo em toda chave, a opção de caixa de seleção fica indisponível e o painel diz qual configuração está prendendo isso. Definir isso pela API devolve `409 gate-forces-game-mode`. - **Escolher um jogo exige um jogo instalado.** A chave de site precisa de pelo menos um jogo instalado com um artefato reproduzível, próprio ou herdado da equipe. Sem nenhum, *escolher* o tipo jogo devolve `409 no-games`. Ligar o portão por si só não devolve: uma chave de site que não exige jogo cai para a caixa de seleção, então o portão continua funcionando enquanto você resolve a questão dos jogos. Se o último jogo instalado for removido depois, uma chave de site que exige um jogo para de servir a verificação em vez de cair para outra coisa em silêncio, porque uma caixa de seleção não consegue verificar em uma chave que exige jogo. Uma chave que *não* exige um jogo cai para a caixa de seleção, para que o seu site continue alcançável. Vale saber reconhecer esse último caso, porque ele tira do ar um site com portão: o portão responde a cada visitante com uma página de "Verificação indisponível" até haver um jogo disponível de novo. Ele também pode chegar sem ninguém mexer em configuração nenhuma, já que um jogo só conta quando a sua versão fixada passa na nossa checagem de determinismo. A página Portão de proxy avisa sempre que uma chave de site está nesse estado e liga tanto para a lista de jogos quanto para a configuração que está exigindo um jogo, então você pode instalar um ou tirar a exigência e deixar a caixa de seleção assumir. ## Fixe um idioma ou um tema Tanto **Idioma** quanto **Tema** vêm por padrão em *acompanhar o visitante*, que é quase sempre o que você quer: - **Idioma** segue o idioma do próprio navegador do visitante, nos mesmos onze idiomas que o widget suporta. - **Tema** segue a preferência clara ou escura do sistema do visitante, e muda junto com ela. Fixe um em vez disso quando o site protegido for de um idioma só, ou quando ele estiver casado com um tema só e você quiser que a verificação acompanhe esse tema em vez de seguir o aparelho do visitante. De todo jeito, a página de verificação leva **a marca desta chave de site**: o mesmo nome de marca, logo, cores e links que o seu widget usa, resolvidos a partir da mesma chave de site. Você configura isso uma vez, nas configurações de aparência do seu widget, e o portão pega de lá. Presets de marca personalizados precisam do plano Apex, como já precisam para o widget; as opções de idioma e tema em si funcionam em todo plano em que o portão está disponível. O texto da própria página de verificação não é personalizável. ## Renomeie o cookie e o caminho do callback Mude isso só quando os padrões conflitarem com a sua app. **Nome do cookie** (padrão `cpt_gate`) é o cookie próprio que o seu proxy define a partir do passe. Renomeie-o se a sua app já usa esse nome, ou se você roda vários apps protegidos em um domínio só e quer liberá-los de forma independente. **Renomear de um nome personalizado para outro tira o seu site com portão do ar até você copiar de novo o trecho do proxy reverso na página Portão de proxy da sua chave de site e recarregar o seu proxy.** O portão procura o nome novo enquanto o seu proxy ainda escreve o antigo, então o visitante é mandado para a verificação, passa nela, e é mandado direto de volta para ela, num laço que termina em um limite de taxa. Já sair do `cpt_gate` padrão é seguro fazer primeiro e ligar depois, porque o portão continua reconhecendo o padrão. **O campo enviado por POST para o seu callback é sempre `cpt_gate`**, qualquer que seja o nome que você dê ao cookie. Ou seja, a leitura do corpo no seu callback nunca muda; muda só o nome que ele escreve no `Set-Cookie`. A resposta do portão inclui um campo `cookie_name` dizendo ao seu callback qual nome usar. **Caminho do callback** (padrão `/__cpt/callback`) é a rota na sua própria origem que recebe o passe e define o cookie. Mova-o se o roteador da sua app já ocupa esse caminho. Ele precisa ser um caminho simples na sua origem: sem esquema, sem host, sem query string, sem fragmento. ## Limite o portão a alguns caminhos **Cobrir só estes caminhos** e **Nunca cobrir estes caminhos** aceitam um padrão por linha e moldam a configuração de proxy reverso gerada. Deixe os dois vazios e todo caminho fica protegido. Eles são indicativos: mudam o trecho que você copia, e quem faz cumprir é o seu proxy. Deixe sempre a sub-requisição do autorizador e o seu caminho de callback sem portão, o que a configuração gerada já faz por você. Um portal de login típico: ``` Cobrir só estes caminhos: / /api/firstfactor Nunca cobrir estes caminhos: /api/verify /healthz ``` ## Veja também - [Configure o portão de página no proxy](/docs/proxy-page-gate/set-up): o passo a passo do nginx. - [Receitas de proxy reverso](/docs/proxy-page-gate/reverse-proxy-recipes): o contrato do callback e os outros proxies. - [Visão geral](/docs/proxy-page-gate/overview): o conceito e o cookie de liberação.