4 ms·
I investigated this and a few others for quickly spinning up a back office app, and settled on postgraphile. The endpoint that is exposed from the service is au
by baoluofu 5y ago
I investigated this and a few others for quickly spinning up a back office app, and settled on postgraphile. The endpoint that is exposed from the service is authenticated and a role is then set on the request object which postgraphile then uses to set the role for the database transaction. With appropriate roles set in the database, my back office users now have fine-grained permissions for reading/writing only to tables that I want them to.
- imbusy111 5y agoIt seems to me that it's the main limitation of this solution - authorization is limited to table scope so if you can update any row, you can update all rows for all users. Same for data querying. If you completely trust your users, that's fine.
- BenjieGillam 5y agoThat's not true; you can use row level security (RLS) to control access (both reading and writing) on a per-row basis. You can think of it as similar to an implicit "where" clause that automatically gets added to all requests. RLS: https://www.postgresql.org/docs/current/ddl-rowsecurity.html https://www.postgresql.org/docs/current/ddl-rowsecurity.html
- lisperforlife 5y agoWe built an entire system using RLS and functions. Postgraphile is frankly amazing. You can also extend the schema using Typescript or SQL.