Integracja może poprawnie połączyć się z UPS API, a po pewnym czasie zwracać błędy autoryzacji. Jedną z przyczyn jest wygasły token. Uzyskanie tokenu nie zapewnia bezterminowego dostępu.
Gdzie podano czas ważności?
Oficjalna specyfikacja UPS OAuth Client Credentials zawiera w odpowiedzi pole expires_in. Opisuje czas ważności żądanego tokenu w sekundach. Odczytuj wartość z serwera, zamiast zastępować ją ustaloną wcześniej stałą.
Co sprawdzić w integracji?
W specyfikacji expires_in ma typ tekstowy. Przy obliczaniu czasu wygaśnięcia przekształć wartość na liczbę i uwzględnij sekundy. Przechowuj czas ważności razem z tokenem.
Praktyczne rozwiązanie to uzyskanie nowego tokenu przed wygaśnięciem, z niewielkim zapasem na wykonanie żądania. To zalecenie dotyczące integracji, nie dodatkowy termin narzucony przez UPS. Przy wielu procesach sprawdź, czy każdy nie prosi niepotrzebnie o nowy token.
Przy błędzie autoryzacji najpierw ustal przyczynę: wygaśnięcie nie jest jedyną możliwością. Unikaj nieskończonych identycznych prób i nie zapisuj tokenów ani sekretów klienta w zwykłych logach.
Kto powinien to sprawdzić?
Programiści sklepów, usług dostawczych i innych systemów korzystających bezpośrednio z UPS API. Nadawca używający gotowej platformy nie musi sam uzyskiwać tokenu OAuth.
W integracji testowej sprawdź pobranie tokenu, jego ponowne użycie i obsługę wygaśnięcia. Przykład w dokumentacji nie gwarantuje stałego czasu dostępu na zawsze.
Najczęstsze pytania
Czy można ustawić stały czas ważności wszystkich tokenów?
Nie zastępuj odpowiedzi serwera stałą wartością. Używaj expires_in otrzymanego tokenu.
W jakich jednostkach podawane jest expires_in?
W sekundach. Specyfikacja UPS określa pole jako tekstowe, więc do obliczeń trzeba przekształcić je na liczbę.
Czy zwykły nadawca musi sam uzyskać token?
Nie, jeśli korzysta z gotowej platformy wysyłkowej. Ta konfiguracja dotyczy programistów systemów używających bezpośrednio UPS API.
