Odkryj nasze wydanie z sierpnia 2024 roku, zawierające impersonację użytkownika, zarządzanie sekretami aplikacji, branding na poziomie organizacji i aplikacji dla doświadczenia logowania i wiele więcej.
Dodano wsparcie dla impersonacji użytkownika przez Wymianę Tokenów:
POST /subject-tokens, aby zażądać subject_token do wykorzystania w wymianie tokenów.POST /oidc/token z nowym typem grant urn:ietf:params:oauth:grant-type:token-exchange, aby wymienić subject_token na impersonowany access_token użytkownika.Zobacz Impersonacja użytkownika po więcej szczegółów.
custom_data na poziomie aplikacjiDodano nowe pole obiektu arbitalnego custom_data do aplikacji. To pole może przechowywać dodatkowe informacje, których nie definiuje standardowy schemat Application.
PATCH /api/applications/{applicationId}/custom-data, aby zaktualizować pole custom_data aplikacji.PATCH /api/applications/{applicationId}, aby umożliwić nadpisanie pola custom_data.Dodano nowy edytor danych JSON do strony szczegółowej aplikacji (z wyjątkiem aplikacji chronionych).
Bezpieczne aplikacje (maszyna-maszyna, tradycyjne web, Chronione) mogą teraz mieć wiele sekretów aplikacji z ustalonym terminem ważności. To umożliwia rotację sekretów i zapewnia jeszcze bezpieczniejsze doświadczenie.
Uwaga: Stary sekret stworzony przed wprowadzeniem tej funkcji nadal może być używany do uwierzytelniania klienta. Zaleca się jednak usunięcie starych i utworzenie nowych sekretów z terminem ważności dla zwiększenia bezpieczeństwa.
GET /api/applications/{applicationId}/secrets: Wylistuj wszystkie sekrety aplikacji.POST /api/applications/{applicationId}/secrets: Utwórz nowy sekret dla aplikacji.DELETE /api/applications/{applicationId}/secrets/{name}: Usuń sekret aplikacji po nazwie.PATCH /api/applications/{applicationId}/secrets/{name}: Zaktualizuj sekret aplikacji po nazwie.DELETE /api/applications/{applicationId}/legacy-secret: Usuń stary sekret aplikacji i zastąp go nowym.Aby zarządzać sekretami swojej aplikacji, przejdź do Logto Console -> Aplikacje -> Szczegóły aplikacji -> Punkty końcowe i poświadczenia.
Oryginalne pole wprowadzania sekretu aplikacji tylko do odczytu zostało zastąpione nową tabelą zarządzania sekretami. Możesz tworzyć, aktualizować i usuwać sekrety w tej tabeli.
Teraz możliwe jest ustawienie jasnych i ciemnych logotypów dla organizacji. Można je przesłać na stronie ustawień organizacji.
Można również nadpisać logo doświadczenia logowania organizacji. Wystarczy dodać parametr organization_id do żądania autoryzacji. W większości SDK Logto można to zrobić za pomocą pola extraParams w metodzie signIn.
Na przykład w SDK JavaScript:
Wartość <organization-id> można znaleźć na stronie ustawień organizacji.
Jeśli nie możesz znaleźć pola extraParams w używanym przez ciebie SDK, daj nam znać.
Teraz można ustawić loga, favikony i kolory dla swojej aplikacji. Te ustawienia będą używane w doświadczeniu logowania, gdy aplikacja rozpoczyna przepływ autoryzacji. Dla aplikacji, które nie mają ustawień brandingu, zostanie użyty branding omni doświadczenia logowania.
Jeśli w żądaniu autoryzacji zostanie podany organization_id, ustawienia brandingu aplikacji zostaną nadpisane przez ustawienia brandingu organizacji, jeśli są dostępne.
Logto teraz wstrzykuje ustawienia i frazy doświadczenia logowania do pliku index.html w celu poprawy wydajności pierwszego ekranu. Aplikacja doświadczenia nadal pobierze ustawienia i frazy z serwera, jeśli:
tsup do budowania pakietów connectorów. Dzięki temu proces budowania będzie szybszy, nie powinno to wpływać na funkcjonalność pakietów.Vite do transpilacji i bundlowania pakietów @logto/console, @logto/demo-app i @logto/experience. Usunięto ParcelJS i zastąpiono Vite. Nie powinno się spodziewać żadnych zmian łamiących.PATCH /api/applications/{applicationId}Wszystkie pola jsonb w obiekcie Application powinny być aktualizowane w trybie replace, a nie w trybie merge. Ta zmiana sprawi, że metoda PATCH będzie bardziej przewidywalna i zgodna z projektem RESTful API.
merge na replace w punkcie końcowym PATCH /api/applications/{applicationId}.partial na full w punkcie końcowym PATCH /api/applications/{applicationId}.oidc_client_metadata, custom_client_metadata, protected_app_metadata i custom_data.Uwaga: Jeśli używasz Konsoli Logto do aktualizacji ustawień
Application, nie powinieneś być dotknięty tą zmianą. Użytkownicy API, którzy używają metodyPATCHdo aktualizacji ustawień pola jsonbApplication, powinni być świadomi tej zmiany. MetodaPATCHteraz zastąpi całe pole jsonb nowymi danymi wejściowymi. Każde częściowe dane wejściowe w dotkniętych polach zostaną odrzucone.
Dotknięte zdarzenia webhook: Role.Scopes.Updated, Organizations.Membership.Updates.
Kod statusu odpowiedzi API zwrócony przez ładunek zdarzenia webhook zawsze wynosił 404. Było to spowodowane wstawieniem ładunku zdarzenia webhook przed ustawieniem kontekstu odpowiedzi API.
Ponieważ webhook jest wyzwalany tylko wtedy, gdy wydarzenie zostanie pomyślnie przetworzone, kod statusu powinien zawsze wynosić 2xx.
Problem został naprawiony, przenosząc wstawienie ładunku zdarzenia webhook po ustawieniu kontekstu odpowiedzi API.
Argon2d i Argon2id. Użytkownicy z tymi algorytmami zostaną zmigrowani do Argon2i po pomyślnym zalogowaniu się.@logto/experience została zsynchronizowana z tym, co jest opisane w README.md.