Uwierzytelnianie API
Jak działają logowanie do panelu oraz token osadzania widżetu — bez systemu kluczy API dla deweloperów.
Strona „Uwierzytelnianie API w Zentor bez klucza API” opisuje obszar funkcjonalny wskazany w adresie URL. Istniejąca treść została uzupełniona o rzeczywisty przebieg, wymagania wstępne i znane ograniczenia. Zentor nie posiada systemu kluczy API dla deweloperów. W panelu używane są sesyjne tokeny JWT ważne dwanaście godzin oraz tokeny odświeżania ważne siedem dni; TOTP i SSO są opcjonalne. Tokeny osadzenia widżetu są wyświetlane jawnym tekstem tylko raz i są powiązane z dozwolonymi originami.
Zentor nie oferuje ogólnego systemu kluczy API dla deweloperów. W panelu używane są sesyjne tokeny JWT ważne dwanaście godzin oraz tokeny odświeżania ważne siedem dni. Opcjonalnie dostępne są TOTP i SSO.
Widżet używa tokenu osadzenia, który jest wyświetlany jawnym tekstem tylko raz. Dodatkowo sprawdzany jest origin. Token i zatwierdzenie domeny są więc ze sobą powiązane; ważny token z niedozwolonego originu nie wystarczy.
Sesyjne tokeny JWT i tokeny widżetu nie mogą trafiać do repozytoriów kodu źródłowego, publicznych logów ani przykładów w dokumentacji. Po wygaśnięciu lub unieważnieniu aplikacja musi korzystać z przewidzianego procesu odnowienia lub ponownego logowania.
Wewnętrzne trasy panelu i Master Admin nie są częścią publicznego API dla deweloperów. Udane logowanie daje uprawnienia wyłącznie w zakresie roli i aktywnego tenanta. Integracje nie mogą traktować wewnętrznych punktów końcowych jako stabilnego interfejsu publicznego.
Dla strony „Uwierzytelnianie API w Zentor bez klucza API” oznacza to: dotychczasowy krótki tekst zostaje rozbudowany do rzetelnej instrukcji, bez obiecywania funkcji wykraczających poza potwierdzony stan produktu. Miarodajne pozostają zweryfikowane źródła faktów i widoczny podział odpowiedzialności między tenantem a Zentor. W przypadku rozbieżności zawsze należy podać dokładnie ten adres URL, danego tenanta i zaobserwowany krok.
Podczas pracy z „api-authentifizierung” każdy krok należy najpierw sprawdzić na kontrolowanym przypadku testowym. Decydujące jest, aby widoczne ustawienie, rzeczywisty stan systemu i oczekiwany wynik były ze sobą zgodne. W razie rozbieżności w analizie pomagają dokładna godzina, dany tenant, użyty kanał i niezmieniony komunikat błędu. Dane dostępowe, tokeny i treści zawierające dane osobowe nie mogą przy tym trafiać do zrzutów ekranu ani tekstów dla wsparcia.