On 19 Feb 2014, at 13:27 , Alexander Shorin <[email protected]> wrote:
> On Wed, Feb 19, 2014 at 4:17 PM, Jan Lehnardt <[email protected]> wrote: >> On 19 Feb 2014, at 13:02 , Alexander Shorin <[email protected]> wrote: >> >>> On Wed, Feb 19, 2014 at 3:59 PM, Jan Lehnardt <[email protected]> wrote: >>>> On 19 Feb 2014, at 11:42 , Alexander Shorin <[email protected]> wrote: >>>> >>>>> On Wed, Feb 19, 2014 at 2:24 PM, Robert Samuel Newson >>>>> <[email protected]> wrote: >>>>>> validate_doc_update(oldDoc, newDoc, userCtx) { >>>>>> >>>>>> if (newDoc.audit_trail[0].user != userCtx.name) { >>>>>> throw({forbidden: "You didn’t add your name to the audit trail!"}); >>>>>> } >>>>>> … >>>>>> } >>>>> >>>>> There is one issue with such approach: replications. You will not be >>>>> able to replicate documents which has different username in >>>>> audit_trail from those one who runs the replication. Or, to be more >>>>> detailed, you'll replicate fine all documents till the design document >>>>> which brings this validation function to your database and after that >>>>> you'll only able to store documents which matches replication's user. >>>> >>>> You could add the replication user to the validation function and keep >>>> the original author. >>> >>> Sure, I could. But this would be tricky and unclear for other users >>> that just wanted to grab the data from CouchDB. >> >> how so? > > Let's say we have some database where multiple users are collaborating > upon some stuff. Let it be image hosting service based on CouchDB > where friends shares images between. Your users allowed to post new > docs with images, but they don't wanted to see how others users > changes docs that they owned. We forbidden such actions via > validate_doc_update function by checking if doc.author matches > userCtx.name. So, that's the case: you allowed to update own documents > and only allow to read the others. > > Now some user wanted to replicate this database to local CouchDB. He > already has his own personal credentials. And he'll use them in > replication and I wonder if he's able to recall another account to use > for replications. Also, if I create special username which is able to > bypass validation function ... well, that's a bug in the system - > what's the reason left to use restricted accounts when you have access > to more powerful ones? In this scenario, the other user would not be able to invoke a replication with the replication-user credentials.
signature.asc
Description: Message signed with OpenPGP using GPGMail
