Điểm nổi bật
Tuần này có hai thay đổi ảnh hưởng đến kết quả trả về từ các request của bạn. Response body không còn bị lỗi mojibake trên các trang không phải UTF-8, và các response không phải 200 được chấp nhận bởi validate cuối cùng đã được tính là thành công thay vì thất bại. Chúng tôi cũng đã vá một vài lỗ hổng bảo mật trên customer API.
Có gì mới
Các trang không phải UTF-8 trả về văn bản đọc được trên Single
Nếu bạn gọi Single trên các diễn đàn tiếng Bulgaria, trang thương mại điện tử Trung Quốc, tin tức Nhật Bản, hoặc bất kỳ trang nào sử dụng windows-1251, GBK, Big5, hoặc Shift_JIS, response body trước đây thường trả về dưới dạng các byte bị lỗi. Lớp HTTP bên dưới đã hard-code bộ giải mã UTF-8, vì vậy một trang tiếng Cyrillic sẽ hiển thị thành промоции và bạn không có cách nào để khôi phục lại văn bản gốc.
Lỗi này đã được khắc phục ở lớp request. Single hiện tại sẽ tự động phát hiện charset nguồn (thông qua header Content-Type, sau đó là <meta charset>, rồi đến <meta http-equiv>) và chuyển mã sang UTF-8 trước khi body được đưa vào envelope JSON của bạn. Và các trang UTF-8 hoặc ASCII sẽ được giữ nguyên mà không bị can thiệp. Các nội dung nhị phân như hình ảnh hoặc PDF sẽ không bao giờ bị giải mã. Nếu bạn muốn nhận các byte thô, returnBuffer: true vẫn sẽ trả về buffer gốc.
Tính năng này được bật theo mặc định. Không cần phải bật bất kỳ flag nào. Các trang hoạt động bình thường trước đây vẫn hoạt động; các trang từng trả về dữ liệu rác giờ đây sẽ hiển thị văn bản đọc được. Người dùng trình duyệt cũng không cần bận tâm về điều này; Chromium tự động giải mã các charset một cách nguyên bản.
Các quy tắc validate hiện quyết định việc phân loại thành công
Khi bạn thiết lập validate cho một request (ví dụ: validate.status.accept = [200, 403]), request engine vốn đã tuân theo quy tắc của bạn và xử lý response mà không báo lỗi. Nhưng bộ phân loại kết quả (outcome classifier) ở phía thượng nguồn của chúng tôi đã bỏ qua quy tắc đó và xếp bất kỳ kết quả nào không phải là 200 thực tế vào nhóm application_fail. Điều này dẫn đến hai hệ quả: các response 403 được chấp nhận của bạn hiển thị dưới dạng thất bại trên Dashboard, và vì chỉ những request thành công mới bị tính phí, các response đã gửi đó cũng không được tính hóa đơn.
Bộ phân loại hiện tại đã tuân thủ những gì validate khai báo. Các request có cấu hình validate sẽ được tính là thành công bất cứ khi nào engine xử lý chúng mà không có lỗi, bất kể status là gì. Các request không có validate vẫn hoạt động như trước (chỉ tính thành công với status 200), vì vậy luồng xử lý cũ không bị ảnh hưởng.
Bản vá này chỉ áp dụng cho các dữ liệu mới: các dòng dữ liệu lịch sử vẫn giữ nguyên kết quả đã lưu, các request mới sẽ được phân loại chính xác. Vì vậy, nếu trước đây bạn thấy trạng thái App Fail trên các response mà bạn biết chắc là hợp lệ, thì đây chính là lý do.
Tăng cường bảo mật trên customer API
Chúng tôi đã triển khai Wave 0 của đợt đánh giá bảo mật trên toàn bộ customer API:
- CORS hiện được giới hạn trong phạm vi
https://foura.ai. Thiết lập trước đây phản hồi lại bất kỳ origin nào trong khi gửi thông tin xác thực, vốn là cấu hình CSRF tiêu chuẩn. Các cuộc gọi trình duyệt cùng nguồn (same-origin) và các cuộc gọi API phía server của bạn không bị ảnh hưởng. - Route metrics đằng sau dòng thời gian Activity của bạn từng chấp nhận một bộ lọc
outcometự do và được đưa trực tiếp vào câu lệnh truy vấn. Hiện tại, nó đã được đưa vào allowlist chỉ gồm các giá trị outcome đã biết. Lỗ hổng này không thể bị khai thác từ một tài khoản thông thường, nhưng vẫn rất đáng để vá lại.
Cả hai thay đổi đều không làm thay đổi bất kỳ giao ước API (API contract) nào. Bạn sẽ không nhận thấy sự khác biệt nào trong quá trình sử dụng thông thường. Nhưng việc tìm ra vấn đề và khắc phục nó trước khi có ai nhận ra vẫn là điều đáng để chia sẻ.
Các nhãn Activity đồng bộ với Overview
Một thay đổi nhỏ. Bảng Activity trong Dashboard của bạn trước đây hiển thị các chuỗi outcome thô như Application_fail, trong khi các thẻ (chips), biểu đồ tròn (donut) và dòng thời gian của Overview lại hiển thị các nhãn thân thiện (App Fail) và mã hóa màu sắc cho từng outcome. Cùng một dữ liệu nhưng có hai cách hiển thị khác nhau. Giờ đây chúng đã được đồng bộ hóa, cả hai đều đọc từ cùng một bản đồ nhãn và màu sắc, nhờ đó trạng thái của một hàng sẽ hiển thị đồng nhất dù bạn kiểm tra ở bất kỳ đâu.
Số liệu
Tuần này không có số liệu mới về độ trễ (latency) hay tỷ lệ thành công (success-rate). Phần lớn công việc tuần này tập trung vào tính chính xác và bảo mật, nơi mà chỉ số đo lường phù hợp là "ngừng làm sai" thay vì "chạy nhanh hơn". Bản tin tuần tới sẽ có dữ liệu về băng thông (throughput) từ một số tính năng đang được triển khai.