On Sun, Sep 13, 2009 at 12:48 AM, Vlad GURDIGA <[email protected]> wrote: > I'm sorry to break the wave, but I wonder would it be practical to > have a kind of validate_doc_read.js? It would give a certain level of > consistency with the validate_doc_update.js mechanism, and we would > probably be able to have a unified security meta-data looking like: > > var role = { > editor: { > can: { > read: {books: true, authors: true}, > write: {books: true, authors: true}, > add: {books: true, authors: true} > } > } > }; > > var user = { > > john: { > can: { > read: {books: true, authors: true}, > add: {books: true, authors: true} > }, > has: { > role: {editor: true, administrator: true} > } > }, > > mary: { > can: { > read: {authors: true}, > add: {authors: true} > }, > has: { > role: {editor: true} > } > } > > }; > > This maybe looks a little verbose to write but feels pretty readable: > > if (!user[userCtx.name].can.read.books && > !user[userCtx.name].has.role.editor) { > throw "Read access denied"; > } > > It would decouple security meta-data from the data itself (I'm not > saying that this would necessarily be a good thing though, let's > discuss). > > What do you think? >
I think this is a cleaner and more flexible model. It would be slow as hell though, as you'd have to do all that serialization on every read, not just on updates. I wonder how slow it would be. I'm guessing it'd take CouchDB from thousands of reads per second to tens of reads per second, but that's just a guess. It also doesn't take into account view read permissions. Maybe it is better to think about doc ACL later, and just concentrate on per-db auth for now. Chris -- Chris Anderson http://jchrisa.net http://couch.io
