Destacados
La selección del perfil de navegador ahora se configura por request. Indica el navegador y el sistema operativo que quieres, y el fingerprint junto con los headers describirán lo mismo. Single aprendió a resolver dos defensas más esta semana (SG-Captcha de SiteGround y el desafío Argon2 de eBay) sin necesidad de iniciar Browser. Y la vista Activity del Dashboard ahora registra lo que solicitaste, no la infraestructura subyacente que se ejecutó.
Novedades
Elige tu perfil de navegador por request
Hasta ahora, unblocker: true elegía una firma (la que fuera nuestra opción por defecto) y eso era todo. Ahora puedes especificar una:
{ "url": "https://example.com", "unblocker": true, "profile": "firefox147" }
o solicita un par de navegador y sistema operativo:
{ "url": "https://example.com", "unblocker": true, "browser": "Chrome", "os": "Windows 10" }
La API rechaza combinaciones desconocidas por nombre y enumera lo que SÍ está disponible, de modo que un error tipográfico no puede enviar silenciosamente una firma que nunca pediste.
El catálogo completo se encuentra en GET /api/profiles. Es público (no necesita clave), porque es una lista de capacidades y no un secreto. En el momento de escribir esto hay 79 perfiles predefinidos en Chrome, Firefox, Edge, Safari y Tor, sobre Windows, macOS, Android e iOS. El Playground lee de la misma lista, por lo que el menú desplegable siempre muestra exactamente lo que tu código puede solicitar.
Por qué es importante: si tu objetivo clasifica las requests por sistema operativo, o tu equipo está haciendo pruebas A/B de qué stack logra pasar un muro en particular, ahora mantienes esa variable constante mientras todo lo demás cambia.
Single resuelve SG-Captcha y proof-of-work de eBay
Dos defensas que solían forzar un salto a través de Browser ahora se resuelven en Single. eBay envía su propio desafío de proof-of-work (un rompecabezas Argon2) y SiteGround protege una parte de la web de alojamiento compartido con SG-Captcha. Ambos se resuelven sin renderizar, lo que significa que la response regresa en forma de una única request HTTP y se tarifa en consecuencia.
La señal de defensa en las responses también creció. Las responses de Browser ahora incluyen defenses: { present, cleared }, para que puedas ver qué proveedor estaba frente a la página y si logramos pasar. La facturación sigue la misma regla: cualquier proveedor que superemos recibe la atribución, sin importar la marca. Cloudflare era la única resolución de pago antes de este período. Akamai Bot Manager, SG-Captcha y el desafío de eBay ahora se encuentran junto a él.
Vista de Activity reconstruida en el Dashboard
Dos columnas en la lista Activity del Dashboard mostraban información incorrecta. El método HTTP siempre decía POST en cada fila (todos nuestros endpoints son POST, por lo que la columna era una constante que no te decía nada). Y la IP del cliente en las llamadas del Playground registraba desde dónde llamaba el Playground, no a la persona que hacía clic en Run.
Ambos están corregidos. La columna del método ahora muestra el verbo que enviaste dentro del cuerpo de la request. La IP del cliente en las filas del Playground ahora muestra la IP del navegador del usuario que ha iniciado sesión, transportada dentro de un token firmado del Playground para que un cliente de la API no pueda falsificarlo.
El resto de la vista fue reconstruido mientras estábamos en ello. La tabla encaja en un portátil sin ocultar columnas, la columna del producto se pliega en la línea de la request, y el panel de detalles ganó pestañas para que la request, la response y el resumen de defensa tengan cada uno su propio desplazamiento.
Facturación: 3D Secure en cambio de plan
Si el emisor de tu tarjeta requería una confirmación 3DS para un cambio de plan (no solo en la suscripción inicial), ese paso no se ejecutaba y el cambio se revertía silenciosamente. Ahora sí se ejecuta. Si intentaste cambiar de plan en el último mes y parecía que no había pasado nada, este es el motivo.
Bajo el capó
El Playground rechaza construir un header de response a partir de los datos de un sitio obtenido (una clase de error de inyección de header que detectamos pronto). Un endpoint de facturación en el Dashboard verifica que la persona que llama es dueña del recurso antes de responder, cerrando una vulnerabilidad IDOR.
El propio pipeline de despliegue recibió las correcciones de una semana difícil después de que una interrupción el día 6 llenara el disco del host de despliegue en medio de la compilación. Cada servicio se niega a compilar sin espacio libre en disco, los despliegues se serializan en lugar de competir, el gateway se mantiene activo cuando un backend falla, y los servicios realmente terminan con SIGTERM en lugar de colgarse hasta que son destruidos treinta segundos después.
Durante mucho tiempo, "qué firma de navegador usar" era una decisión que tomábamos por ti. Ya no tiene que ser así.