thx for responding, please can you elaborate - don...
# sql
c
thx for responding, please can you elaborate - don't quite undertstand that first part - what do i need on insert?
g
Never mind, you have a select RLS set. That part should be good. Every insert also does a select on Supabase by default so you have to have select RLS set and you do, plus you have minimal set. I responded to quickly.
So your problem is you are not inserting an uuid for the id column.
When you insert it checks the incoming data and does not find the uuid and rejects the operation
Also I think on delete you want id not user_id
c
ahhh right so you always need that? because i understood that it would get that from the fact the user is authd?
g
Well you would have to get the default id to be the auth id as default for that column, but then you would not use insert RLS on it.
c
ok sweet - so I understand what you mean about setting auth id as the default - not sure why i wouldn't then use insert RLS on that though? - setting the id in the js worked though thank you very much for that!
g
On the RLS, if it even works checking the default values (I’m not sure) it is still a waste cause it will never fail as you are setting to the value you are checking against.
Just to be clear though if you set it thru JavaScript you need to use RLS.
In thinking about it, for the set by default case, you would want RLS to at least check for logged in user to make sure they had a UUID.
c
cool - Will always leave RLS on anyway as its extra protection. So this works:
Copy code
create table public.keys (
  id uuid references auth.users not null DEFAULT auth.uid(),
  inserted_at timestamp with time zone DEFAULT timezone('utc'::text, now()) NOT NULL,
  address text,
  data text,
  primary key (id)
);

alter table public.keys enable row level security;

create policy "Users can insert their own keys."
  on public.keys for insert
  with check ( auth.uid() = id );
g
Just for completeness, if a user is not logged in I believe auth.uid will return null. This would pass the RLS but in your case only fail because you have null not allowed for that column. I’d probably check role for authorized instead on the insert.
c
interesting. So still check
auth.uid() = id
for select/update/delete but for insert just make sure they are authd?
so like
Copy code
sql
create table public.keys (
  id uuid references auth.users not null DEFAULT auth.uid(),
  inserted_at timestamp with time zone DEFAULT timezone('utc'::text, now()) NOT NULL,
  address text,
  data text,
  primary key (id)
);

alter table public.keys enable row level security;

create policy "Users can insert their own keys."
  on public.keys for insert
  with check ( auth.role() = 'authorized'::text );

create policy "Users can view their own keys."
  on public.keys for select
  using ( auth.uid() = id );

CREATE POLICY "Users can delete own keys."
  ON public.keys for delete 
  using ( auth.uid() = id );
g
Your no null protects you so you were fine, but that was probably luck. I'm not doing anything like that, but seems like better to have RLS really do something than rely on the insert failing.
c
yeah agreed - prefer to have RLS on regardless but just want to simplify process from the front end perspective
hence wanting the default there so only have to send the data to insert