Caputchin
Puerta de página en el proxy

Personaliza el reto

Ver como Markdown

La página de verificación que muestra la puerta se configura por clave de sitio, en su página Puerta de proxy del dashboard, y a través de la API de gestión, MCP y Terraform como cualquier otro ajuste. Cada opción de abajo viene por defecto con el comportamiento que ya tienes, así que una clave de sitio que no toques sigue funcionando exactamente igual.

Elige un juego o una casilla

Tipo de reto decide qué hace realmente el visitante:

TipoQué hace el visitanteCuándo encaja
Jugar un juegoJuega un breve juego de verificación en la páginaSeñal más fuerte contra los bots. El valor por defecto. Le cuesta al visitante unos segundos.
Confirmar con una casillaToca una vez mientras corre una comprobación de prueba de trabajoMás rápido, más ligero, sin juego que instalar. Señal más débil.

Dos reglas acotan la elección:

  • Una clave de sitio que exige juego muestra siempre un juego. Si el ajuste Exigir un juego para verificar de la propia clave de sitio está encendido, o tu equipo exige un juego en cada clave, la opción de casilla no está disponible y el dashboard dice qué ajuste la está fijando. Ponerlo por la API devuelve 409 gate-forces-game-mode.
  • Elegir un juego requiere un juego instalado. La clave de sitio necesita al menos un juego instalado con un artefacto reproducible, propio o heredado del equipo. Sin ninguno, elegir el tipo juego devuelve 409 no-games. Encender la puerta por sí solo no: una clave de sitio que no exige juego cae a la casilla, así que la puerta sigue funcionando mientras resuelves lo de los juegos.

Ese último caso conviene saber detectarlo, porque deja un sitio con puerta fuera de servicio: la puerta responde a cada visitante con una página de «Verificación no disponible» hasta que vuelva a haber un juego disponible. También puede llegar sin que nadie toque un ajuste, porque un juego solo cuenta cuando su versión fijada ha pasado nuestra comprobación de determinismo. La página Puerta de proxy avisa siempre que una clave de sitio está en ese estado y enlaza tanto a la lista de juegos como al ajuste que está exigiendo un juego, así que puedes instalar uno o levantar la exigencia y dejar que la casilla tome el relevo.

Fija un idioma o un tema

Tanto Idioma como Tema vienen por defecto en coincidir con el visitante, que es casi siempre lo que quieres:

  • Idioma sigue el idioma del propio navegador del visitante, en los mismos once idiomas que soporta el widget.
  • Tema sigue la preferencia clara u oscura del sistema del visitante, y cambia con ella.

Fija uno en su lugar cuando el sitio con puerta sea de un solo idioma, o cuando esté comprometido con un solo tema y quieras que la verificación lo acompañe en vez de seguir al dispositivo del visitante.

En cualquier caso, la página de verificación lleva la marca de esta clave de sitio: el mismo nombre de marca, logo, colores y enlaces que usa tu widget, resueltos desde la misma clave de sitio. Eso lo configuras una vez, en los ajustes de apariencia de tu widget, y la puerta lo recoge. Los presets de marca personalizados necesitan el plan Apex, igual que para el widget; las opciones de idioma y tema en sí funcionan en todos los planes en los que la puerta está disponible.

La redacción de la propia página de verificación no es personalizable.

Cambia esto solo cuando los valores por defecto choquen con tu app.

Nombre de la cookie (por defecto cpt_gate) es la cookie de origen que tu proxy fija a partir del pase. Renómbrala si tu app ya usa ese nombre, o si corres varias apps con puerta en un mismo dominio y quieres despejarlas por separado.

El campo que se envía por POST a tu callback es siempre cpt_gate, le pongas el nombre que le pongas a la cookie. Así que el parseo del cuerpo en tu callback no cambia nunca; solo cambia el nombre que escribe en Set-Cookie. La respuesta de la puerta incluye un campo cookie_name que le dice a tu callback qué nombre usar.

Ruta del callback (por defecto /__cpt/callback) es la ruta de tu propio origen que recibe el pase y fija la cookie. Muévela si el router de tu app ya se queda con esa ruta. Debe ser una ruta simple en tu origen: sin esquema, sin host, sin query string, sin fragmento.

Acota la puerta a algunas rutas

Cubrir solo estas rutas y No cubrir nunca estas rutas admiten un patrón por línea y dan forma a la configuración de proxy inverso generada. Deja ambas vacías y toda ruta queda con puerta.

Son orientativas: cambian el fragmento que copias, y es tu proxy quien las hace cumplir. Deja siempre sin puerta la subpetición del autorizador y tu ruta de callback, cosa que la configuración generada ya hace por ti.

Un portal de inicio de sesión típico:

Cubrir solo estas rutas:
/
/api/firstfactor

No cubrir nunca estas rutas:
/api/verify
/healthz

Véase también

En esta página