Supabase som backend som tjeneste · leksjon

Testing og feilsøking av RLS

Lær strategier for effektiv testing av RLS-policyer, slik at de oppfører seg som forventet, og for feilsøking av tilgangsproblemer

Leksjon 2 av 312 trinn

Testing og feilsøking av RLS er en gratis leksjon i Supabase som backend som tjeneste på CoddyKit. Dette er leksjon 2 av 3. Du kan lese hele leksjonen gratis nedenfor – og deretter øve praktisk i nettleseren med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i Supabase som backend som tjeneste, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i Supabase som backend som tjeneste inneholder totalt 3 leksjoner.

Hvorfor teste RLS-policyer?

Row-Level Security (RLS) er kraftig, men krevende. Den styrer hvem som kan se og endre data direkte på databasenivå. En liten feil kan eksponere sensitiv informasjon eller blokkere legitime brukere.

Sikkerhet: Bekreft at sensitive data er beskyttet.
Funksjonalitet: Sørg for at brukerne får tilgang til det de trenger.
Forhindre feil: Oppdag utilsiktede tilgangsproblemer tidlig.

Det er avgjørende å teste RLS for å sikre en trygg og funksjonell applikasjon.

To hovedmetoder for testing

Du kan teste RLS-policyene dine ved hjelp av to hovedmetoder:

SQL Editor (databasenivå): Samhandle direkte med databasen ved hjelp av SQL, og opptre som forskjellige brukere. Dette egner seg godt til isolert testing.
Klientsiden (applikasjonsnivå): Test gjennom applikasjonens frontend- eller backend-kode ved å sende autentiserte API-forespørsler. Dette validerer hele flyten.

Begge metodene gir unik innsikt i hvordan RLS-policyene oppfører seg.

Metode 1: SQL Editor med SET ROLE

Den mest direkte måten å teste RLS på er å bruke Supabase SQL Editor til å opptre som en bruker. PostgreSQL lar deg midlertidig overta tillatelsene til en annen rolle (bruker) ved hjelp av kommandoen SET ROLE.

Da kan du kjøre spørringer som om du var den aktuelle brukeren, og se nøyaktig hvilke data brukeren kan se eller endre i henhold til RLS-policyene dine.

SET ROLE-demo: Opptre som en bruker

Aktiver først RLS på tabellen. Opprett deretter en policy. Slik tester du den i SQL Editor. Vi bruker en eksempelbruker-ID for demonstrasjonen.

Merk: Bytt ut 'auth.jwt()' med den faktiske JWT-nyttelasten hvis du tester med tokenet til en ekte bruker, eller bruk en bestemt auth.uid() hvis du kjenner bruker-ID-en.

-- Assume a user with ID 'a1b2c3d4-e5f6-7890-1234-567890abcdef'
SET SESSION AUTHORIZATION 'postgres';

-- Temporarily set the auth.uid() function to return a specific ID
-- In a real scenario, this would be set by the JWT from the client
SELECT set_config('auth.request.jwt.claim.sub', 'a1b2c3d4-e5f6-7890-1234-567890abcdef', TRUE);

-- Now, run a query on a table with RLS enabled
-- For example, if you have a 'posts' table with an 'author_id' column
SELECT * FROM posts;

-- Reset session authorization
RESET SESSION AUTHORIZATION;

-- Clear the custom auth.uid() setting
SELECT set_config('auth.request.jwt.claim.sub', '', TRUE);

Bekrefte tilgang med SELECT

Etter at du har angitt rollen eller simulert auth.uid(), kan du kjøre enkle SELECT-, INSERT-, UPDATE- eller DELETE-setninger for å se effekten. Hvis RLS-policyen fungerer, skal du bare se (eller kunne påvirke) radene som den simulerte brukeren har tilgang til.

Hvis du ser for mye eller for lite, kan det hende at policyen må justeres.

Metode 2: Testing på klientsiden

Det er viktig å teste RLS gjennom applikasjonskoden, fordi det simulerer bruk i den virkelige verden. Du sender autentiserte forespørsler ved hjelp av Supabase-klientbiblioteket (for eksempel JavaScript eller Python).

Når en bruker logger inn, inkluderer klientbiblioteket automatisk brukerens JWT i API-forespørsler. Supabase bruker deretter denne JWT-en til å fastslå auth.uid() og bruke RLS-policyene tilsvarende.

Demo på klientsiden: Autentisert henting

Dette konseptuelle JavaScript-eksempelet viser hvordan en innlogget brukers økt brukes til å hente data. RLS-policyene på posts-tabellen filtrerer automatisk resultatene basert på den autentiserte brukeren.

Det er ikke nødvendig med en egen SET ROLE her; dette håndteres av Supabase-klienten og backend-systemet.

import { createClient } from '@supabase/supabase-js'

const supabaseUrl = 'YOUR_SUPABASE_URL'
const supabaseAnonKey = 'YOUR_SUPABASE_ANON_KEY'

const supabase = createClient(supabaseUrl, supabaseAnonKey)

async function fetchUserPosts() {
  // Assume user is already signed in
  const { data: { user } } = await supabase.auth.getUser()

  if (user) {
    const { data, error } = await supabase
      .from('posts')
      .select('*')

    if (error) {
      console.error('Error fetching posts:', error.message)
    } else {
      console.log('User posts:', data)
    }
  } else {
    console.log('No user signed in.')
  }
}

fetchUserPosts()

Feilsøking av RLS: EXPLAIN ANALYZE

Når RLS ikke oppfører seg som forventet, er EXPLAIN ANALYZE din beste hjelper. Denne SQL-kommandoen viser kjøringsplanen for en spørring, inkludert hvordan RLS-policyer brukes.

Se etter trinnet "Filter" i planen. Det viser hvor betingelsene i RLS-policyen evalueres. Dette hjelper deg med å bekrefte om policyen faktisk vurderes, og om betingelsene er effektive.

EXPLAIN ANALYZE-demo

Kjør dette i SQL Editor (etter at du har angitt brukerrollen/-ID-en som tidligere) for å se hvordan RLS påvirker spørringsplanen. Resultatet viser trinnene i kjøringen av spørringen.

Se etter linjer i resultatet som er knyttet til RLS-policyen, og som ofte vises som Filter: (auth.uid() = posts.user_id) eller noe tilsvarende.

SET SESSION AUTHORIZATION 'postgres';
SELECT set_config('auth.request.jwt.claim.sub', 'a1b2c3d4-e5f6-7890-1234-567890abcdef', TRUE);

EXPLAIN ANALYZE SELECT * FROM posts WHERE id = 1;

RESET SESSION AUTHORIZATION;
SELECT set_config('auth.request.jwt.claim.sub', '', TRUE);

Vanlige RLS-feller

Feilsøking innebærer ofte å se etter vanlige feil:

RLS er ikke aktivert: Kjørte du ALTER TABLE your_table ENABLE ROW LEVEL SECURITY;?
Manglende policy: Uten en policy er det ingen tilgang (med mindre standardinnstillingen tillater tilgang).
Feil USING/WITH CHECK: Betingelsene samsvarer kanskje ikke med hensikten din. USING brukes til lesing, oppdatering og sletting, mens WITH CHECK brukes til innsetting og oppdatering.
Rekkefølge på policyer: Flere policyer kombineres med OR for å avgjøre tilgang.
Omgåelse for superbrukere: Husk at brukeren postgres omgår RLS.

Test RLS-kunnskapen din

Du har lært om testing og feilsøking av RLS. La oss se om du kan finne den beste måten å bekrefte hvordan en RLS-policy oppfører seg for en bestemt bruker i Supabase SQL Editor.

Besvar den i den interaktive leksjonen

Oppsummering: Testing og feilsøking av RLS

I denne leksjonen lærte du hvordan du effektivt tester og feilsøker Row-Level Security-policyer. Vi gikk gjennom:

Hvor viktig det er å teste RLS for sikkerhet og funksjonalitet.
Bruk av SQL Editor med SET ROLE og set_config for å opptre som ulike brukere.
Testing av RLS gjennom autentiserte forespørsler fra klientsiden.
Bruk av EXPLAIN ANALYZE for å forstå hvordan RLS-policyer brukes.
Identifisering og løsning av vanlige RLS-feller.

Grundig testing sørger for at dataene dine forblir sikre og tilgjengelige slik du har tenkt!

Gratis å komme i gang

Lær deg Supabase som backend som tjeneste med en AI-veileder – gratis

Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.

Kurs: 11
Leksjoner: 40

Start læringen gratis Se hele kurset

Ofte stilte spørsmål

Er leksjonen «Testing og feilsøking av RLS» gratis?

Ja – hele teksten i «Testing og feilsøking av RLS» er gratis å lese her på nettet. For å øve interaktivt med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt, og for å låse opp resten av Supabase som backend som tjeneste-kurset, kan du oppgradere til CoddyKit PRO. Kurset i Supabase som backend som tjeneste inneholder totalt 3 leksjoner.

Hva lærer jeg i «Testing og feilsøking av RLS»?

Lær strategier for effektiv testing av RLS-policyer, slik at de oppfører seg som forventet, og for feilsøking av tilgangsproblemer Du øver på Supabase som backend som tjeneste med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.

Trenger jeg erfaring for å begynne med Supabase som backend som tjeneste?

Ingen tidligere erfaring er nødvendig. Supabase som backend som tjeneste på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 2 av 3.

Hvor lang tid tar leksjonen «Testing og feilsøking av RLS»?

De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.

Kan jeg skrive og kjøre kode i denne Supabase som backend som tjeneste-leksjonen?

Ja. Alle Supabase som backend som tjeneste-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.

Alle leksjonene i dette kurset

Introduksjon til RLS-policyer
Testing og feilsøking av RLS
Rollebasert tilgang med RLS og egendefinerte claims

← Tilbake til Supabase som backend som tjeneste