Điểm nổi bật
Khả năng chọn browser profile hiện đã có thể tùy chỉnh theo từng request. Chỉ định trình duyệt và hệ điều hành bạn muốn, fingerprint cùng với các header sẽ khớp hoàn toàn với cấu hình đó. Single đã được cập nhật để vượt qua thêm hai bài kiểm tra trong tuần này (các bài kiểm tra tính toán của SiteGround và eBay) mà không cần khởi chạy Browser. Ngoài ra, giao diện Activity trên Dashboard hiện ghi lại chính xác nội dung bạn đã yêu cầu, thay vì quy trình kỹ thuật chạy ngầm bên dưới.
Có gì mới
Chọn browser profile theo từng request
Trước đây, unblocker: true chỉ chọn một signature mặc định duy nhất. Hiện tại bạn có thể chỉ định một signature cụ thể:
{ "url": "https://example.com", "unblocker": true, "profile": "firefox147" }
hoặc yêu cầu một cặp trình duyệt và hệ điều hành:
{ "url": "https://example.com", "unblocker": true, "browser": "Chrome", "os": "Windows 10" }
API sẽ từ chối các kết hợp không xác định theo tên và liệt kê những gì hiện CÓ SẴN, nhờ đó lỗi chính tả không thể âm thầm gửi đi một chữ ký mà bạn chưa từng yêu cầu.
Danh mục đầy đủ có tại GET /api/profiles. Mục này công khai (không cần khóa API), vì đây là danh sách tính năng chứ không phải thông tin bí mật. Tại thời điểm viết bài, hiện có 79 preset trên Chrome, Firefox, Edge, Safari và Tor, hoạt động trên Windows, macOS, Android và iOS. Playground đọc từ cùng một danh sách, vì vậy menu thả xuống luôn hiển thị chính xác những gì code của bạn có thể yêu cầu.
Lý do điều này quan trọng: nếu mục tiêu của bạn phân tích request theo hệ điều hành, hoặc nhóm của bạn đang thử nghiệm A/B xem ngăn xếp nào vượt qua được một rào cản cụ thể, bạn hiện có thể giữ cố định biến số đó trong khi mọi thứ khác thay đổi.
Single hoàn thành các bước kiểm tra tính toán của SiteGround và eBay
Hai cơ chế phòng thủ từng buộc phải chuyển hướng qua Browser giờ đây đã được xử lý xong trên Single. eBay triển khai thử thách proof-of-work riêng (một câu đố Argon2) và SiteGround chạy quy trình kiểm tra riêng trên một phần lớn hạ tầng shared hosting. Cả hai đều được giải quyết mà không cần render, nghĩa là response trả về dưới dạng một HTTP request đơn lẻ và được tính phí tương ứng.
Tín hiệu phòng thủ trong response cũng được mở rộng. Các response từ Browser hiện mang theo defenses: { present, cleared }, để bạn có thể thấy nhà cung cấp giải pháp bảo mật nào đang đứng trước trang và liệu chúng tôi đã vượt qua thành công hay chưa. Cách tính phí tuân theo cùng một quy tắc: bất kỳ nhà cung cấp nào chúng tôi vượt qua đều được ghi nhận, bất kể thương hiệu nào. Trước giai đoạn này, chỉ có một dịch vụ kiểm tra được tính phí như một trang tương tác. Hiện đã có thêm ba dịch vụ nữa được áp dụng.
Tái cấu trúc chế độ xem Activity trong Dashboard
Hai cột trong danh sách Activity của Dashboard từng hiển thị không đúng. HTTP method luôn hiển thị POST trên mọi hàng (tất cả các endpoint của chúng tôi đều là POST, vì vậy cột này là một hằng số vô nghĩa). Và IP client trên các lệnh gọi Playground từng ghi lại địa chỉ nơi Playground gửi lệnh gọi, chứ không phải người dùng đang nhấn Run.
Cả hai vấn đề đã được khắc phục. Cột method hiện hiển thị động từ bạn đã gửi bên trong request body. IP client trên các hàng Playground hiện hiển thị IP trình duyệt của người dùng đã đăng nhập, được chuyển tiếp bên trong một token Playground đã ký để API client không thể giả mạo.
Phần còn lại của giao diện cũng được xây dựng lại. Bảng hiển thị vừa vặn trên màn hình laptop mà không cần ẩn cột, cột sản phẩm được thu gọn vào dòng request, và bảng chi tiết có thêm các tab để request, response cùng tóm tắt phòng thủ có vùng cuộn riêng.
Thanh toán: 3D Secure khi thay đổi gói dịch vụ
Nếu đơn vị phát hành thẻ của bạn yêu cầu xác thực 3DS cho việc thay đổi gói (không chỉ khi đăng ký lần đầu), bước đó trước đây không được kích hoạt và thay đổi bị âm thầm hoàn tác. Hiện bước này đã hoạt động. Nếu bạn đã thử đổi gói trong tháng qua và thấy như không có gì xảy ra, thì đó chính là nguyên nhân.
Bên dưới hệ thống
Playground từ chối tạo response header từ dữ liệu của trang web được thu thập (một dạng lỗi header-injection mà chúng tôi đã phát hiện sớm). Một endpoint thanh toán trên Dashboard sẽ xác minh người gọi có sở hữu tài nguyên hay không trước khi phản hồi, loại bỏ một lỗ hổng IDOR.
Bản thân deploy pipeline đã nhận hàng loạt bản sửa lỗi trong một tuần đầy khó khăn, sau khi sự cố gián đoạn vào ngày 6 làm đầy ổ đĩa của deploy host ngay giữa quá trình build. Mọi service hiện từ chối build nếu không có đủ dung lượng đĩa trống, các đợt deploy được tuần tự hóa thay vì tranh chấp tài nguyên (race condition), gateway vẫn duy trì hoạt động khi một backend bị chập chờn (flapping), và các service thực sự thoát khi nhận SIGTERM thay vì bị treo cho đến khi bị kill sau ba mươi giây.
Trong một thời gian dài, việc lựa chọn "browser signature nào" là quyết định mà chúng tôi đưa ra thay bạn. Điều đó giờ đây không còn cần thiết nữa.