Najważniejsze informacje
Dwie zmiany w tym tygodniu wpływają na to, co wraca z Twoich requestów. Body odpowiedzi ze stron innych niż UTF-8 nie przychodzi już jako mojibake, a zaakceptowane przez validate odpowiedzi inne niż 200 są w końcu liczone jako sukces, a nie błąd. Załataliśmy też kilka luk bezpieczeństwa w klienckim API.
Co nowego
Strony inne niż UTF-8 zwracają czytelny tekst w Single
Jeśli wywołujesz Single na bułgarskich forach, chińskich platformach e-commerce, japońskich serwisach informacyjnych lub czymkolwiek, co serwuje windows-1251, GBK, Big5 lub Shift_JIS, body odpowiedzi wracało wcześniej jako uszkodzone bajty. Podszyta pod spodem warstwa HTTP miała na sztywno zakodowany dekoder UTF-8, więc strona pisana cyrylicą docierała jako промоции i nie dało się odzyskać oryginału po Twojej stronie.
Zostało to naprawione na warstwie requestów. Single wykrywa teraz kodowanie źródłowe (najpierw przez header Content-Type, potem <meta charset>, a na końcu <meta http-equiv>) i konwertuje je na UTF-8, zanim body trafi do Twojego pakietu JSON. Strony w UTF-8 lub ASCII przechodzą bez zmian. Zawartość binarna, taka jak obrazy czy pliki PDF, nigdy nie jest dekodowana. Jeśli potrzebujesz surowych bajtów, returnBuffer: true nadal zwraca oryginalny bufor.
Włączone domyślnie. Nie musisz ustawiać żadnej flagi. Strony, które działały wcześniej, nadal działają. Te, które zwracały śmieci, teraz zwracają czytelny tekst. Użytkownicy przeglądarek też nie muszą o tym myśleć, Chromium dekoduje zestawy znaków natywnie.
Reguły validate sterują teraz klasyfikacją sukcesu
Gdy ustawiasz validate w requeście (na przykład validate.status.accept = [200, 403]), silnik requestów już wcześniej respektował tę regułę i zwracał odpowiedź bez błędu. Jednak nasz klasyfikator wyników (outcome classifier) na wyższym poziomie ignorował tę regułę i wrzucał wszystko, co nie było dosłownym kodem 200, do worka application_fail. Miało to dwie konsekwencje: Twoje zaakceptowane 403 pojawiało się jako błąd w Dashboardzie, a ponieważ tylko sukcesy są rozliczane, te dostarczone odpowiedzi nie były fakturowane.
Klasyfikator respektuje teraz to, co zadeklarowano w validate. Requesty z validate są liczone jako sukces zawsze, gdy silnik obsłużył je bez błędu, niezależnie od statusu. Requesty bez validate zachowują się tak jak wcześniej (sukces tylko przy 200), więc dotychczasowa ścieżka pozostaje bez zmian.
Poprawka działa tylko w przód: historyczne wiersze zachowują swój zapisany wynik, a nowe requesty są klasyfikowane poprawnie. Jeśli więc widziałeś App Fail przy odpowiedziach, o których wiedziałeś, że są poprawne, to właśnie z tego powodu.
Wzmocnienie bezpieczeństwa klienckiego API
Wdrożyliśmy Wave 0 audytu bezpieczeństwa w klienckim API:
- CORS jest teraz ograniczony do
https://foura.ai. Poprzednie ustawienie odzwierciedlało dowolne źródło (origin) podczas przesyłania danych uwierzytelniających, co jest standardową podatnością na CSRF. Wywołania z tej samej domeny (same-origin) w przeglądarce oraz Twoje wywołania API po stronie serwera nie są dotknięte tą zmianą. - Ścieżka metryk (metrics route) obsługująca oś czasu aktywności (Activity timeline) akceptowała wcześniej dowolny filtr
outcome, który trafiał bezpośrednio do zapytania. Teraz wprowadziliśmy tam allowlistę znanych wartości outcome. Nie dało się tego wykorzystać ze zwykłego konta, ale warto było to zamknąć.
Żadna z tych zmian nie wpływa na kontrakt API. Nie zauważysz ich podczas normalnego użytkowania. Ale znalezienie problemu i wyeliminowanie go, zanim ktokolwiek go zauważy, wciąż zasługuje na wzmiankę.
Etykiety w Activity są zgodne z Overview
Mała rzecz. Tabela Activity w Dashboardzie wyświetlała wcześniej surowe ciągi znaków wyników, takie jak Application_fail, podczas gdy kafelki, wykres kołowy (donut) i oś czasu w sekcji Overview pokazywały przyjazne etykiety (App Fail) i oznaczały każdy wynik kolorami. Te same dane, dwie różne prezentacje. Teraz są zsynchronizowane i korzystają z tej samej mapy etykiet i kolorów, więc status wiersza wygląda tak samo niezależnie od miejsca, w którym go sprawdzasz.
Liczby
Ten tydzień nie przynosi nowych danych o opóźnieniach (latency) ani wskaźnikach sukcesu (success-rate). Większość z tego to praca nad poprawnością i bezpieczeństwem, gdzie właściwą metryką jest „przestać się mylić”, a nie „działać szybciej”. Przyszłotygodniowy przegląd powinien zawierać dane o przepustowości (throughput) z kilku wdrażanych właśnie tematów.