On 14 Sep 2010, at 03:26, J Chris Anderson wrote: > > On Sep 13, 2010, at 6:23 PM, Simon Metson wrote: > >> Hi James. >> I think the thing to do is require that a document has a user field, >> and that the value of that field matches the userCtx in the >> validate_doc_update function. This then pushes the issue client side, and >> makes the servers life easier. It could also be added by the front end >> apache in the case of our deployment, I think. I can see this sort of >> trigger thing being a good way of giving people a loaded gun aimed at their >> foot, they certainly are in Oracle if you're not careful. >> Cheers >> Simon > > The big issue is that any code which runs on normal document updates, will > also run during replication, as replication is just a normal client. So this > means that adding a field will happen not just on the original client PUT but > also when replication happens. > > This is why _update is a separate handler.
Adding a required field should be idempotent (correct me if I am wrong) so it doesn't matter that replication is an agent of the user. In the past we talked about "blessing" a ddoc / update function that would magically invoke the update function on every write. (analog for _show and _list) and people seem to like to explore that idea. That said, the "magic" bit worries me a little :) Cheers Jan -- > > Chris > >> >> On 9 Sep 2010, at 05:19, James Jackson wrote: >> >>> Hi all, >>> >>> Moving this from the users forum, as it appears what I'm after isn't >>> currently available. For the security model I with to implement in a >>> production CouchDB cluster, I would like to be able to force a field to be >>> written to all docs based on the user context. The _update functionality is >>> not what I am after as it requires the user to actually call it when >>> writing a document (means security could be got-around by not calling this, >>> and setting the required field in the passed document to something >>> arbitrary, which would then not get caught by a validation function), and >>> can't modify a document which is passed to it (as far as I can tell it can >>> only modify existing documents, or create new ones). >>> >>> I see this ticket: >>> >>> https://issues.apache.org/jira/browse/COUCHDB-441 >>> >>> which talks about the functionality I am after, but appears to have morphed >>> into what is now there. >>> >>> I am willing to implement such functionality, if it already doesn't exist, >>> but wonder if this would be welcome in the trunk, or if there are killer >>> pitfalls which stop this being possible. I note that in the discussion on >>> that ticket there is talk of how to deal with multiple such modify-on-write >>> functions, perhaps this is one area that needs discussion? >>> >>> In any case, I'll probably implement this for our CouchDB installation, but >>> it would be good to make it generic and globally useful such that I can >>> contribute it back. I know of a number of people who would like this >>> functionality... >>> >>> Regards, >>> James. >> >
