RLS and user identity

What you can do today

The user table lives in the runlot_auth schema of your project database. You can join against it like any other table.

select p.id, p.title, u.email
from posts p
join runlot_auth.users u on u.id = p.owner_id
order by p.id desc
limit 20;

For now, check permissions in your worker code.

const user = await env.auth.user(request);
if (!user) return new Response(null, { status: 401 });

const rows = await env.db.exec(
  "select id, title from posts where owner_id = $1 order by id desc limit 20",
  [user.id],
);

What is not supported yet

The runlot_auth.uid() function already exists.

create or replace function runlot_auth.uid() returns uuid language sql stable as $$
  select (nullif(current_setting('request.jwt.claims', true), '')::json->>'sub')::uuid
$$;

But the request.jwt.claims setting is not populated today, so the function always returns NULL. If you use runlot_auth.uid() in an RLS policy right now, every row is filtered out.

Preparing for RLS

If you plan to use RLS, you can already design your schema to store user IDs. Make the owner column a uuid and store runlot_auth.users.id in it. All you have to defer until the feature ships is turning the RLS policies on.

alter table posts add column owner_id uuid not null;
create index on posts (owner_id);
-- Add the RLS policies once the feature ships.

We will update this page when support changes.