7 ms·
Sorry, if you read the page linked you'd see that that is not the case. It is open to SELECT, UPDATE, and INSERT. if it were SELECT only that would be read-only
by TheEskimo 15y ago
Sorry, if you read the page linked you'd see that that is not the case. It is open to SELECT, UPDATE, and INSERT. if it were SELECT only that would be read-only.
As it is, that's just stupid as any user can wantonly edit anything. I could trivially edit every level's author to be myself or do intensive operations which result in a DOS.
The only smart way to give clients access to a database is through some sort of frontend entirely under your control which prevents them from having the user/pass and sanitizes the queries.
Edit: Whoops, while I typed this multiple other people did the same. Sorry for the redundancy.
- nicksergeant 15y agoYes, I replied to my comment and even updated the original comment indicating that I was incorrect.
- soult 15y ago> The only smart way to give clients access to a database is through some sort of frontend entirely under your control which prevents them from having the user/pass and sanitizes the queries. MySQL maybe, but enterprise DBs (think Oracle, DB2, Postgres) support a very fine-grained access model.
- toyg 15y agoI'd argue that even then, they are less hardened against network-layer exploits than your average webserver. Network security is bread & butter for a webserver, not for your enterprise DB running in safe intranets with only cursory penetration testing.
- soult 15y agoI agree, though if you hardcode username and password into your application there's no need for fancy exploits.