---
title: "Supabase raw_user_meta_data: kā reģistrācija kļuva par Owner"
description: "handle_new_user trigeris ņēma role_id no raw_user_meta_data, ko nosaka pārlūks. Kā jebkurš kļuva par Owner, labojums ar ielūgumiem un 1 minūtes pārbaude."
url: "https://madsalt.tech/lv/notes/supabase-raw-user-meta-data-role/"
author: "Denys Zaichenko"
language: "lv"
published: 2026-10-18
---

# Supabase raw_user_meta_data: kā reģistrācija kļuva par Owner

Īsumā

`raw_user_meta_data` glabā visu, ko pārlūks nodeva `supabase.auth.signUp()`. Vienā produkcijas lietotnē `handle_new_user` trigeris no turienes nolasīja jaunā lietotāja lomu, tāpēc jebkurš varēja reģistrēties ar Owner lomas id un pārņemt kontu. Labojums: loma nāk no tabulas, ko raksta tikai serveris un kas tiek aizpildīta pirms ielūguma nosūtīšanas.

Tas notika [revīzijas uzņēmuma darba laika uzskaites](https://madsalt.tech/lv/work/audit-firm-time-tracking/) lietotnē, Supabase lietotnē, kur katrs piekļuves noteikums dzīvo datubāzē. Kļūda bija trigerī, kas katram jaunam lietotājam izveido profilu.

## Ko darīja trigeris?

Vienkāršotā veidā tas izskatījās šādi:

```sql
create function public.handle_new_user()
returns trigger
language plpgsql
security definer set search_path = ''
as $$
declare
  _role_id uuid := (new.raw_user_meta_data ->> 'role_id')::uuid;
begin
  insert into public.profiles (id, full_name, role_id)
  values (new.id, new.raw_user_meta_data ->> 'full_name', _role_id);
  return new;
end;
$$;
```

Ielūgumu plūsma tur ielika pareizo `role_id`, tāpēc ierastā lietojumā tas strādāja. Taču `raw_user_meta_data` ir reģistrācijas `options.data`, un tā saturu nosaka pārlūks:

```js
await supabase.auth.signUp({
  email: 'me@example.com',
  password: '...',
  options: { data: { role_id: '<owner role uuid>' } },
})
```

Atļauju pārbaude īpašniekiem atgrieza true, pirms skatījās uz jebko citu, tāpēc šis viens lauks deva pilnu kontroli pār kontu. Pašas Supabase [Users guide](https://supabase.com/docs/guides/auth/users) saka, ka lietotāja metadatus nedrīkst izmantot RLS politikās vai autorizācijas loģikā, jo lietotājs tos var rediģēt bez jebkādām pārbaudēm.

![No kurienes nāca jaunā lietotāja loma. handle_new_user trigeris pirms labojuma un pēc tā. Pirms: ikviens, kas reģistrējas: signUp options.data → raw_user_meta_data → handle_new_user → Owner loma; Pēc: tikai ielūgtie cilvēki: Ielūguma funkcija → pending_invites → handle_new_user → Ielūgtā loma.](https://madsalt.tech/charts/lv/supabase-raw-user-meta-data-role.svg)

*No produkcijas Supabase lietotnes reģistrācijas trigera, 2026. gada jūnijs.*

## Kas to izlaboja?

Loma tagad nāk no privātas tabulas, kurai klients nevar piekļūt:

```sql
create table private.pending_invites (
  email text primary key,
  role_id uuid,
  invited_by uuid,
  created_at timestamptz default now()
);
revoke all on table private.pending_invites from anon, authenticated;
```

Ielūguma funkcija darbojas serverī pēc tam, kad pārbaudīta ielūdzēja atļauja. Tā vispirms ieraksta gaidošo ielūgumu un tikai tad izveido ielūguma saiti. Trigeris atrod lomu pēc e-pasta un izdzēš rindu. Vārds joprojām nāk no metadatiem, un tas ir kārtībā: tie ir attēlošanas dati.

Secībai ir nozīme. Ielūgums lietotāju izveido uzreiz: Supabase [Users guide](https://supabase.com/docs/guides/auth/users) norāda, ka jauna e-pasta ielūgšana izveido neapstiprinātu lietotāju. Trigeris iedarbojas tajā brīdī, tāpēc gaidošajai rindai jau jābūt.

## Kā pārbaudīt savu lietotni?

Atveriet savu `handle_new_user` funkciju vai jebkuru trigeri uz `auth.users` un meklējiet `raw_user_meta_data`. Vārds un avatārs no turienes ir kārtībā. Loma, uzņēmums, plāns, nomnieks vai jebkas cits, kas dod piekļuvi, jāņem no tabulas vai no `raw_app_meta_data`, ko lietotājs mainīt nevar.

Tad pamēģiniet: reģistrējieties caur API, ierakstot `options.data` laukā `role_id` vai `role: 'admin'`. Jaunajam kontam nevajadzētu iegūt neko papildus.

Šāda pārbaude ir mana [RLS testēšanas metodes](https://madsalt.tech/lv/blog/how-to-test-supabase-rls/) pirmais solis. Vairāku nomnieku lietotnēm skatiet arī [ko RLS izlaiž lietotājam divās org.](https://madsalt.tech/lv/notes/supabase-rls-user-in-two-organizations/). Pārējās pārbaudes, ko veicu katrā Supabase lietotnē, ir manā [Lovable lietotnes drošības kontrolsarakstā](https://madsalt.tech/lv/blog/lovable-app-security-checklist/). Pirmais, ko skatos Dashboard, ir [kuras shēmas atklāj Data API](https://madsalt.tech/lv/notes/supabase-exposed-schemas/). [Supabase drošības pārbaude](https://madsalt.tech/lv/tools/supabase-security-check/) aptver lomas, tiesības, politikas un autentifikācijas iestatījumus pret 46 OWASP Top 10:2025 noteikumiem, bet ne to, ko trigeris pārkopē no reģistrācijas metadatiem, tāpēc šī paliek manuāla pārbaude.