🎉 Przedstawiamy naszą lipcową aktualizację: Logto API SDK, Sejf na tajne dane do przechowywania federacyjnych tokenów, zarządzaj TOTP i Kodami zapasowymi przez Account API i więcej!
TypeScript SDK do interakcji z Management API Logto przy użyciu uwierzytelniania za pomocą poświadczeń klienta.
Jak to działa:
npm install @logto/apicreateManagementApi(), aby utworzyć typowanego klienta Management API z poświadczeniami twojej aplikacji.Najważniejsze funkcje:
Sejf na tajne dane to bezpieczne rozwiązanie w Logto do zarządzania wrażliwymi danymi użytkowników, w tym tokenami dostępu, kluczami API, kodami dostępu i innymi poufnymi informacjami. Dane te są zwykle wykorzystywane do dostępu do zewnętrznych usług w imieniu użytkowników, co czyni bezpieczne przechowywanie kluczowym.
Przechowywanie tokenów jest już wspierane zarówno dla społecznościowych, jak i korporacyjnych konektorów SSO. Po włączeniu tej opcji, Logto przechowuje zestaw tokenów wydanych przez dostawcę tożsamości po udanym uwierzytelnieniu. Aplikacje mogą następnie pobrać token dostępu później — bez konieczności ponownego uwierzytelniania użytkownika — aby wywołać zewnętrzne API.
Wspierane konektory:
Jak to działa:
Więcej szczegółów znajduje się w dokumentacji sejfu na tajne dane.
Użytkownicy mogą teraz dodawać TOTP oraz kody zapasowe przy użyciu Account API.
POST /api/my-account/mfa-verifications/totp-secret/generate: Generuj sekret TOTP.POST /api/my-account/mfa-verifications/backup-codes/generate: Generuj kody zapasowe.POST /api/my-account/mfa-verifications: Dodaj sekret TOTP lub kod zapasowy przy użyciu wygenerowanego sekretu lub kodów.GET /api/my-account/mfa-verifications/backup-codes: Pobierz kody zapasowe.scope przy generowaniu URL autoryzacyjnego dla konektorów społecznościowych. Pozwala to na żądanie dodatkowych uprawnień od dostawcy społecznościowego podczas wywoływania Logto social verification endpoint. Jeśli scope zostanie podany, zostanie on użyty w żądaniu autoryzacyjnym; w innym przypadku użyty zostanie domyślny scope skonfigurowany w ustawieniach konektora.Ograniczenie klucza obcego uwzględniające tenant dla tabeli organization_user_relations
Problem
Deweloperzy mogli omyłkowo przypisać user_id z innego tenant-a do organizacji, powodując błędy 500 na endpointach API użytkowników organizacji. Oryginalna tabela organization_user_relations miała ograniczenie klucza obcego tylko dla users (id), co pozwalało przypisać dowolny istniejący user ID niezależnie od separacji tenantów.
Przyczyna główna
Logto stosuje Row Level Security (RLS) na wszystkich tabelach, aby izolować dostęp do danych tenantów. Podczas łączenia tabeli users z organization_user_relations, faktyczne dane użytkownika stają się niedostępne dla bieżącego tenant-a z powodu ograniczeń RLS, powodując, że zwracane dane użytkownika są null, co prowadzi do błędów serwera 500.
Rozwiązanie
Dodano złożony klucz obcy (tenant_id, user_id) wskazujący na users (tenant_id, id), aby zapewnić, że tenant ID relacji organizacja-użytkownik odpowiada tenant ID użytkownika. Zapewnia to prawidłową separację tenantów na poziomie bazy danych.