Personaliza el reto
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:
| Tipo | Qué hace el visitante | Cuándo encaja |
|---|---|---|
| Jugar un juego | Juega un breve juego de verificación en la página | Señal más fuerte contra los bots. El valor por defecto. Le cuesta al visitante unos segundos. |
| Confirmar con una casilla | Toca una vez mientras corre una comprobación de prueba de trabajo | Má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.
Renombra la cookie y la ruta del callback
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
/healthzVéase también
- Configura la puerta de página en el proxy: el recorrido con nginx.
- Recetas de proxy inverso: el contrato del callback y los otros proxies.
- Panorama: el concepto y la cookie de paso libre.