Puntos destacados
La selección del perfil de navegador ahora es un parámetro por request. Especifica el navegador y el sistema operativo que deseas, y tanto la huella digital como los headers coincidirán con ello. Single aprendió a completar dos validaciones más esta semana (las computacionales de SiteGround y eBay) sin necesidad de iniciar Browser. Además, la vista de Activity en el Dashboard ahora registra lo que solicitaste, no la infraestructura interna que se ejecutó por debajo.
Novedades
Elige tu perfil de navegador por request
Hasta ahora, unblocker: true elegía una sola firma (la que fuera nuestra opción predeterminada) y eso era todo. Ahora puedes especificar una:
{ "url": "https://example.com", "unblocker": true, "profile": "firefox147" }
o solicita una combinación 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, evitando que un error tipográfico envíe silenciosamente una firma que nunca solicitaste.
El catálogo completo está disponible en GET /api/profiles. Es público (no requiere clave), ya que es una lista de capacidades y no un secreto. Al momento de escribir esto, existen 79 presets 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 perfila las requests según el sistema operativo, o si tu equipo está haciendo pruebas A/B para ver qué stack supera un bloqueo específico, ahora puedes mantener esa variable fija mientras todo lo demás cambia.
Single completa las comprobaciones computacionales de SiteGround y eBay
Dos defensas que antes obligaban a recurrir a Browser ahora se resuelven en Single. eBay utiliza su propio desafío de proof-of-work (un puzzle Argon2) y SiteGround ejecuta su propia comprobación en una parte considerable de la web de alojamiento compartido. Ambas se resuelven sin renderizar, lo que significa que la response se entrega como una única request HTTP y se factura según esa tarifa.
La señal de defensa en las responses también se amplió. Las responses de Browser ahora incluyen defenses: { present, cleared }, lo que te permite ver qué proveedor estaba delante de la página y si logramos superarlo. La facturación sigue la misma regla: cualquier proveedor que superemos se atribuye, sin importar la marca. Antes de esta actualización, solo un servicio de comprobación se facturaba como página interactiva. Ahora se suman tres más.
Vista de actividad rediseñada en el Dashboard
Dos columnas en la lista de actividad del Dashboard mostraban información incorrecta. El método HTTP siempre mostraba POST en cada fila (todos nuestros endpoints son POST, por lo que la columna era una constante sin valor informativo). Y la IP del cliente en las llamadas del Playground registraba desde dónde llamaba el Playground, no la persona que hacía clic en Run.
Ambos problemas están solucionados. La columna de 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 autenticado, transmitida dentro de un token firmado del Playground para que un cliente de la API no pueda falsificarla.
Aprovechamos para rediseñar el resto de la vista. La tabla se ajusta a la pantalla de una laptop sin ocultar columnas, la columna de producto se integra en la línea de la request y el panel de detalles ahora cuenta con pestañas para que la request, la response y el resumen de defensas tengan su propio desplazamiento independiente.
Facturación: 3D Secure al cambiar de plan
Si el emisor de tu tarjeta requería una confirmación 3DS para cambiar de plan (y 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 durante el último mes y pareció que no ocurrió nada, esa fue la razón.
Bajo el capó
El Playground rechaza construir un header de response a partir de los datos de un sitio obtenido (un tipo de error de inyección de headers que detectamos a tiempo). Un endpoint de facturación en el Dashboard verifica que quien realiza la llamada sea propietario del recurso antes de responder, cerrando una posible vulnerabilidad IDOR.
El pipeline de despliegue en sí recibió una semana intensa de correcciones después de que una caída el día 6 llenara el disco del host de despliegue a mitad de una compilación. Ahora, cada servicio se niega a compilar si no hay suficiente espacio en disco, los despliegues se serializan en lugar de competir entre sí, el gateway permanece activo cuando un backend oscila y los servicios realmente terminan con SIGTERM en lugar de colgarse hasta que los matan treinta segundos después.
Durante mucho tiempo, "qué firma de navegador usar" fue una decisión que tomamos por ti. Ya no tiene que ser así.