4 ms·
Is that really good enough, though? For example, suppose that I write a blogging platform, and I want to ensure that a user can only query their own blog entri
by akeefer 17y ago
Is that really good enough, though? For example, suppose that I write a blogging platform, and I want to ensure that a user can only query their own blog entries. How would I do that if the query is coming from the client (which always has to be untrusted) directly to the database? What prevents someone from rewriting the js client side so that it queries blog posts from other users? Or to prevent it from just sucking back all the blog posts in the DB and essentially DOSing the whole server?
Doing per-user security directly in the DB with simple CRUD permissions per table would be enough of a headache, but most applications eventually require finer-grained security than that, and for performance reasons you also don't want a client to be able to execute just any arbitrary query.
It seems like this is pretty close to same trap a lot of people fall into of only enforcing data validation client-side, or only enforcing things like view permissions client-side (by not rendering links), which leaves all sorts of holes open.
- Periodic 17y agoI kept hoping the next paragraph would address this, but it didn't. It's cool and all, but it sounds like you're still going to basically need a server stack there to enforce permissions and some logic and consistency things. For example, say users have some private data. What stops me from modifying the javascript to insert a record that points to someone else's email address in my record? Unless the database can see this and prevent it I might then be looking at or even able to change someone else's email on their account. It can get very hairy if you don't have full control over the database interaction because you have to start guarding against arbitrary database operations.
- deleted 17y ago[deleted]
- iamwil 17y agoWell, all queries are accessed through URLs. There are two types of queries: temp views and permanent views. You can use apache/nginx to redirect all query through URLs for temporary views. Permanent views are stored on the db. That way, your client can't execute arbitrary queries. Then, the client can only be limited to views/queries that the web dev set. http://wiki.apache.org/couchdb/Nginx_As_a_Reverse_Proxy http://wiki.apache.org/couchdb/Nginx_As_a_Reverse_Proxy Then as long as the client can keep its identification token secret from others, you can implement "user can only query their own blog entry" I suggest you look into couchDB a bit further. CouchDB is a different beast altogether from relational databases. Therefore, the assumptions you make about what a database can and cannot do coming from a relational world doesn't always apply.