Puntos destacados
Antes, una organización era solo una fila que solo podía contener a una persona. Ahora es una página que tú administras: invita a un colega, asígnale un rol y permítele crear keys que la empresa paga. Proxy Finder también dejó de responder "out of tries" y comenzó a especificar el obstáculo exacto con el que chocó, mientras que Browser se aseguró de mostrar siempre la misma información coherente a cada página.
Novedades
Organizaciones que realmente puedes administrar
Antes, agregar a un colega requería enviarnos un correo, lo que llevaba a los equipos a comprar dos suscripciones independientes.
Ahora tu organización tiene su propia página en el Dashboard, respaldada por tres roles. El owner mantiene la suscripción contra la cual se facturan sus keys; por lo tanto, solo existe uno y la propiedad se transfiere. Los admins gestionan el uso, la facturación y los miembros. Los members usan el servicio. Las invitaciones se envían por correo electrónico y funcionan incluso para quienes nunca se han registrado.
Cualquier persona en una organización puede crear keys para ella y transferir una key personal a la organización, evitando que un desarrollador use una key personal que le cobre por tareas de la empresa. El consumo de una key de la organización se factura al plan del owner, y cada confirmación indica qué plan asume el costo. Cualquier miembro puede renombrar una key; regenerar, deshabilitar y eliminar quedan restringidos a owners y admins, ya que esas acciones interrumpen el acceso de todos los colegas de inmediato.
Un filtro único de Owner se aplica en Overview, Detailed Metrics, Recent Activity y tu lista de keys. Usage & Limits y Billing permanecen privados, ya que los miembros no necesitan consultar la cuota del owner.
Proxy Finder deja de hacer suposiciones
El mensaje "Download maxTry limit reached" se mostraba idéntico si todas las salidas estaban bloqueadas, si todas las salidas estaban caídas o si obtuvimos la página auténtica 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 fueron rechazadas por un sistema de defensa identificado y qué proveedores intervinieron, cuántas rechazó tu validate.status y cuántas devolvieron HTTP 200 sin defensas detectadas y fallaron únicamente por tu validate.data. Se incluye también una frase clara a modo de resumen.
Ese último recuento es el más valioso. Una regla de contenido que no coincide parece exactamente un bloqueo total bajo las métricas anteriores, y ningún reintento podrá solucionarlo. (Más información sobre cómo las reglas de validación determinan el éxito.)
La otra parte corresponde al perfil. Proxy Finder rotaba las salidas pero nunca la firma del cliente, por lo que un sitio que rechazaba un perfil de navegador lo rechazaba en todas las salidas del pool. Ahora, un rechazo cambia el perfil en un reintento programado, manteniendo constantes las requests y los créditos por tarea. Si fijas profile tú mismo, nada cambia. En los destinos más complejos, ten en cuenta que la salida final sigue teniendo más peso 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 era la request, por lo que una sola request podía afirmar que era Windows, un Mac y una versión que la flota no estaba ejecutando, todo al mismo tiempo. Ahora hay un solo valor, decidido una sola vez y propagado a todas partes: el inicio, 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 es importante porque las cookies de autorización están vinculadas a la salida y al User-Agent juntos. La consulta al 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 acumulan.
Otras tres mejoras llegaron junto 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. Una configuración de 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 deberían. Una URL que terminaba en
#reviewssolía agotar el tiempo de espera siempre. 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 en buen estado, no solo en sus páginas de bloqueo, y Auto no podía distinguir entre ambas, por lo que las páginas correctas escalaban a un navegador sin necesidad. En un sitio de alquiler de coches, eso significaba 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. En el modelo de pago por éxito estos valores difieren, y la diferencia es dinero real, por lo que ambos están en la tarjeta: facturado como el número principal y gastado debajo, por producto y en total. La tarjeta de Requests se divide de la misma manera. El período y el detalle también son controles independientes, 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 para transferir parámetros ahora ofrece el perfil de la última response, de modo que una request enviada con un perfil que no escribiste replica 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 A/B en producción estuvo a la par en objetivos fáciles y mejoró en los difíciles, donde la mediana de tiempo por página pasó de 5.5s a 3.8s mientras que la latencia de toda la flota no varió. Un objetivo tuvo el resultado 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.