paint-brush
Így biztosíthatják a fejlesztők, hogy az érzékeny adatok véletlenül ne érjenek el egy másik eszköztáltal@dougsillars1
Új történelem

Így biztosíthatják a fejlesztők, hogy az érzékeny adatok véletlenül ne érjenek el egy másik eszközt

által Doug8m2024/12/25
Read on Terminal Reader

Túl hosszú; Olvasni

A fejlesztőknek gondoskodniuk kell arról, hogy az alkalmazásokban tárolt érzékeny adatok véletlenül se kerüljenek más félhez. Ez az oktatóanyag végigvezeti Önt, hogyan hozhat létre Remix alkalmazást a Clerk hitelesítési réteg használatával. Ezután a Neon Row Level Security-t használjuk az ügyféladatok védelmére.
featured image - Így biztosíthatják a fejlesztők, hogy az érzékeny adatok véletlenül ne érjenek el egy másik eszközt
Doug HackerNoon profile picture
0-item

Kaptad már a szomszédod csomagját a bejárati ajtódnál? (Lehet, hogy véletlenül is kinyitotta?) Lehet, hogy érzékeny hangposta maradt másnak? Alkalmazásfejlesztőként az Ön feladata annak biztosítása, hogy az alkalmazásában tárolt érzékeny adatok véletlenül se kerüljenek más félhez.


Számos technika áll rendelkezésre az ügyfelek adatainak biztonságos tárolására, és sok nagyon összetett és nehezen megvalósítható. Ideális esetben az összes ügyféladatot egyetlen adatbázisban lehetne védeni – így a funkció kialakítása egyszerű és biztonságos marad.


A sorszintű biztonság (RLS) az a képesség, hogy biztonságossá és vezérelhetővé váljon egy adatbázistáblán belüli meghatározott adatsorokhoz való hozzáférés. Ez egy hatékony eszköz, amely lehetővé teszi, hogy az összes ügyféladatot egyetlen adatbázisban tárolja anélkül, hogy aggódna a fiókok közötti adatszivárgás miatt. Az RLS helyes megvalósítása azonban bonyolult folyamat lehet, amely magában foglalja a bejelentkezési adatok és az adatbázis-engedélyek kombinálását. A Neon Authorize leegyszerűsíti ezt a folyamatot azáltal, hogy automatikusan integrálja az OAuth-szolgáltató hitelesítését a PostgreSQL-adatbázisba.


A Neon Authorize a meglévő hitelesítési réteget használja minden bejelentkezett felhasználó azonosítására, és az adatbázisban lévő összes adatot hozzárendeli a bejelentkezési hitelesítő adataihoz. Ez biztosítja, hogy az adatbázisban tárolt adatokhoz csak bejelentkezett felhasználók férhessenek hozzá – és csak a bejelentkezett felhasználók láthatják adataikat.


Ez az oktatóanyag végigvezeti Önt, hogyan hozhat létre Remix alkalmazást a Clerk hitelesítési réteg használatával. A Clerk egy népszerű felhasználói hitelesítési és -kezelő eszköz. Adatrétegként a Neon Postgres-t fogja használni, és a Neon Authorize segítségével biztosíthatja minden bejelentkezett ügyfél adatait. A táblázat minden sora kijelöl egy felhasználói azonosítót, amelyet a Clerk biztosít. Csak a felhasználói azonosítóval hitelesítettek léphetnek kapcsolatba a sorban lévő adatokkal.


Mintaalkalmazásunk egyszerű – minden bejelentkezést rögzít az RLS adatbázisba a felhasználói azonosító használatával. Az oldal betöltésekor a hitelesített felhasználó utolsó 10 bejelentkezése jelenik meg, és nem jelennek meg más felhasználók adatai (ugyanabban a PostgreSQL táblában tárolva). Kezdjük is!

A Remix alkalmazás létrehozása


Kezdje azzal, hogy hozzon létre egy Remix alkalmazást, és telepítse a függőségeket az alábbi kódrészlet segítségével. Részletesebb utasításokat a Remix gyors üzembe helyezési útmutatójában talál.

 ##make a directory and initialise your NPM project mkdir neon-authorize-remix-clerk-app cd neon-authorize-remix-clerk-app npm init -y ## install runtime dependecies for Remix npm i @remix-run/node @remix-run/react @remix-run/serve isbot@4 react react-dom @remix-run/router drizzle-orm npm install @neondatabase/serverless npm install @clerk/remix npm i -D @remix-run/dev vite


Mivel a Remix a Vite-t, egy Javascript-összeállítási eszközt használja, hozza létre vite.config.js a gyökérkönyvtárban:


 import { vitePlugin as remix } from "@remix-run/dev"; import { defineConfig } from "vite"; export default defineConfig({ plugins: [remix()], });


Mielőtt bármilyen fejlesztést végzünk, fiókokat kell létrehoznunk a Clerknél és a Neonnál szolgáltatásaik használatához:


Clerk és Neon példányok létrehozása

Hivatalnok

Új projekt létrehozásához jelentkezzen be a Clerk irányítópultra.

  1. A bal oldali navigációs panelen válassza az API-kulcsok lehetőséget.

    1. A Gyorsmásolás mezőben válassza a Remix lehetőséget, és másolja át a környezeti változókat.
    2. Illessze be őket egy .env fájlba a kódban.
  2. A bal oldali navigációs panelen válassza a „ JWT sablonok lehetőséget.

    1. Hozz létre egy sablont (az enyémet „ neon-remixnek ” neveztem el).
    2. Másolja ki a JWKS végpont URL-jét későbbi használatra.

Neon

  1. Jelentkezzen be a Neon konzolba, és hozzon létre egy új projektet.

  2. A bal oldali navigációs menüben válassza az Engedélyezés lehetőséget .

  3. Hozzon létre egy új szolgáltatót, és illessze be a Clerk JWKS URL-címét , amelyet korábban a Clerkről másolt.


Miután létrehozta a példányt, kattintson a „Kezdés” gombra. Megnyílik egy oldalsó panel a Neon Authorize integrációjának befejezéséhez szükséges lépések sorozatával.

Az első lépések beállítás lépéseiből áll, hogy beállítson egy alap engedélyezési projektet a Clerk segítségével.

 1. Set up Neon Extension and Roles Privileges. Run these steps in the Dashboard. 2. Grant privileges to the roles in the neondb database. 

A sorszintű biztonság beállítása

A megadott kód egy todos alkalmazásra vonatkozik. Ahelyett, hogy egy todos alkalmazáshoz használnánk a Neon által biztosított általános kódot, létrehozunk egy login_history táblát, és beállítjuk rajta az RLS-t. Nyissa meg az SQL-szerkesztőt a Neon irányítópulton, és futtassa az alábbi kódot. A login_history tábla az egyes felhasználók bejelentkezési idejét tárolja.


Vegye figyelembe, hogy login_history csak három oszlopból áll: az id, a user_id és a login_at. Az utolsó két oszlopban a legutóbbi bejelentkezési adatok jelennek meg az alkalmazásban.


 CREATE TABLE login_history ( id bigint generated by default as identity primary key, user_id text not null default (auth.user_id()), login_at timestamp not null default now() ); -- 1st enable row level security for your table ALTER TABLE login_history ENABLE ROW LEVEL SECURITY; -- 2nd create policies for your table CREATE POLICY "Individuals can add login." ON login_history FOR INSERT TO authenticated WITH CHECK ((select auth.user_id()) = user_id); CREATE POLICY "Individuals can view their own logins. " ON login_history FOR SELECT TO authenticated USING ((select auth.user_id()) = user_id);


Adja hozzá a megadott környezeti változókat .env fájlhoz



Ha ezek a beállítási lépések befejeződtek, az .env fájlnak négy változóval kell rendelkeznie: kettő a Clerktől és kettő a Neontól:

 CLERK_PUBLISHABLE_KEY=pk_test_.... CLERK_SECRET_KEY=sk_test_... # Database owner connection string DATABASE_URL='postgresql://neondb_owner:...' # Neon "authenticated" role connection string DATABASE_AUTHENTICATED_URL='postgresql://authenticated@ep-...


A Remix alkalmazás elkészítése

Az alkalmazás készen áll a felépítésre. A teljes kód elérhető a GitHubon , de itt kiemeljük a legfontosabb funkciókat. Az alkalmazás magja app/routes/_index.tsx fájlban található:


 export const loader: LoaderFunction = async (args) => { const { userId, getToken } = await getAuth(args); if (!userId) { return redirect("/sign-in"); } const authToken = await getToken(); console.log(userId); if (!authToken) { return null; } const DATABASE_AUTHENTICATED_URL= process.env.NEXT_PUBLIC_DATABASE_AUTHENTICATED_URL; try { const sql = neon(DATABASE_AUTHENTICATED_URL ?? '', { authToken, }); const loginResponse = await sql(`INSERT INTO login_history ("user_id") VALUES ($1) RETURNING *`,[userId]); // Retrieve last 10 logins const last10LoginsResponse = await sql(`SELECT * FROM login_history WHERE user_id = $1 ORDER BY login_at DESC LIMIT 10`, [userId]); console.log(`loginResponse: ${JSON.stringify(loginResponse)}`); return last10LoginsResponse as Array<LoginHistory>; } catch (error) { console.error(`Error inserting into login_history table: ${error.message}`); console.error(`Error details: ${JSON.stringify(error)}`); throw error; } }

Az _index.tsx fájl LoaderFunction befejezi a feladatokat a kiszolgálón, mielőtt az oldalt rendereli az ügyfél számára. Ebben az alkalmazásban a rakodó végzi az alkalmazás nehéz emelésének nagy részét.


A függvény először ellenőrzi, hogy a felhasználó nincs-e bejelentkezve, majd átirányítja a /sign-in oldalra. A bejelentkezési oldal az Ügyintéző irányítópultján konfigurálható úgy, hogy különböző bejelentkezési típusokat fogadjon el, például Google és e-mail bejelentkezéseket:


A bejelentkezési oldal létrehozásához lépjen a Clerk irányítópultra, és állítsa be a projekthez szükséges bejelentkezési módokat.


Ha a felhasználó be van jelentkezve, a függvény lekéri a userId és authToken a Clerk-től. Ezek az értékek elengedhetetlenek ahhoz, hogy a felhasználó be legyen jelentkezve, majd a userId segítségével feltöltheti az adatbázis minden sorát.


Az RLS által védett adatbázis módosításához ki kell húznia a DATABASE_AUTHENTCATED_URL a környezeti változókból.

Az RLS biztonság megvalósításának alapvető logikája a LoaderFunction -ban rejlik. Az SQL Neon-példány inicializálása a környezeti változók és a hitelesítési token használatával történik. A loginResponse függvény SQL-hívást indít, és beszúrja a user_id-t (és az aktuális időt) a PostgreSQL-adatbázisba, majd a last10LoginsResponse függvény lekérdezi a DB-ben a 10 legutóbbi bejelentkezést.


Végül a last10LoginsResponse visszaadásra kerül a betöltő függvény.


Az Index() függvény _index.tsx fájlban az oldal elrendezését jeleníti meg az alábbi részletben látható módon:


 export default function Index() { const logins = useLoaderData(); return ( <div> <h1>Signed in</h1> <p>You are signed in!</p> <p> <UserButton /></p> <div> <h1>Recent Logins</h1> {logins?.map((logins) => ( <li key={logins.id}> {logins.user_id} login at: {logins.login_at} </li> ))} </div> <p>< SignOutButton > Sign Out</ SignOutButton ></p> </div> ); }

A fenti kód a LoaderFunction válaszát kéri le, amely az utolsó 10 bejelentkezési bejegyzést tartalmazza. Ez a válasz létrehoz egy oldalt, amely közli a felhasználóval, hogy be van jelentkezve, felsorolja az utolsó 10 bejelentkezést, és egy Kijelentkezés gombot jelenít meg az alábbiak szerint:

A válasz visszaérkezett


Ebben a példában a user_id is megjelenik, hogy egyértelműen jelezze, hogy csak a bejelentkezett felhasználó bejelentkezési adatai láthatók.

Egy inkognitóablak használatával bejelentkezhet egy második Google-fiókkal, és megtekintheti a különböző felhasználók adatait egymás mellett:



Vegye figyelembe, hogy a bejelentkezési idők átfedésben vannak, de a sorszintű biztonság használatával az adatbázisban megakadályozhatja az adatszivárgást a fiókok között. A sorok csak a hitelesített felhasználó számára bonthatók ki és jeleníthetők meg.


Következtetés

Az adatok titkosságának megőrzése kritikus használati eset. Mivel az alkalmazások gyakran tárolnak személyes információkat, ezeket biztosítani kell, hogy az adatok megfelelő kezekben legyenek. A fogyasztók egyre több jogi védelmet élveznek, mint például a GDPR, és az olyan eszközök, mint a Neon Authorize, megkönnyítik a sorszintű biztonság bevezetését az ügyfelek adatainak védelme érdekében.


Ebben a bejegyzésben végigjártuk azokat a lépéseket, amelyek szükségesek ahhoz, hogy engedélyezzük a sorszintű biztonságot a Neon adatbázisban. Az RLS használata ügyfeleink adataival biztosítja, hogy csak a bejelentkezett felhasználó rendelkezzen a saját adatainak kinyeréséhez szükséges hitelesítési adatokkal.


Adja hozzá a Row Layer Security-t alkalmazásához még ma a Neon segítségével.