[Logto](https://logto.io/) to nowoczesny dostawca usług uwierzytelniania tożsamości, który oferuje bezpieczne, kompleksowe i przyjazne dla użytkownika wsparcie logowania dla aplikacji. Dostarcza również wiele SDK oraz przewodniki integracyjne dla różnych frameworków i języków programowania, umożliwiając bezproblemową integrację usług uwierzytelniania tożsamości klasy korporacyjnej w Twojej aplikacji w kilka minut. Ten artykuł skupia się głównie na szczegółach dotyczących integracji Supabase z Logto. ## Podstawy Supabase Supabase wykorzystuje [Zabezpieczenia na Poziomie Wiersza (Row-Level Security) Postgresa](https://www.postgresql.org/docs/current/ddl-rowsecurity.html) do kontrolowania uprawnień dostępu do danych. W prostych słowach, tworząc polityki Zabezpieczeń na Poziomie Wiersza dla tabel w bazie danych, możemy ograniczyć i zarządzać tym, kto może odczytywać, zapisywać i aktualizować dane w tabeli. Załóżmy, że w Twojej bazie danych znajduje się tabela o nazwie „posts” z następującą zawartością: Tabela postów

Pole `user_id` w tabeli reprezentuje użytkownika, do którego należy każdy post. Możesz ograniczyć każdego użytkownika do dostępu jedynie do swoich danych postów na podstawie pola `user_id`. Jednak aby to zrealizować, Supabase musi być w stanie zidentyfikować bieżącego użytkownika uzyskującego dostęp do bazy danych. ### Dodanie danych użytkownika do żądań Supabase Dzięki wsparciu Supabase dla JWT, gdy nasza aplikacja komunikuje się z Supabase, możemy wygenerować JWT zawierający dane użytkownika przy użyciu sekretu JWT udostępnionego przez Supabase. Następnie używamy tego JWT jako nagłówka Authentication podczas składania żądań. Po otrzymaniu żądania, Supabase automatycznie weryfikuje ważność JWT i umożliwia dostęp do danych zawartych w nim w dalszych procesach. Najpierw możemy uzyskać sekret JWT z Supabase z „Project Settings” na pulpicie Supabase: Strona ustawień API Supabase

Następnie, gdy używamy SDK Supabase do składania żądań do Supabase, wykorzystujemy ten sekret do wygenerowania naszego JWT i dodania go jako nagłówka Authentication do żądania. (Należy pamiętać, że proces ten odbywa się w backendzie Twojej aplikacji i sekret JWT nigdy nie powinien być udostępniany stronom trzecim). ```jsx import { createClient } from '@supabase/supabase-js'; import { sign } from 'jsonwebtoken'; / * Uwaga: * Możesz znaleźć SUPABASE_URL, SUPABASE_ANON_KEY w tym samym miejscu, gdzie znajdziesz Sekret JWT. */ const SUPABASE_URL = process.env.SUPABASE_URL; const SUPABASE_ANON_KEY = process.env.SUPABASE_ANON_KEY; const SUPABASE_JWT_SECRET = process.env.SUPABASE_JWT_SECRET; export const getSupabaseClient = (userId) => { const jwtPayload = { userId, }; const jwt = sign(jwtPayload, SUPABASE_JWT_SECRET, { expiresIn: '1h', // Tylko do demonstracji }); const client = createClient(SUPABASE_URL, SUPABASE_ANON_KEY, { global: { headers: { Authorization: `Bearer ${jwt}`, }, }, }); return client; }; ``` Następnie przejdź do Edytora SQL na pulpicie Supabase i utwórz funkcję do pobierania `userId` obecną w żądaniu: Utworzenie funkcji pobrania user ID

Kod użyty na obrazku jest następujący: ```sql create or replace function auth.user_id() returns text as $$ select nullif(current_setting('request.jwt.claims', true)::json->>'userId', '')::text; $$ language sql stable; ``` Jak pokazuje kod, w Supabase, możesz pobrać payload JWT, który generujemy, wywołując `request.jwt.claims`. Pole `userId` w payloadzie to wartość, którą ustawiliśmy. Dzięki tej funkcji Supabase może określić użytkownika, który aktualnie uzyskuje dostęp do bazy danych. ### Utworzenie polityki Zabezpieczeń na Poziomie Wiersza Następnie możemy utworzyć politykę Zabezpieczeń na Poziomie Wiersza, aby ograniczyć każdego użytkownika do dostępu jedynie do swoich danych postów na podstawie pola `user_id` w tabeli postów. 1. Przejdź do strony Edytora Tabel na pulpicie Supabase i wybierz tabelę `posts`. 2. Kliknij „Add RLS Policy” u góry tabeli. 3. W wyświetlonym oknie kliknij „Create policy”. 4. Wprowadź nazwę polityki i wybierz komendę Polityka SELECT. 5. W bloku `using` poniższego kodu wprowadź: ```sql auth.user_id() = user_id ``` Utworzenie polityki RLS

Korzystając z takich polityk, można osiągnąć kontrolę dostępu do danych w Supabase. W rzeczywistych aplikacjach będziesz tworzyć różne polityki, aby ograniczyć działania użytkowników, takie jak wstawianie i modyfikowanie danych. Jednak to jest poza zakresem tego artykułu. Aby uzyskać więcej informacji na temat Zabezpieczeń na Poziomie Wiersza (RLS), zapoznaj się z [Zabezpiecz swoje dane za pomocą Zabezpieczeń na Poziomie Wiersza Postgresa](https://supabase.com/docs/guides/database/postgres/row-level-security). ### Podstawowy proces integracji z Logto Jak wcześniej wspomniano, ponieważ Supabase wykorzystuje RLS do kontroli dostępu, kluczem do integracji z Logto (lub inną usługą uwierzytelniania) jest uzyskanie id użytkownika, który jest upoważniony, i przesłanie go do Supabase. Cały proces jest przedstawiony na poniższym diagramie: ```mermaid sequenceDiagram Participant U as Użytkownik końcowy Participant Logto Participant B as Usługa backendowa aplikacji Participant Supabase U->>Logto: Zaloguj się przez Logto Logto-->>U: `access_token` U->>B: Żądanie danych z `access_token` B->>B: Pobierz `user_id` z `access_token` B->>B: Wygeneruj jwt za pomocą `user_id` i `sekretu JWT Supabase` B->>Supabase: Żądanie danych z jwt Supabase-->>B: Zwrócone dane B-->>U: Zwrócone dane ``` Następnie wyjaśnimy, jak zintegrować Logto z Supabase na podstawie tego diagramu procesu. ## Integracja Logto Logto oferuje przewodniki integracyjne dla różnych frameworków i języków programowania. Zazwyczaj aplikacje zbudowane na tych frameworkach i językach należą do kategorii takich jak aplikacje natywne, SPA (jednostronicowe aplikacje), tradycyjne aplikacje webowe oraz aplikacje M2M (machine-to-machine). Możesz odwiedzić stronę [Przewodniki Szybkiego Startu Logto](https://docs.logto.io/quick-starts/), aby zintegrować Logto z Twoją aplikacją na podstawie stosu technologicznego, którego używasz. Następnie postępuj zgodnie z instrukcjami poniżej, aby zintegrować Logto z Twoim projektem w zależności od rodzaju aplikacji. ### Aplikacja natywna lub SPA Zarówno aplikacje natywne, jak i SPA działają na Twoim urządzeniu, a poświadczenia (token dostępu) uzyskane po zalogowaniu się są przechowywane lokalnie na Twoim urządzeniu. Dlatego, podczas integracji aplikacji z Supabase, musisz komunikować się z Supabase za pośrednictwem usługi backendowej, ponieważ nie można na każdym urządzeniu użytkownika ujawniać poufnych informacji (takich jak sekret JWT Supabase). Załóżmy, że budujesz swoje SPA za pomocą React i Express. Pomyślnie zintegrowałeś Logto z Twoją aplikacją, postępując zgodnie z [Przewodnikiem SDK do React](https://docs.logto.io/quick-starts/react/) (możesz odnieść się do kodu w naszym [przykładzie react](https://github.com/logto-io/js/tree/master/packages/react-sample)). Dodatkowo, dodałeś weryfikację tokena dostępu Logto na swoim serwerze backendowym zgodnie z dokumentacją [Chron Twoje API na Node (Express)](https://docs.logto.io/docs/recipes/protect-your-api/node/). Następnie, użyjesz tokena dostępu uzyskanego od Logto do żądania danych użytkownika z Twojego serwera backendowego: ```jsx import { useLogto } from '@logto/react'; import { useState, useEffect } from 'react'; import PostList from './PostList'; const endpoint = ''; const resource = ''; function PostPage() { const { isAuthenticated, getAccessToken } = useLogto(); const [posts, setPosts] = useState(); useEffect(() => { const fetchPosts = async () => { const response = await fetch(endpoint, { headers: { Authorization: `Bearer ${await getAccessToken(resource)}`, }, }); setPosts(response.json()); }; if (isAuthenticated) { void fetchPosts(); } }, [isAuthenticated, getAccessToken]); return ; } export default PostPage; ``` Na Twoim serwerze backendowym już wyodrębniłeś id zalogowanego użytkownika z tokena dostępu przy użyciu middleware: ```jsx // auth-middleware.ts import { createRemoteJWKSet, jwtVerify } from 'jose'; //... export const verifyAuthFromRequest = async (ctx, next) => { // Wyodrębnij token const token = extractBearerTokenFromHeaders(ctx.request.headers); const { payload } = await jwtVerify( token, // Surowy token Bearer wyodrębniony z nagłówka żądania createRemoteJWKSet(new URL('https:///oidc/jwks')), // wygeneruj jwks, używając jwks_uri uzyskanego z serwera Logto { // oczekiwany wydawca tokena, powinien być wydany przez serwer Logto issuer: 'https:///oidc', // oczekiwana publiczność tokena, powinna być wskaźnikiem zasobu bieżącego API audience: '', } ); // jeśli używasz RBAC assert(payload.scope.includes('some_scope')); // logika niestandardowego ładunku ctx.auth = { userId: payload.sub, }; return next(); }; ``` Teraz możesz skorzystać z funkcji `getSupabaseClient` opisanej powyżej, aby przypisać `userId` do JWT używanego w kolejnych żądaniach do Supabase. Alternatywnie możesz utworzyć middleware, aby utworzyć klienta Supabase do żądań, które muszą komunikować się z Supabase: ```jsx export const withSupabaseClient = async (ctx, next) => { ctx.supabase = getSupabaseClient(ctx.auth.userId); return next(); }; ``` W późniejszym przebiegu przetwarzania, możesz bezpośrednio wywołać `ctx.supabase` do komunikacji z Supabase: ```jsx const fetchPosts = async (ctx) => { cosnt { data } = await ctx.supabase.from('posts').select('*'); return data; } ``` W tym kodzie, Supabase zwróci tylko dane postów należące do bieżącego użytkownika na podstawie wcześniej zdefiniowanych polityk. ### Tradycyjna aplikacja webowa Główną różnicą między tradycyjną aplikacją online a aplikację natywną lub SPA jest to, że tradycyjna aplikacja online renderuje i aktualizuje strony wyłącznie na serwerze webowym. Dlatego też poświadczenia użytkowników są zarządzane bezpośrednio przez serwer webowy, podczas gdy w aplikacjach natywnych i SPA znajdują się na urządzeniu użytkownika. Podczas integracji Logto z tradycyjną aplikacją webową w Supabase, możesz bezpośrednio uzyskać id zalogowanego użytkownika z backendu. Na przykładzie projektu Next.js, po zintegrowaniu Logto z projektem postępując zgodnie z [Przewodnikiem SDK do Next.js](https://docs.logto.io/quick-starts/next-app-router/), możesz użyć SDK Logto do uzyskania informacji o użytkowniku i zbudowania odpowiedniego JWT umożliwiającego interakcję z Supabase. ```jsx import { getLogtoContext } from '@logto/next-server-actions'; import { logtoConfig } from '@/logto'; import { getSupabaseClient } from '@/utils'; import PostList from './PostList'; export default async function PostPage() { const { cliams } = await getLogtoContext(logtoConfig); // `sub` wartość w `cliams` to id użytkownika. const supabase = getSupabaseClient(cliams.sub); const { data: posts } = await supabase.from('posts').select('*'); return ; } ``` ### Aplikacja typu machine-to-machine Machine-to-machine (M2M) jest często używane, gdy Twoja aplikacja musi komunikować się bezpośrednio z serwerami zasobów, takimi jak statyczna usługa pobierająca codzienne posty itp. Możesz skorzystać z przewodnika [machine-to-machine: Uwierzytelnianie z Logto](https://docs.logto.io/quick-starts/m2m/), aby uzyskać uwierzytelnianie do aplikacji typu M2M. Integracja między Supabase a aplikacjami typu machine-to-machine jest podobna do integracji z aplikacjami natywnymi i SPA (jak opisano w sekcji „Aplikacja natywna lub jednostronicowa aplikacja”). Polega ona na uzyskaniu tokenu dostępu z Logto i następnie jego weryfikacji przez chronione API backendowe. Jednakże ważne jest zaznaczenie, że aplikacje natywne i SPA są zazwyczaj projektowane dla użytkowników końcowych, więc uzyskane id użytkownika reprezentuje samego użytkownika. Jednak token dostępu dla aplikacji M2M reprezentuje aplikację, a pole `sub` w payloadzie tokena dostępu to client id aplikacji M2M, a nie konkretnego użytkownika. Dlatego w trakcie tworzenia ważne jest rozróżnienie, które dane są przeznaczone dla aplikacji M2M. Ponadto, jeśli chcesz, aby konkretna aplikacja M2M miała dostęp do Supabase w imieniu całej usługi, aby obejść ograniczenia RLS, możesz użyć sekretu `service_role` Supabase do utworzenia klienta Supabase. Jest to przydatne, gdy chcesz wykonywać zadania administracyjne lub zautomatyzowane, które wymagają dostępu do wszystkich danych bez ograniczeń ustanowionych politykami Zabezpieczeń na Poziomie Wiersza dla pojedynczych użytkowników. Sekret `service_role` można znaleźć na tej samej stronie co sekret JWT: Sekret roli serwisowej

Podczas tworzenia klienta Supabase użyj sekretu `service_role`, aby ten klient miał dostęp do wszystkich danych w bazie danych: ```jsx import { createClient } from '@supabase/supabase-js'; // ... const SUPABASE_SERVICE_ROLE_SCRET = process.env.SUPABASE_SERVICE_ROLE_SCRET; const client = createClient(SUPABASE_URL, SUPABASE_SERVICE_ROLE_SCRET, { // ...opcje }); ``` ## Podsumowanie W tym artykule szczegółowo omówiono integrację Logto z Supabase, przedstawiając kluczowe informacje i istotne aspekty integracji. Omawiamy takie pojęcia jak uwierzytelnianie JWT oraz polityki Zabezpieczeń na Poziomie Wiersza, prowadząc Cię przez proces bezproblemowego włączenia Logto do aplikacji zasilanych przez Supabase. Z tą wiedzą mamy nadzieję, że z pełnym przekonaniem zwiększysz bezpieczeństwo, funkcjonalność swojej aplikacji, a nawet rozszerzysz swoje projekty o dodatkowe funkcje.