4 ms·
> 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 dec
by jgraettinger1 3y ago
> 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.
- mfalcao 3y agoRLS 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.
- steve-chavez 3y agoFor 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.
- mfalcao 3y agoIndeed - 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?