From 6b72da38e622e4488378fe7e681c4084568ebb69 Mon Sep 17 00:00:00 2001 From: steve-chavez Date: Thu, 16 Apr 2020 18:01:07 -0500 Subject: [PATCH] Move some api notes to best practices --- api.rst | 18 ------------------ best_practices.rst | 19 +++++++++++++++++++ 2 files changed, 19 insertions(+), 18 deletions(-) diff --git a/api.rst b/api.rst index 55dae2a3f..fd62a0f92 100644 --- a/api.rst +++ b/api.rst @@ -103,18 +103,6 @@ The view will provide a new endpoint: GET /fresh_stories HTTP/1.1 -.. important:: - - Views are invoked with the privileges of the view owner, much like stored procedures with the ``SECURITY DEFINER`` option. When created by a SUPERUSER role, all `row-level security `_ will be bypassed unless a different, non-SUPERUSER owner is specified. - - .. code-block:: postgres - - -- Workaround: - -- non-SUPERUSER role to be used as the owner of the views - CREATE ROLE api_views_owner; - -- alter the view owner so RLS can work normally - ALTER VIEW sample_view OWNER TO api_views_owner; - .. _fts: Full-Text Search @@ -932,12 +920,6 @@ Updates also support :code:`Prefer: return=representation` plus :ref:`v_filter`. Beware of accidentally updating every row in a table. To learn to prevent that see :ref:`block_fulltable`. -.. warning:: - - Insertion on VIEWs with complex `RULEs `_ might not work out of the box with PostgREST. - It's recommended that you `use triggers instead of RULEs `_. - If you want to keep using RULEs, a workaround is to wrap the VIEW insertion in a stored procedure and call it through the :ref:`s_procs` interface. - .. _bulk_insert: Bulk Insert diff --git a/best_practices.rst b/best_practices.rst index c8ecdbc09..34e9c473b 100644 --- a/best_practices.rst +++ b/best_practices.rst @@ -20,3 +20,22 @@ By default, a function is executed with the privileges of the user who calls it. Another option is to define the function with the :code:`SECURITY DEFINER` option. Then only one permission check will take place, the permission to call the function, and the operations in the function will have the authority of the user who owns the function itself. See `PostgreSQL documentation `_ for more details. +Views with RLS +-------------- + +Views are invoked with the privileges of the view owner, much like stored procedures with the ``SECURITY DEFINER`` option. When created by a SUPERUSER role, all `row-level security `_ will be bypassed unless a different, non-SUPERUSER owner is specified. + +.. code-block:: postgres + + -- Workaround: + -- non-SUPERUSER role to be used as the owner of the views + CREATE ROLE api_views_owner; + -- alter the view owner so RLS can work normally + ALTER VIEW sample_view OWNER TO api_views_owner; + +Views with Rules +---------------- + +Insertion on VIEWs with complex `RULEs `_ might not work out of the box with PostgREST. +It's recommended that you `use triggers instead of RULEs `_. +If you want to keep using RULEs, a workaround is to wrap the VIEW insertion in a stored procedure and call it through the :ref:`s_procs` interface.