Điểm nổi bật
Việc chọn browser profile hiện có thể được tùy chỉnh cho từng request. Chỉ định browser và hệ điều hành bạn muốn, sau đó fingerprint cùng với headers sẽ mô tả chính xác những điều đó. Single đã học được cách giải quyết thêm hai hệ thống phòng thủ trong tuần này (SG-Captcha của SiteGround và thử thách Argon2 của eBay) mà không cần khởi chạy Browser. Và chế độ xem Activity của Dashboard hiện ghi lại những gì bạn yêu cầu, không phải các luồng xử lý chạy ngầm bên dưới.
Tính năng mới
Chọn browser profile cho từng request
Cho đến nay, unblocker: true chỉ chọn một chữ ký (bất kể giá trị mặc định hiện tại của chúng tôi là gì) và chỉ có vậy. Bây giờ bạn có thể chỉ định một chữ ký:
{ "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 từ chối các kết hợp không xác định theo tên và liệt kê những gì CÓ SẴN, do đó một lỗi đánh máy không thể âm thầm cung cấp một chữ ký mà bạn chưa từng yêu cầu.
Toàn bộ danh mục nằm tại GET /api/profiles. Nó công khai (không cần khóa), vì đây là danh sách khả năng, không phải bí mật. Tính đến thời điểm viết bài này có 79 cài đặt sẵn trên Chrome, Firefox, Edge, Safari và Tor, trên Windows, macOS, Android và iOS. Playground đọc từ cùng một danh sách, vì vậy danh sách thả xuống luôn hiển thị chính xác những gì mã của bạn có thể yêu cầu.
Tại sao điều này quan trọng: nếu mục tiêu của bạn là hồ sơ yêu cầu theo OS, hoặc nhóm của bạn đang A/B testing xem stack nào vượt qua một rào cản cụ thể, bạn hiện có thể giữ cố định biến đó trong khi mọi thứ khác thay đổi.
Single vượt qua SG-Captcha và bằng chứng công việc của eBay
Hai biện pháp bảo vệ từng buộc phải chuyển hướng qua Browser giờ đã vượt qua được trên Single. eBay triển khai thử thách bằng chứng công việc (proof-of-work) của riêng mình (một câu đố Argon2) và SiteGround bảo vệ một phần web lưu trữ chia sẻ bằng SG-Captcha. Cả hai đều được giải quyết mà không cần rendering, điều này có nghĩa là response trả về dưới dạng một HTTP request duy nhất và được định giá tương ứng.
Tín hiệu phòng thủ trong các response cũng phát triển hơn. Các Browser response hiện mang defenses: { present, cleared }, do đó bạn có thể thấy vendor nào đứng trước trang và liệu chúng ta có vượt qua được hay không. Thanh toán tuân theo cùng một quy tắc: bất kỳ vendor nào chúng ta vượt qua đều được quy vào, bất kể đó là thương hiệu nào. Cloudflare là giải pháp trả phí duy nhất trước cửa sổ này. Akamai Bot Manager, SG-Captcha và thử thách của eBay hiện được thêm vào.
Khung nhìn Activity được xây dựng lại trong Dashboard
Hai cột trong danh sách Activity của Dashboard đang hiển thị sai thông tin. Phương thức HTTP luôn đọc POST trên mọi hàng (tất cả các endpoint của chúng ta là POST, vì vậy cột này là một hằng số không cho bạn biết thông tin gì). Và client IP trên các lệnh gọi từ Playground đã ghi lại nơi Playground gọi từ đó, không phải người nhấp Run.
Cả hai đều đã được sửa. Cột phương thức hiện đọc động từ bạn gửi bên trong request body. Client IP trên các hàng Playground hiện đọc IP trình duyệt của người dùng đã đăng nhập, được mang bên trong một Playground token đã ký để một API client không thể giả mạo.
Phần còn lại của khung nhìn đã được xây dựng lại trong khi chúng tôi làm việc. Bảng hiển thị vừa vặn trên máy tính xách tay mà không ẩn cột, cột sản phẩm gấp vào dòng request và bảng chi tiết có thêm các tab để request, response và bản tóm tắt phòng thủ, mỗi phần đều có thể cuộn riêng.
Thanh toán: 3D Secure khi thay đổi gói
Nếu công ty phát hành thẻ của bạn yêu cầu xác nhận 3DS cho việc thay đổi gói (không chỉ ở lần đăng ký ban đầu), bước đó đã không khởi chạy và thay đổi đã âm thầm hoàn nguyên. Nó hiện đã hoạt động. Nếu bạn đã cố gắng thay đổi gói trong tháng qua và dường như không có gì xảy ra, thì đó là lý do.
Bên trong hệ thống
Playground từ chối tạo response header từ dữ liệu của một trang đã tìm nạp (một loại lỗi chèn header mà chúng tôi đã bắt sớm). Một endpoint thanh toán trên Dashboard xác minh người gọi sở hữu tài nguyên trước khi trả lời, đóng một đường dẫn IDOR.
Bản thân deploy pipeline đã được sửa lỗi trong suốt một tuần sau khi sự cố vào ngày 6 làm đầy ổ đĩa của deploy host giữa quá trình build. Mọi service từ chối build nếu không đủ dung lượng đĩa trống, các bản deploy chạy nối tiếp thay vì tranh chấp, gateway duy trì hoạt động khi một backend chập chờn, và các service thực sự thoát khi nhận SIGTERM thay vì treo cho đến khi bị ngắt sau đó ba mươi giây.
Trong một thời gian dài, việc sử dụng "chữ ký trình duyệt nào" là quyết định mà chúng tôi đưa ra thay cho bạn. Mọi thứ không nhất thiết phải như vậy.