4 ms·

This would also allow browsers to act as direct database clients if I am interpreting this right? That means that your web app could act like "psql" and open a

This would also allow browsers to act as direct database clients if I am interpreting this right? That means that your web app could act like "psql" and open a direct TCP socket connection to "postgresql://user:pass@host:5432/db", which would change everything You'd no longer need a backend just to middleman SQL requests, assuming you have proper RLS implemented. (Whether or not this is a good idea/applicable to all cases is debatable, but it at least becomes possible if I'm reading right)

maybenotsofast 4y ago
Kinda curious. How do you propose to keep the db/cache login credentials secure on the client side in JavaScript? Wouldn't they be accessible to anyone reading the front end source files or plugins installed in the browser context?
- publicdatamaybe 4y ago
  For public data I am inclined to agree with the parent. You could just pass a single auth token to the database if it supported it for public data only and fetch it that way. Kinda like a bearer token, etc... Therefore having direct access to the database from the client side only for public data. This would be very beneficial to the web as a whole as a lot of the data is public data. Then the separation of privilege/access has to happen directly at the database level which is totally possible. Would be a nice addition to the web to treat public data differently.
  - worklikethis 4y ago
    At the database table level, each field could have the following properties which processed together would decide the level of access for that piece of data stored. data_access: private|public data_scope: single|composite data_exempt: age|gender|otherpiifield Somewhat protecting PII by not allowing querries which would infringe PII rules when selecting multiple sensitive fields.
- idsout 4y ago
  Temporary expirable sessions like we have today could be one way. Generate a temporary session (DB creds) for an authenticated user.
  - maybeagain 4y ago
    Maybe in the browser context it would reduce the security risk. However that db backend is still listening for logins, it does not know who the client is. What happens today imho is that you have access to pieces of the data tables not the whole database at once to run queries at will. When you fill out an html form or click a button that runs business logic code which might run sql queries based on a token/id you passed. That token/id does not have access to the whole database. Temporary database wide sessions are still a risk in the browser context.
matlin 4y ago
Very cool for projects like Hasura and Supabase which rely on middleman http servers (like PostgREST). But also great for building tools like database inspectors / SQL managers right in the browser!
xyzzy_plugh 4y ago
Alternatively databases could simply implement HTTP and do this today. Connecting browsers directly to databases is generally a bad idea for other reasons.

maybenotsofast 4y ago

Kinda curious. How do you propose to keep the db/cache login credentials secure on the client side in JavaScript? Wouldn't they be accessible to anyone reading the front end source files or plugins installed in the browser context?

publicdatamaybe 4y ago
For public data I am inclined to agree with the parent. You could just pass a single auth token to the database if it supported it for public data only and fetch it that way. Kinda like a bearer token, etc... Therefore having direct access to the database from the client side only for public data. This would be very beneficial to the web as a whole as a lot of the data is public data. Then the separation of privilege/access has to happen directly at the database level which is totally possible. Would be a nice addition to the web to treat public data differently.
- worklikethis 4y ago
  At the database table level, each field could have the following properties which processed together would decide the level of access for that piece of data stored. data_access: private|public data_scope: single|composite data_exempt: age|gender|otherpiifield Somewhat protecting PII by not allowing querries which would infringe PII rules when selecting multiple sensitive fields.
idsout 4y ago
Temporary expirable sessions like we have today could be one way. Generate a temporary session (DB creds) for an authenticated user.
- maybeagain 4y ago
  Maybe in the browser context it would reduce the security risk. However that db backend is still listening for logins, it does not know who the client is. What happens today imho is that you have access to pieces of the data tables not the whole database at once to run queries at will. When you fill out an html form or click a button that runs business logic code which might run sql queries based on a token/id you passed. That token/id does not have access to the whole database. Temporary database wide sessions are still a risk in the browser context.

matlin 4y ago

Very cool for projects like Hasura and Supabase which rely on middleman http servers (like PostgREST). But also great for building tools like database inspectors / SQL managers right in the browser!

xyzzy_plugh 4y ago

Alternatively databases could simply implement HTTP and do this today. Connecting browsers directly to databases is generally a bad idea for other reasons.