by radimm on 6/10/24, 6:49 AM with 18 comments
by ufmace on 6/10/24, 11:45 PM
It's slick when the default query API does everything you need. But it seems inevitable that you'll eventually need to do something it doesn't support well. Then you're building views and stored procedures. Okay, those can work, but version control, unit testing, composeability, etc just aren't at the level of any mainstream web framework. Not to mention logging, tracing, etc. The complexity is going to get unmanageable fast, and then what?
And the auth. It probably works okay with a few dozen users who are all trusted. Would you trust the Postgres auth system with tens of thousands of users, many of who are internet randos who may be malicious? It feels like a recipe for disaster.
But then if you're only supporting trusted users doing basic stuff, why not let them use a regular DB client rather than this API?
by billllll on 6/11/24, 12:04 AM
Taking a look at the docs here:
https://postgrest.org/en/v12/references/auth.html
https://postgrest.org/en/v12/explanations/db_authz.html
It doesn't seem like current_user_id() is a provided function, and the docs claim nothing else is done with the JWT except validating it. It looks like your claim already includes user_id, so you'd have to get it from the claim using:
current_setting('request.jwt.claims', true)::json->>'user_id';
Not sure if I'm missing something.by xrd on 6/10/24, 11:22 PM
Anyone used both and can offer a comparison?
by wg0 on 6/10/24, 11:13 PM