6 ms·
Not sure how I feel about exposing my database directly to a client. This means all security regarding reading and writing any data must be handled in CouchDB.
by aneth 16y ago
Not sure how I feel about exposing my database directly to a client. This means all security regarding reading and writing any data must be handled in CouchDB. Not knowing about CouchDB, the existence of CouchApp leads me to believe there must be some way to do this, but I can't see how this would be possible with MySQL or Postgres.
Cell level security in a database? Hmm.
- jchrisa 16y agoCouchDB's security is per-database (since you assume you will be replicating a complete database to the end-user, the concept of cell-level security doesn't make sense).
- aneth 16y agoCell-level security would never make sense, which is why you need an application layer to perform queries and return and modify only data that a client has permission for. Am I right that the database would be shared by all clients and that the application layer is essentially moved into the client? If so, this seems like a pretty silly architecture.
- jchrisa 16y agoyes the application runs entirely on the client, but validation functions are run on replication, so I can change my copy of your blog post, but you won't let me change it via replication. That would be silly.
- prodigal_erik 16y agoIs that desired behavior in CouchDB? If replication will refuse to change anyone else's copy of that document, changing my own copy merely desynchronizes my replica and deceives myself about the true state of the world. I would prefer the system know which changes would be rejected elsewhere, and stop me from making them in the first place.
- aneth 16y agoIn addition to erik's comment, I'm also concerned about what people can read. What about email addresses in the user table? Deleted posts and edit history? Privately shared content? Does validation allow the restriction of who can view certain content?