On 19 Feb 2014, at 14:19 , Alexander Shorin <[email protected]> wrote:
> On Wed, Feb 19, 2014 at 5:15 PM, Jan Lehnardt <[email protected]> wrote: >> 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. > > Which bypassed validation rules, right? And what stops him to use the > same credentials to push data back from local instance to public one? > If it workarounds validation rules, he'll be able to rewrite docs that > he shouldn't be able to. That's the problem. No, I mean in my scenario the person who could make a local change to a doc they didn’t create would *NOT* have the replicator user’s credentials, so they could NOT replicate things back elsewhere. You point is important though: you need to set these things up carefully :) Best Jan --
signature.asc
Description: Message signed with OpenPGP using GPGMail
