Puntos clave
Antes, una organización era una fila que solo podía albergar a una persona. Ahora es una página que tú gestionas: invita a un colega, asígnale un rol, permítele crear keys que paga la empresa. Proxy Finder también dejó de responder "out of tries" y empezó a identificar el bloqueo específico con el que se topó, y Browser pasó la semana asegurándose de contarle la misma historia dos veces a una página.
Novedades
Organizaciones que realmente puedes gestionar
Antes, añadir a un colega implicaba enviarnos un email, por lo que los equipos terminaban comprando dos suscripciones independientes.
Tu organización ahora tiene su propia página en el Dashboard, respaldada por tres roles. El owner mantiene la suscripción contra la que se facturan sus keys, por lo que hay exactamente uno y la propiedad se transfiere. Los admins gestionan el uso, la facturación y los miembros. Los members usan la plataforma. Las invitaciones se envían por email y funcionan incluso para alguien que nunca se ha registrado.
Cualquier persona en una organización puede crear keys pertenecientes a ella y transferir una key personal a la misma, de modo que un developer no necesita una key personal que le cobre por el trabajo de la empresa. El uso de una key de la organización se factura al plan del owner, y cada confirmación indica qué plan asume el costo. Cualquier member puede renombrar una key; regenerar, deshabilitar y eliminar quedan en manos de owners y admins, ya que esas acciones detienen el trabajo de cualquier colega que la esté usando en el instante en que ocurren.
Un filtro de Owner se aplica en Overview, Detailed Metrics, Recent Activity y tu lista de keys. Usage & Limits y Billing siguen siendo personales, ya que un member no tiene por qué ver la cuota del owner.
Proxy Finder deja de adivinar
"Download maxTry limit reached" se leía igual si todos los nodos de salida estaban bloqueados, si todos estaban caídos, o si obtuvimos la página legítima y tu propia regla la descartó. Esos tres casos requieren soluciones completamente distintas.
Una tarea fallida ahora incluye attemptReport: cuántas salidas nunca respondieron, cuántas rechazó un sistema de defensa reconocido y qué proveedores lo hicieron, cuántas rechazó tu validate.status y cuántas devolvieron HTTP 200 sin defensas visibles y solo fallaron en tu validate.data. Viene acompañada de una frase de resumen clara.
Pero ese último recuento es el fundamental. Una regla de contenido que no coincide parece exactamente un bloqueo desde cualquier ángulo que medíamos antes, y ningún reintento lo resolverá. (Más información sobre cómo las reglas de validación determinan el éxito.)
La otra parte es el perfil. Proxy Finder rotaba los nodos de salida pero nunca la firma del cliente, por lo que un sitio que rechazaba un perfil de navegador lo rechazaba en cada salida del pool. Ahora, un rechazo cambia el perfil en un reintento que ya estaba programado, por lo que las requests y los créditos por tarea no varían. Si fijas profile manualmente, nada cambia. Ten en cuenta que, en los objetivos más complejos, el nodo de salida al que llegas sigue importando más que el perfil que envías.
Browser deja de contradecirse
Pedir un User-Agent a Browser solía ser peor que no pedirlo. Tres capas distintas tenían su propia idea de quién hacía la request, por lo que una sola request podía afirmar que era Windows, Mac y una versión que la flota ni siquiera ejecutaba, todo al mismo tiempo. Ahora hay un solo valor, decidido una vez y transportado a todas partes: el lanzamiento, la página y los workers que la página inicia.
Los client hints se derivan de esa cadena, por lo que sec-ch-ua, la plataforma y navigator.platform coinciden con ella. La response devuelve la cadena que realmente enviamos, lo cual importa porque las clearance cookies están vinculadas a la salida y al User-Agent de forma conjunta. La consulta del renderer también responde de la misma manera en el documento y en un worker ahora, una más de las señales débiles que se van sumando.
Llegaron tres mejoras más con esto:
- El reloj sigue a la salida. Browser se ejecuta en la zona horaria del país donde se encuentra tu salida, por lo que una página que renderiza horas locales muestra lo que vería un visitante de allí. Cuando no se conoce el país, el reloj no se modifica.
- WebRTC se mantiene en la misma ruta que todo lo demás. La configuración de un proxy cubre lo que un navegador envía a través de TCP. WebRTC no está en esa ruta, por lo que una página que le solicita candidatos ICE obtiene una respuesta independiente. Browser desactiva eso cada vez que una request incluye una salida.
- Las URL con anclas cuestan lo que deben. Una URL que terminaba en
#reviewssolía agotar el tiempo de espera en cada ocasión. Ahora vuelve a funcionar a velocidad normal.
Rutas más económicas y un Dashboard que cuenta con precisión
Imperva inyecta su script en páginas saludables, no solo en sus páginas de rechazo, y Auto no podía distinguir entre ambas, por lo que las páginas saludables escalaban a un browser sin necesidad. En un sitio de alquiler de autos, eso suponía 75 créditos y 27.5 segundos a lo largo de seis intentos; ahora es un solo intento, 10 créditos y unos seis segundos y medio. Algunos sitios te entregan una sesión dentro del rechazo con el que responden a una request sin sesión, y los cuatro motores ahora la devuelven de inmediato antes de escalar.
La tarjeta de créditos de Overview mostraba todo lo gastado y lo etiquetaba como facturado. Con el modelo pay-for-success estos valores difieren, y la diferencia es dinero real, por lo que ambos están en la tarjeta: el monto facturado como número principal y el gastado debajo, por producto y en total. La tarjeta de Requests se divide de la misma manera. El período y el nivel de detalle también son controles separados, desde 30 minutos hasta un año más un rango personalizado, retirando el selector que decía "1D" y abría treinta días.
En el Playground, el botón de transferir ahora ofrece el perfil de la última response, de modo que una request enviada con un perfil que no escribiste reproduce la versión que funcionó. Cada parámetro está en la referencia de la API.
Bajo el capó
Proxy Finder guarda más historial por host: 32 salidas en lugar de una docena. En un test A/B en vivo estuvo a la par en objetivos fáciles y mejoró en los difíciles, donde la mediana de tiempo por página bajó de 5.5s a 3.8s mientras que la latencia global de la flota no varió. Un objetivo tuvo un comportamiento opuesto y todavía no sabemos por qué, así que tendrá su propia medición.
Una tarea que va a fallar fallará de todos modos. La diferencia está en si cierras el ticket en un minuto o te pasas la tarde midiendo lo incorrecto.