Comment by jgraettinger1 | Hacker News Reader

Comment by jgraettinger1 | Hacker News Reader

Parent Full thread

> Row level security is their "foundational piece", but there is a reason why we moved away from database functions and application logic in database over a decade ago: that stuff in unmaintainable.

Funny. In my experience, application-level authorization checks are very error-prone, easy to accidentally omit, and difficult to audit for correctness."Unmaintainable", I suppose.

Whereas RLS gives you an understandable authorization policy with a baseline assurance that you're not accidentally leaking records you shouldn't be.

RLS is great, but it's not that hard to shoot yourself in the foot or miss stuff. E.g.:

  ALTER TABLE bookmarks ENABLE ROW LEVEL SECURITY;
  CREATE POLICY bookmarks_owner ON bookmarks USING (owner_id = auth.uid());
  CREATE VIEW recent_bookmarks AS SELECT * FROM bookmarks ORDER BY created_at DESC LIMIT 5;

The above may look fine at first glance, but recent_bookmarks actually bypasses RLS.

For that there's security invoker now:

  CREATE VIEW recent_bookmarks WITH (security_invoker=true) AS 
  SELECT * FROM bookmarks ORDER BY created_at DESC LIMIT 5;

Point taken though, it's not the default behavior.

Indeed - one of the great changes in v15. (for any folks on previous versions, you need to change the view owner to a non-superuser role without the bypassrls attribute).

Thanks for all your work on PostgREST, Steve! Do you think we'll see relational inserts in the near future, or is that still a bit down the road?

Reply on news.ycombinator.com