Supabase als backenddienst · Les

RLS testen en debuggen

Leer strategieën om uw RLS-beleid effectief te testen, zodat u zeker weet dat het zich gedraagt zoals verwacht, en toegangsproblemen te debuggen

Les 2 van 312 stappen

RLS testen en debuggen is een gratis Supabase als backenddienst-les op CoddyKit. Dit is les 2 van 3. Je kunt de volledige les hieronder gratis lezen en daarna in de browser praktisch oefenen met een ingebouwde code-editor en een AI-begeleider die 24/7 beschikbaar is. Deze les maakt deel uit van het leertraject Supabase als backenddienst. Je voortgang wordt gesynchroniseerd op het web en in de CoddyKit-app. De cursus Supabase als backenddienst bevat in totaal 3 lessen.

Waarom RLS-beleidsregels testen?

Row-Level Security (RLS) is krachtig, maar lastig. Het bepaalt rechtstreeks op databaseniveau wie gegevens kan bekijken en wijzigen. Een kleine fout kan gevoelige informatie blootleggen of legitieme gebruikers de toegang ontzeggen.

Beveiliging waarborgen: Bevestig dat gevoelige gegevens beschermd zijn.
Functionaliteit: Zorg ervoor dat gebruikers toegang hebben tot wat ze nodig hebben.
Fouten voorkomen: Spoor onbedoelde toegangsproblemen vroegtijdig op.

Het testen van RLS is cruciaal voor een veilige en goed werkende toepassing.

Twee belangrijke testmethoden

Je kunt je RLS-beleid testen met twee primaire methoden:

SQL Editor (databaseniveau): Werk rechtstreeks met je database via SQL en doe alsof je verschillende gebruikers bent. Dit is ideaal voor geïsoleerde tests.
Clientzijde (toepassingsniveau): Test via de frontend- of backendcode van je toepassing door geauthenticeerde API-aanvragen te doen. Hiermee valideer je de volledige gegevensstroom.

Beide methoden bieden unieke inzichten in de werking van je RLS-beleid.

Methode 1: SQL Editor met SET ROLE

De meest directe manier om RLS te testen is door de Supabase SQL Editor te gebruiken om je voor te doen als een gebruiker. Met PostgreSQL kun je tijdelijk de rechten van een andere rol (gebruiker) aannemen met de opdracht SET ROLE.

Zo kun je query's uitvoeren alsof je die specifieke gebruiker bent en precies zien welke gegevens die gebruiker volgens je RLS-beleid kan bekijken of wijzigen.

Demo van SET ROLE: je voordoen als een gebruiker

Schakel eerst RLS in voor je tabel. Maak daarna een beleid. Zo test je het in de SQL Editor. We gebruiken voor deze demonstratie een fictieve gebruikers-ID.

Opmerking: Vervang 'auth.jwt()' door je werkelijke JWT-payload als je test met het token van een echte gebruiker, of gebruik een specifieke auth.uid() als je een bekende gebruikers-ID hebt.

-- 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);

Toegang controleren met SELECT

Nadat je de rol hebt ingesteld of auth.uid() hebt nagebootst, kun je eenvoudige SELECT-, INSERT-, UPDATE- of DELETE-instructies uitvoeren om het effect ervan te bekijken. Als je RLS-beleid werkt, zie je alleen de rijen waartoe de nagebootste gebruiker toegang heeft (of die deze gebruiker kan beïnvloeden).

Als je te veel of te weinig ziet, moet je je beleid mogelijk aanpassen.

Methode 2: testen aan de clientzijde

RLS testen via de code van je toepassing is cruciaal, omdat dit het gebruik in de praktijk nabootst. Je doet geauthenticeerde aanvragen met de Supabase-clientbibliotheek (bijvoorbeeld JavaScript of Python).

Wanneer een gebruiker zich aanmeldt, voegt de clientbibliotheek automatisch diens JWT toe aan API-aanvragen. Supabase gebruikt deze JWT vervolgens om de auth.uid() te bepalen en het RLS-beleid overeenkomstig toe te passen.

Demo aan de clientzijde: geauthenticeerde gegevens ophalen

Dit conceptuele JavaScript-fragment laat zien hoe de sessie van een ingelogde gebruiker wordt gebruikt om gegevens op te halen. Het RLS-beleid voor de tabel posts filtert de resultaten automatisch op basis van de geauthenticeerde gebruiker.

Hier is geen specifieke SET ROLE nodig; de Supabase-client en backend regelen dit.

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()

RLS opsporen: EXPLAIN ANALYZE

Wanneer RLS zich niet gedraagt zoals verwacht, is EXPLAIN ANALYZE je beste hulpmiddel. Deze SQL-opdracht toont het uitvoeringsplan van een query, inclusief de manier waarop RLS-beleid wordt toegepast.

Zoek in het plan naar de stap "Filter". Die geeft aan waar de voorwaarden van je RLS-beleid worden geëvalueerd. Zo kun je controleren of je beleid überhaupt wordt meegenomen en of de voorwaarden efficiënt zijn.

Demo van EXPLAIN ANALYZE

Voer dit uit in de SQL Editor (nadat je de gebruikersrol of -ID zoals eerder hebt ingesteld) om te zien hoe RLS het queryplan beïnvloedt. De uitvoer bevat de stappen voor het uitvoeren van de query.

Bekijk de uitvoer op regels die verband houden met je RLS-beleid. Deze verschijnen vaak als Filter: (auth.uid() = posts.user_id) of iets vergelijkbaars.

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);

Veelvoorkomende valkuilen bij RLS

Bij het opsporen van problemen moet je vaak controleren op veelvoorkomende fouten:

RLS niet ingeschakeld: Heb je ALTER TABLE your_table ENABLE ROW LEVEL SECURITY; uitgevoerd?
Ontbrekend beleid: Zonder beleid is er geen toegang (tenzij de standaardinstelling toegang toestaat).
Onjuiste USING/WITH CHECK: De voorwaarden komen mogelijk niet overeen met je bedoeling. USING gebruik je voor lezen, bijwerken en verwijderen; WITH CHECK voor invoegen en bijwerken.
Volgorde van beleid: Meerdere beleidsregels worden voor toegang met OR gecombineerd.
Omzeiling door superuser: Houd er rekening mee dat de gebruiker postgres RLS omzeilt.

Test je kennis van RLS

Je hebt geleerd hoe je RLS kunt testen en problemen kunt opsporen. Laten we kijken of je de beste manier kunt herkennen om het gedrag van een RLS-beleid voor een specifieke gebruiker in de Supabase SQL Editor te controleren.

Beantwoord dit in de interactieve les

Samenvatting: RLS testen en problemen opsporen

In deze les heb je geleerd hoe je je Row-Level Security-beleid effectief kunt testen en problemen kunt opsporen. We hebben het volgende behandeld:

Het belang van RLS testen voor beveiliging en functionaliteit.
De SQL Editor met SET ROLE en set_config gebruiken om gebruikers na te bootsen.
RLS testen via geauthenticeerde aanvragen aan de clientzijde.
EXPLAIN ANALYZE gebruiken om te begrijpen hoe RLS-beleid wordt toegepast.
Veelvoorkomende valkuilen bij RLS herkennen en oplossen.

Grondige tests zorgen ervoor dat je gegevens veilig blijven en toegankelijk zijn zoals bedoeld.

Gratis beginnen

Leer Supabase als backenddienst met een AI-tutor — gratis

Schrijf echte code en voer die uit in je browser, krijg direct hulp van een AI-tutor die 24/7 beschikbaar is en ga verder waar je gebleven bent op het web of in de app.

Cursussen: 11
Lessen: 40

Gratis beginnen met leren Bekijk de volledige cursus

Veelgestelde vragen

Is de les “RLS testen en debuggen” gratis?

Ja — de volledige tekst van “RLS testen en debuggen” kun je hier gratis op het web lezen. Als je interactief wilt oefenen met een ingebouwde code-editor en een AI-begeleider die 24/7 beschikbaar is, en de rest van de cursus Supabase als backenddienst wilt ontgrendelen, kun je upgraden naar CoddyKit PRO. De cursus Supabase als backenddienst bevat in totaal 3 lessen.

Wat leer ik in “RLS testen en debuggen”?

Leer strategieën om uw RLS-beleid effectief te testen, zodat u zeker weet dat het zich gedraagt zoals verwacht, en toegangsproblemen te debuggen Je oefent met Supabase als backenddienst door code rechtstreeks in de browser uit te voeren. Een AI-begeleider die 24/7 beschikbaar is beantwoordt je vragen terwijl je de les doorwerkt.

Heb ik ervaring nodig om met Supabase als backenddienst te beginnen?

Ervaring vooraf is niet nodig. Supabase als backenddienst op CoddyKit is opgebouwd voor beginners tot gevorderden, zodat je hier of bij het begin kunt starten en in je eigen tempo kunt leren. Dit is les 2 van 3.

Hoe lang duurt de les “RLS testen en debuggen”?

De meeste lessen van CoddyKit duren ongeveer 5–10 minuten. Elke les is kort en interactief, zodat je gestaag vooruitgaat en op het web en in de app precies verdergaat waar je was gebleven.

Kan ik code schrijven en uitvoeren in deze les over Supabase als backenddienst?

Ja. Elke les over Supabase als backenddienst bevat een ingebouwde code-editor, zodat je rechtstreeks in je browser echte code kunt schrijven en uitvoeren en direct feedback van AI krijgt — lokale installatie is niet nodig.

Alle lessen in deze cursus

Kennismaking met RLS-policies
RLS testen en debuggen
Rolgebaseerde toegang met RLS en custom claims

← Terug naar Supabase als backenddienst