You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Feb 24, 2024. It is now read-only.
Copy file name to clipboardExpand all lines: auth.rst
+1-1
Original file line number
Diff line number
Diff line change
@@ -298,7 +298,7 @@ PostgREST uses JWT mainly for authentication and authorization purposes and enco
298
298
Schema Isolation
299
299
================
300
300
301
-
A PostgREST instance is configured to expose all the tables, views, and stored procedures of a single schema specified in a server configuration file. This means private data or implementation details can go inside a private schema and be invisible to HTTP clients. You can then expose views and stored procedures which insulate the internal details from the outside world. It keeps you code easier to refactor, and provides a natural way to do API versioning. For an example of wrapping a private table with a public view see the :ref:`public_ui` section below.
301
+
You can isolate your api schema from internal implementation details, as explained in :ref:`schema_structure`. For an example of wrapping a private table with a public view see the :ref:`public_ui` section below.
Copy file name to clipboardExpand all lines: best_practices.rst
+13-7
Original file line number
Diff line number
Diff line change
@@ -1,14 +1,20 @@
1
1
2
-
Schema structure
3
-
----------------
2
+
.. _schema_structure:
3
+
4
+
Schema Structure
5
+
================
6
+
7
+
A PostgREST instance exposes all the tables, views, and stored procedures of a single `PostgreSQL schema <https://www.postgresql.org/docs/12/ddl-schemas.html>`_ (a namespace of database objects). This means private data or implementation details can go inside different private schemas and be invisible to HTTP clients.
8
+
9
+
It is recommended that you don't expose tables on your API schema. Instead expose views and stored procedures which insulate the internal details from the outside world.
10
+
This allows you to change the internals of your schema and maintain backwards compatibility. It also keeps your code easier to refactor, and provides a natural way to do API versioning.
4
11
5
12
.. image:: _static/db.png
6
-
:align:center
7
13
8
14
.. _func_privs:
9
15
10
16
Function privileges
11
-
-------------------
17
+
===================
12
18
13
19
By default, when a function is created, the privilege to execute it is not restricted by role. The function access is PUBLIC—executable by all roles(more details at `PostgreSQL Privileges page <https://www.postgresql.org/docs/12/ddl-priv.html>`_). This is not ideal for an API schema. To disable this behavior, you can run the following SQL statement:
14
20
@@ -17,7 +23,7 @@ By default, when a function is created, the privilege to execute it is not restr
17
23
-- Assuming your schema is named "api"
18
24
ALTER DEFAULT PRIVILEGES IN SCHEMA api REVOKE EXECUTE ON FUNCTIONS FROM PUBLIC;
19
25
20
-
-- Or to stop functions from being executable in the whole database(note the removal of the IN SCHEMA part).
26
+
-- Or to stop functions from being PUBLICly executable in the whole database
21
27
ALTER DEFAULT PRIVILEGES REVOKE EXECUTE ON FUNCTIONS FROM PUBLIC;
22
28
23
29
See `PostgreSQL alter default privileges <https://www.postgresql.org/docs/current/static/sql-alterdefaultprivileges.html>`_ for more details.
@@ -40,7 +46,7 @@ By default, a function is executed with the privileges of the user who calls it.
40
46
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 <https://www.postgresql.org/docs/current/static/sql-createfunction.html#SQL-CREATEFUNCTION-SECURITY>`_ for more details.
41
47
42
48
Views with RLS
43
-
--------------
49
+
==============
44
50
45
51
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 <https://www.postgresql.org/docs/current/static/ddl-rowsecurity.html>`_ will be bypassed unless a different, non-SUPERUSER owner is specified.
46
52
@@ -53,7 +59,7 @@ Views are invoked with the privileges of the view owner, much like stored proced
53
59
ALTER VIEW sample_view OWNER TO api_views_owner;
54
60
55
61
Views with Rules
56
-
----------------
62
+
================
57
63
58
64
Insertion on VIEWs with complex `RULEs <https://www.postgresql.org/docs/11/sql-createrule.html>`_ might not work out of the box with PostgREST.
59
65
It's recommended that you `use triggers instead of RULEs <https://wiki.postgresql.org/wiki/Don%27t_Do_This#Don.27t_use_rules>`_.
0 commit comments