3 ms·
i don't think this is a valid counterargument -- even if access is only given to views / stored procs you would have the same issue of a client connection direc
by fat0wl 12y ago
i don't think this is a valid counterargument -- even if access is only given to views / stored procs you would have the same issue of a client connection directly to the HTTP api having too coarse-grained security privileges since they could be executed with any input params (unless there was some kindof extra security layer spanning front-end to db layer? sounds crazy)
but this could be a moot point as long as db communication is only done server-side so it can be behind company firewall anyway -- after all, isn't that why the current db security model works? No one should EVER post ajax to the db, essentially. & i dont think anyone is suggesting that, i hope
- imanaccount247 12y agoI don't know how to make it any clearer. You connect as user A. You authenticate. You can only do things user A is given permission to do. Yes, people are suggesting talking directly to the DB. We want that because we already use our DB this way anyways, but we have to have a completely unnecessary web layer sitting in front of it just to pass the request directly back to the database without doing anything to it.